Quick & dirty: From zero to Manjaro, with a duplicate system and external bootloader on GPT disk attached to UEFI motherboard

Content table

     Bootloader preparation
     Bootloader execution

:arrows_counterclockwise: 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.

:x: No, manjaro-chroot isn’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.

:brain: 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.

:wrench: 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.

:unlock:Do not forget to disable SecureBoot!
Manjaro doesn’t sign their kernels, nor provide keys! Boot issues occur otherwise if left on!


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:dagger: for evaluation of a new device or for use as a functional backup you can boot into, then read on to find out how.

:dagger: For machines you have administrative rights for! Don’t go about performing this on devices you do not own, and especially without preparation beforehand as it’s a bad look to have a non-functional system due to hardware compatibility issues.

:fast_forward: 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.

:left_right_arrow: 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.


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:

:heavy_dollar_sign: Live session instance, in preferred terminal emulator:

inxi -Fa
Understand this command

:book: 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], -s and -n.

Expanded understanding of -F:

-W: Adds weather line. (Yes, inxi can 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 (-xxx provides the most information.)

Needless to say, this will not filter output. If you’re going to share your inxi output to a forum like this one, you should always use inxi -Fazy instead, 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.

:computer: 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.


:fast_forward: I will assume the partition with Windows is already shrunk. If not; gparted, partitionmanager or gnome-disks can 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 to gparted and gnome-disks (via gnome-disk-utility).

:minidisc: If you want to use an exfat partition for shared storage or extra space, then the only GUI software which allows you to do this (to my knowledge) is gnome-disks.

:right_anger_bubble: If you try to use manjaro-chroot -a for finding the duplicated system and enabling it, you can’t. Sure, it’ll find the instance and let you try but manjaro-chroot will 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.

:motorcycle: 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.

:heavy_dollar_sign: Live session instance, in preferred terminal emulator:

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:

:gear: In Run Application or similar dialogue:

pkexec gparted

:heavy_dollar_sign: Terminal works too, but will output debug information, which will over time with subsequent commands cause you to lose information from lsblk with 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.


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.

:clamp: 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.

:stop_sign: 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.

:rewind: In hindsight this might not be necessary. But ptovided EFI partitions are typically assigned the boot and esp flags 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.

:spiral_notepad: As an additional provision, use a redirect to output as text file. Example below.

:heavy_dollar_sign: Live session instance, in preferred terminal emulator:

lsblk -f > $HOME/Desktop/disks.txt

This 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.

:fast_forward: Assuming the system partition is labelled OS from 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.

:heavy_dollar_sign: Live session instance, in whatever terminal you prefer to open /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.

:spiral_notepad: From pluma in (hypothetical) /etc/fstab at /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

:mag_right: /etc/fstab is 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.

:spiral_notepad: From pluma in (hypothetical) revised /etc/fstab at /run/media/manjaro/OS, 1 / 2

UUID=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:

:spiral_notepad: From pluma in (hypothetical) revised /etc/fstab at /run/media/manjaro/OS, 2 / 2

UUID=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…

:heavy_dollar_sign: Live session instance, in whatever terminal you prefer to open /etc/fstab:

pluma admin:///run/media/manjaro/OS/boot/grub/grub.cfg

…and disregard this message near the top.

:spiral_notepad: From pluma in (hypothetical) /boot/grub/grub.cfg at /run/media/manjaro/OS, useless warning:


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:

:heavy_dollar_sign: GRUB Rescue


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.

:fast_forward: I will assume the system is on (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.

:heavy_dollar_sign: GRUB Rescue:


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.

:heavy_dollar_sign: GRUB Rescue:

set root=(hd1,4)
set prefix=(hd1,4)/boot/grub
insmod 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.

:railway_track: This is where we get back on track with advice from the Manjaro wiki!

:heavy_dollar_sign: In xdg-terminal or 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…


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.

:heavy_dollar_sign: In xdg-terminal or preferred emulator:

hostnamectl set-hostname newfonewhodis

:pencil2: Replace newfonewhodis with 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.


A lot of work, and a bit of memes went into this one. Hope it was worth it to help at least one person out. If there is some way to make manjaro-chroot mount the duplicated system instance then let me know! I feel like there is a way to do it, but I was also lacking time before I had to discard the other machine I had access to which included SecureBoot, EFI and all of that jazz.

1 Like

You’re one of the prime candidates to become a wiki editor once the new wiki comes online (Date: TBD, being handled by one guy off-line for now)


I definitely did not forget to include the step about copying /boot from original EFI part duplicated system root into the new EFI part on USB-attached media, not at all. :blush:

Apologies for dropping that bit of information. Bootloader Preparation has been revised.

1 Like