[HowTo] Boot Manjaro ISO directly with GRUB

Difficulty: ★☆☆☆☆

We are all familiar with burning live usb stick to boot our Manjaro isos. That is useful when you are installing manjaro on a new machine. However, if you already have linux installed with grub, there is a better way to boot Manjaro iso files. I usually do this when I test new iso files for a new release or when I need to use a rescue system because one of my experiments rendered my installation unbootable.

You can boot the .iso file directly from your hard drive without burning an USB stick. Not only is this less hassle, it also gives you better performance because your HDD or SSD is much faster than your average USB stick. And your kids are usually less likely to eat your hard drive than your USB sticks. I learnt his from @gohlip, who posted a similar tutorial on the archived forum: Booting Manjaro iso using grub2 - Tutorials - Manjaro Linux Forum

How to do it

  1. Save your .iso file to directory /miso on a FAT or EXT2/3/4 volume. You can also use a different folder, but you need to adjust the configuration file path accordingly.

    • If you use btrfs subvolumes, you need to include your subvolume in path, like this /@/miso and need to insmod btrfs instead of insmod ext2 in the examples below.
    • If you use another FS, insmod your FS instead of insmod ext2 in the examples below.
  2. Create the file /boot/grub/custom.cfg or /etc/grub.d/40_custom file with the following contents:

    menuentry "Manjaro  grub_iso"  {
        set isofile="/miso/manjaro-gnome-20.1-stable-x86_64.iso"
        set dri="free"
        set lang="en_US"
        set keytable="fi"
        set timezone="Europe/Helsinki"
        search --no-floppy -f --set=root $isofile
        probe -u $root --set=abc
        set pqr="/dev/disk/by-uuid/$abc"
        loopback loop $isofile
        linux  (loop)/boot/vmlinuz-x86_64  img_dev=$pqr img_loop=$isofile driver=$dri tz=$timezone lang=$lang keytable=$keytable copytoram
        initrd  (loop)/boot/intel_ucode.img (loop)/boot/initramfs-x86_64.img
  3. Adjust the keytable, timezone and language parameters to match your needs. Make sure your isofile variable matches the name and location of your iso file.

  4. If you have an AMD CPU, change intel_ucode.img to amd_ucode.img.

  5. Profit. When you reboot, your grub has an extra entry that let’s you boot into the live system.

This menu entry loads the iso to ram. It increases the performance further, and let’s you mount and manipulate the partition that the iso is located on. However, it also requires more ram. If you don’t have enough ram for this, you can remove the parameter copytoram from the configuration.


Really nice, never thought about that although aware it is possible. And damn easy too.

Also very helpful if the system does not want to boot and you don’t have a stick at hand or can’t flash one from another device. (At least if grub and the drive is still ok)

First thing I will do after work tomorrow :wink:

1 Like

I usually have btrfs subvolumes and timeshift-autosnap with grub-btrfs set up, plus this. So, if an update messes up my boot, I boot into the snapshot that was taken right before the update, and restore that. But if that doesn’t work, I can still boot into my live system and fix the issue from there. Booting into a snapshot is just quicker though if I’m in hurry.

Very great guide!!
But I have a doubt though, it’s necessary to run sudo update-grub after create the file and if I’m using an AMD CPU, i need to change intel_ucode.img for amd_ucode.img?

Nope, this is direct gru configuration and not touched by update-grub


Not needed.

Changes to /boot/grub/custom.cfg do not require re-running *grub-mkconfig* , since /etc/grub.d/41_custom adds the necessary source statement to the generated configuration file.

Thanks!!! I’m gonna try it right now!!!

I’m not able to boot up with the iso, this are the errors

  1. Can’t find the disk
  2. Can’t find the iso
  3. Can’t find server
  4. load the kernel first
    I recheck the path, the options i change in the custom.cfg

Could be because of the UUID?

Damn, this is a wet dream for distro hoppers also. :joy:
Faster than setting up a VM and you can try on bare metal right away.

There should be some tool to automate this (select distro(s), download iso(s), make cfg, reboot :wink: :joy:

1 Like

The problem is that different distros need different Grub menu code.
I used to get the code by analysing the ISO, I mounted it with
mount -o loop *.iso /mnt
then checked what is in the /mnt/boot folder and tried to recreate it. It was still not possible to boot many ISOs this way.

I’ve used this method for a long time and it works great. But, it’s a hassle when updating the iso. With the release of ventoy and its ability to autodetect the image(s), is it not possible to update the script for a true “drag & drop & forget” method?

1 Like

There is also


Yes, auto detection is quite possible. Ventoy is even more simple because you don’t need to update the menu when you add isos. Not sure how to use ventoy directly from the disk, but that might be possible too.

You can use ventoy from disk - I wouldn’t recommend it though - especially since ventoy formats the disk to exfat.

I’ll have to try ventoy at some time and examine the grub config. Maybe it could be used as template for drag and drop iso booting from disk too? I dunno, have to see.


Thanks for this very useful tip…I will try it for my new laptop. :hugs:

1 Like

I followed the first post, modified the custom.cfg to match my needs (AMD cpu, nonfree drivers, fr keytable, Paris timezone), and with no surprise it worked flawlessly this is really great to have a ‘live media’ always on hands! great tutorial thanks!

Something that could be noted is the possibility to customize the dri variable (free or nonfree), and the menu entry name can also be changed.


I’d like to boot Manjaro from iso and make it use my home folder. Is it possible?

As far as I know the ISO is a closed system you can’t really use it like a normal system.

Yes, but why? Do you want the change to be persistent?

1 Like

That way it wouldn’t have to be installed. I’d boot directly from iso and instead of updating the system I’d build another one. I don’t know if it makes sense, but seems like an interesting concept. lz4 makes boot time really fast and copytoram makes the entire system super responsive.

What you’re describing is this:


is not a good idea when a critical vulnerability surfaces: the ISOs get only built a couple (2-3) times per year and a persistent USB stick is the ultimate in portable computing…