Content table
Preface
Preparation
Duplication
System
Bootloader preparation
Bootloader execution
Hostname
Dèjá vu? Yes, we’ve been at this place before. This topic is a slight repackaging of what I wrote not too long ago about fixing a system when UUID from backup is modified, for this scenario.
No,
manjaro-chrootisn’t going to help you here. I’ll explain why later, but right now what you need to know is that it didn’t work for me when I followed directions from the Manjaro Wiki. Hence, why I found another way that’s probably going to be quicker and yield much less frustration, in spite of the fact it’s technically the incorrect way of doing things.
A lot of this requires significant knowledge of how your system operates. While I try to offer the information quite simply with generic examples if applicable, it will be assumed there is some previous experience with disk manipulation utilities. If you lack this experience, everything is simple enough to use but may be frustrating the first few times using such software.
As I use MATE for my desktop, some examples may be specific to that. If you aren’t using MATE or a GTK desktop, adjust provided examples to suit your system’s security mechanisms and complimentary software which comes with your graphical shell environment.
Do not forget to disable SecureBoot!
Manjaro doesn’t sign their kernels, nor provide keys! Boot issues occur otherwise if left on!
Preface
Bought yourself a brand new computer and it came pre-loaded with Microsoft Windows? Want to dual-boot, but not delete the OEM’s system in case lax satisfaction with the unit merits a return? If you’re already running a Manjaro system on another computer or have a perfectly functional backup hanging around, you can use that and not lose anything from it, skipping the need to reconfigure.
If you wish to purpose an existing system on any machine
for evaluation of a new device or for use as a functional backup you can boot into, then read on to find out how.
This will not cover how to convert from BIOS to UEFI. For brevity, I’m assuming it’s already a system running as installed on a GPT disk for use with modern UEFI motherboards.
While the premise is using another PC’s internal storage media, if you’re looking to just make it external for ease of use between devices, the same exact procedures will work for that too!
Also, if using the system via external media — root, home and all — then the EFI partition can exist where those partitions are as it would on a typical installation. The reason one would want to have the EFI partition be in an external media is for instances where an EFI part already exists, as less work would be necessary to revert changes for an internally-installed media.
Preparation
Before you begin…
The machine in question needs to allow three distinct features as part of its motherboard firmware and one additional requirement:
- Toggle SecureBoot functionality
- Use of UEFI even if SecureBoot is turned off
- System boot using an EFI file
- Destination media already uses a GUID Partition Table (GPT)
If these qualifications are not met, transfer may still be possible but some of this guide simply won’t work, which will require alternative methods to complete this task.
Don’t forget, the live session instance for Manjaro requires use of a password for permitting superuser tasks. When prompted, the password is
manjaro.
If using a machine you are unfamiliar with, you should run a live session and perform the following to figure out what additional software packages you might need for the new machine, after some time of research. To begin your research, run this command to retrieve information about it:
Live session instance, in preferred terminal emulator:
inxi -FaUnderstand this command
From the inxi manual, published on July 26th 2020, with truncation and formatting
-F: Show Full output for inxi. Includes all Upper Case line letters except-W, plus [-j],-sand-n.Expanded understanding of
-F:
-W: Adds weather line. (Yes,inxican tell you the weather!)
-j: Shows all active swap types (partition, file, zram).
-s: Show output from sensors if sensors installed/configured[.]
-n: Show Advanced Network card information[:] interface, speed, MAC ID, state, etc.
-a: The --admin option sets -xxx, and only has to be used once.Expanded understanding of
-a:
-xxx: [E]xtra data triggers can be useful for getting more in-depth data on various options. They can be added to any long form option list (-xxxprovides the most information.)Needless to say, this will not filter output. If you’re going to share your
inxioutput to a forum like this one, you should always useinxi -Fazyinstead, which will also format your output to be more forum-friendly. ex.:inxi -Fazy > $HOME/inxi.txt
Once you know if your machine needs additional packages, prepare the target system with additional libraries necessary for all hardware of the new machine if possible to save some headache later, and reboot into a live session without any additional media attached, to boot into it. If you cannot because it’s a backup you aren’t booting into, no sweat — deal with it later.
This should go without saying, but when booting into a live session, other devices might take priority depending on order of USB ports sought by firmware.
Especially if transferring a USB-attached system to another media, it is important to only attach additional media after the system has completed boot into the live session.
Duplication
gparted,partitionmanagerorgnome-diskscan deal with that if the disk isn’t using compression. For brevity, specifics of KDE / Qt software won’t be mentioned, which limits software function descriptors in this topic togpartedandgnome-disks(viagnome-disk-utility).
If you want to use an
exfatpartition for shared storage or extra space, then the only GUI software which allows you to do this (to my knowledge) isgnome-disks.
If you try to use
manjaro-chroot -afor finding the duplicated system and enabling it, you can’t. Sure, it’ll find the instance and let you try butmanjaro-chrootwill fail with a declaration it cannot mount said partition, in spite of it existing, At least that’s what I encountered.
The easiest software by far to use for this is gparted, as some boot flags need to be adjusted, of which I cannot seem to find in gnome-disks. To begin, have all media to be used for the execution and use of the new system prepared for transfer onto another machine’s media, if not choosing to use a system externally.
In certain instances, running from USB-C might be faster than an internal hard disk! Depends on machine, and as mentioned earlier this can apply equally to using a system externally.
After attaching all media intended for use, perform this for an at-a-glance partition index.
lsblk -f
This information doesn’t matter now, beyond making sure the partitions you want already exist. Perform this to execute gparted with elevated privileges:
In Run Application or similar dialogue:
pkexec gparted
lsblkwith limited scrollback. If using the terminal, end the command with an ampersand (&) so task can be interrupted in the terminal but still remain active in the foreground and restore access to the terminal.
System
Using the information from lsblk, you should be able to figure out which media to transfer onto where. For where the system will be, copy where system root (and if applicable, home) is, one at a time to paste into the destination media.
Once pending operations to copy the system partitions are ordered, apply changes and wait.
Used smaller partitions? You’ll thank yourself for having done so!
After completion, if you wish to avoid UUID collisions then perform a check for both partitions, prior to assigning them a new, randomly-generated UUID.
This may not be necessary! If you are going to delete the original partitions anyway, then you can avoid doing this and save yourself some work!
Bootloader preparation
Also applicable to portable instances, though you would apply a GPT table prior to copying.
Assumes UUID will had changed. If the only thing different is the external bootloader, you shouldn’t need to change anything more than
/etc/fstab.
For the bootloader, first create onto the external media to be used a new partition table using GPT if the media isn’t already prepared as such. When finished, create a new fat32 partition and label it as efi. This only needs to be 512 megabytes in size.
Once it is created, right-click on it to prompt a context menu which will lead to the Flags option. By default, msftdata is enabled but this partition needs to use the boot flag, which will also assign it the esp flag and de-assign msftdata.
In hindsight this might not be necessary. But ptovided EFI partitions are typically assigned the
bootandespflags as that EFI partition typically contains the sole bootloader on disk.
Once finished, mount the duplicated root partition, and new EFI partition using gnome-disks. The left pane should assist in identifying the disks said partitions are held in. I’d say continue operations in gparted if only the context menu there would allow me to mount. The reason for mounting both EFI partitions is because there needs to exist a means of accessing GRUB via USB for its rescue mode feature, which will be utilized later on. From duplicated root partition, copy /boot into the USB-attached media’s EFI partition.
Repeat the lsblk command from before for an updated at-a-glance partition table. This matters now for adjusting the UUIDs as shown in /etc/fstab of the duplicated system partition.
As an additional provision, use a redirect to output as text file. Example below.
lsblk -f > $HOME/Desktop/disks.txtThis might help if the terminal is preferred for operations involving the system’s graphical text editor as any debug output from opening it will most likely cause whatever useful output to be lost if not performed in another terminal emulator instance.
OSfrom hereon.
Using GVFS’ admin protocol, open the copy of /etc/fstab from the duplicated system instance, which will be in /run/media/manjaro. Consult lsblk or gnome-disks for this information.
/etc/fstab:pluma admin:///run/media/manjaro/OS/etc/fstab
If the UUIDs of any partitions listed there had changed, then use the information from lsblk post-change to modify these UUIDs. Example below.
plumain (hypothetical)/etc/fstabat/run/media/manjaro/OS:# <file system> <mount point> <type> <options> <dump> <pass> UUID=FEE1DEAD-0000-0000-0000-000000000000 / ext4 defaults,noatime 0 1 UUID=DEADBEEF-1111-1111-1111-111111111111 /home ext4 defaults,noatime 0 2 UUID=DEFEC8ED-2222-2222-2222-222222222222 none swap defaults 0 0 UUID=1337-C0D3 /boot/efi vfat umask=0077 0 2
/etc/fstabis not nearly this neat, but the example should help you figure out how the fields are suppose to be arranged for easier reeadibility.
For any of the UUIDs which are different from the original /etc/fstab in the duplicated partition compared to output from lsblk, change those. For instance, if the swap and bootloader are different, then only change those.
plumain (hypothetical) revised/etc/fstabat/run/media/manjaro/OS,1/2UUID=600DDODO-2222-2222-2222-222222222222 none swap defaults 0 0 UUID=60D5-C0D3 /boot/efi vfat umask=0077 0 2
If the UUIDs for system partitions are different, then not only those have to be changed, but the system root UUID in /boot/grub/grub.cfg also needs to be changed. So if this needs to happen:
plumain (hypothetical) revised/etc/fstabat/run/media/manjaro/OS,2/2UUID=FEE1600D-0000-0000-0000-000000000000 / ext4 defaults,noatime 0 1 UUID=600DBEEF-1111-1111-1111-111111111111 /home ext4 defaults,noatime 0 2
Then you also need to open the duplicate’s /boot/grub/grub.cfg as follows…
/etc/fstab:pluma admin:///run/media/manjaro/OS/boot/grub/grub.cfg
…and disregard this message near the top.
plumain (hypothetical)/boot/grub/grub.cfgat/run/media/manjaro/OS, useless warning:DO NOT EDIT THIS FILE
Use the find and replace function of your editor to replace the old system UUID with the new system UUID, and save. This is important as this will enable use of the system after setting GRUB root and prefix, which will be the next action to perform as presently, there is no functional bootloader.
Bootloader execution
Reboot and return to the device selection menu of your motherboard’s firmware. This time, rather than booting from USB an existing device, EFI file will be used.
Attempt to use the file from external device in /boot/grub called grub.efi. It will fail and go to rescue mode. This is where you can finally boot into the system.
Try this first:
ls
Whatever that outputs, know this trick: Legacy MBR partitions will have msdos in them, and GPT partitions will have gpt in them but those terms can be dropped completely. As there typically isn’t scrollback or cursor movement available in this rescue mode, this is of great convenience to know.
(hd1,gpt4): Adjust for your system and media!
While you can type in, say, (hd1,4) to see information about the partition, this is what you should do.
(hd1,4)/
That’s right, the only thing different there is a forward slash. But it will give you a directory listing. If you see things like /etc, /boot and /proc from your duplicate partition, you’re in the right place. So then to access the modified bootloader, do this.
set root=(hd1,4) set prefix=(hd1,4)/boot/grub insmod normal normal
That should prompt the bootloader from the duplicated partition. Press E to edit the bootloader entry for Manjaro Linux and make sure the system functions as intended, If it shows the UUID for the duplicated partition in all relevant fields of the bootloader entry, press F10 or hold Ctrl and press X to attempt boot.
If everything in /boot/grub/grub.cfg and /etc/fstab is correct, then you will proceed to boot into duplicated system instance. Once there, open a terminal and proceed as follows.
This is where we get back on track with advice from the Manjaro wiki!
xdg-terminalor preferred emulator:sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=manjaro --recheck sudo update-grub
How does it know what is /boot/efi? Because that’s defined in /etc/fstab! Once this task is finished, restart the computer and see if a new entry in the motherboard’s device selection screen titled manjaro shows up.
If it does, then that means GRUB is installed and functional via USB. Choosing it should prompt the instance of GRUB which comes with Manjaro, and you should be able to boot into the system which was duplicated. Once in, there is something else you should do if the oriiginal instance is used again…
Hostname
To avoid any hostname conflicts with the original system on any network, just like the UUID this should be changed as well. To do so is simple enough.
xdg-terminalor preferred emulator:hostnamectl set-hostname newfonewhodis hostnamectl
Replace
newfonewhodiswith your preference.
Make whatever other adjustments related to hostname you may need with respective programs, then after that you’re finished making a functional duplicate of your system from one location to another.
And if you ever change your mind about that machine you purchased, reverting changes should be as easy as deleting the ext4 partitions and resizing the OEM system partition to fill it in.
