Booting ISO or USB key images directly from Grub2?

I’m playing with the idea of booting ISO images and USB key images stored in a disk partition directly from Grub2. That would allow to install Linux or test liveCDs without even using a USB key. It seems that Grub2 has everything needed for that (with a combination of drivemap and chainloader), but I can’t seem to get it working and, as usual with boot stuff, it’s a pain to understand what’s happening.

Has somebody recently tried that, or can point me to a howto?

23 thoughts on “Booting ISO or USB key images directly from Grub2?

  1. I, too, have wanted to accomplish this but lack the Grub2 knowledge to do so. Very exciting indeed!

  2. drivemap and chainloader won’t work; remember that the kernel and initrd you boot have to start out from bare metal and find their root filesystem, and as such you need active cooperation from them (they might offer some magic boot parameter you can pass to tell them to loop-mount an ISO). After that you want something like ‘loopback loop0 /path/to/iso’.

    Ideally you would then be able to ‘set root=(loop0)’ and just forget about the loopback bit for the rest of grub.cfg, but we need to get merged in order for that to work properly. In the meantime, you should just be able to prefix the kernel and initrd paths with (loop0) in order to get GRUB to read them from the loopback filesystem.

  3. I’ve been able to boot the Lucid Desktop and Netboot ISOs from my USB flash drive with the following grub.cfg stanzas:

    menuentry “Ubuntu 10.04 Lucid Lynx Desktop AMD64″ {
    loopback loop /images/ubuntu/ubuntu-10.04-desktop-amd64.iso
    set root=(hd0,1)
    linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=/images/ubuntu/ubuntu-10.04-desktop-amd64.iso noeject noprompt
    initrd (loop)/casper/initrd.lz

    menuentry “Ubuntu 10.04 Lucid Lynx Desktop i386″ {
    loopback loop /images/ubuntu/ubuntu-10.04-desktop-i386.iso
    set root=(hd0,1)
    linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=/images/ubuntu/ubuntu-10.04-desktop-i386.iso noeject noprompt
    initrd (loop)/casper/initrd.lz

    menuentry “Ubuntu 10.04 Lucid Lynx Netbook i386″ {
    loopback loop /images/ubuntu/ubuntu-10.04-desktop-i386.iso
    set root=(hd0,1)
    linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=/images/ubuntu/ubuntu-10.04-netbook-i386.iso noeject noprompt
    initrd (loop)/casper/initrd.lz


    These didn’t work when I tested them in KVM, but they did work on real hardware, so be wary.

  4. As above (anonymous) but I have:

    menuentry “Kubuntu 10.04 x64″ {
    loopback loop /iso/kubuntu-10.04-desktop-amd64.iso
    linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=/iso/kubuntu-10.04-desktop-amd64.iso noeject noprompt –
    initrd (loop)/casper/initrd.lz

    menuentry “Kubuntu 10.04 x64 (XBMC)” {
    loopback loop /iso/kubuntu-10.04-desktop-amd64-xbmc.iso
    linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=/iso/kubuntu-10.04-desktop-amd64.iso noeject noprompt –
    initrd (loop)/casper/initrd.lz

    my iso folder is on the root of the drive, next to the grub dir.

  5. Many, many people want this. As pointed out above, you can do it in some special cases like Linux installer ISOs, but only because those installers use kernels and initrds that understand ISOs. If grub2 had hard-disk emulation support (such as that in the grub4dos fork of grub1), it could handle disks that just use a CD to boot like a floppy.

    However, if you wanted to handle it in the general case for arbitrary bootable ISOs, you would have to have GRUB leave part of itself around when the OS runs much like it does with drivemap, but instead of a simple interrupt hook, it would need to emulate a full CD-ROM drive and controller (ATAPI, SCSI, SATA…) in a way that arbitrary OSes could understand. Not likely to happen.

  6. Try PLoP ( It’s an alternative boot manager on its own that can boot off of USB sticks and other devices, but you can add it as an option in Grub, and use that to boot a USB device if Grub on its own cannot.

  7. Like Colin Watson already mentioned, to chainload an ISO from grub2 is unfortunately not possible (yet/ ever?), as it would require grub2 to intercept not only BIOS calls for emulating a CD drive from the given ISO (so the embedded ElTorio bootloader can take over), but also to fool higher level driver OS drivers. While kernel and initramfs can be loaded through grub2′s loopback option, grub.cfg still needs to know about their exact location inside the ISO. Additionally the initramfs must be able to find the root device itself, which unfortunately rules out generic solutions and makes it not only dependent on proper OS/ initramfs support, but also highly distribution specific.

    For sidux, we have solved this through the custom grub2-fll-fromiso package mentioned by iria.
    Vcs-Svn: svn://
    This package plugs into update-grub (Debian specific), searches for ISOs matching a given regexp below the configured directories and then looks inside the ISOs (through genisoimage’s isoinfo, to avoid having to mount it) for kernel and initramfs files, matching a hardcoded regexp (vmlinuz, initrd.img) for the file names. Once these are known, an appropriate stanza can be written to grub.cfg (the example is slightly more complex than necessary, given that the ISOs are stored on LVM2):

    ### BEGIN /etc/grub.d/60_fll-fromiso ###
    menuentry "sidux-2009-04-moros-kde-lite-amd64-200912310312 (vmlinuz0.amd)" {
    insmod iso9660
    insmod lvm
    insmod ext2
    set root='(vg-challenger-pyfll)'
    search --no-floppy --fs-uuid --set 5050dfe1-96ac-4680-a093-6fdef64c5c56
    loopback loop /sidux-2009-04-moros-kde-lite-amd64-200912310312.iso
    linux (loop)/boot/vmlinuz0.amd fromhd=/dev/mapper/vg--challenger-pyfll fromiso=/sidux-2009-04-moros-kde-lite-amd64-200912310312.iso boot=fll lang=de_DE TZ=Europe/Berlin quiet noeject hostname=challenger username=slh
    initrd (loop)/boot/initrd0.amd
    ### END /etc/grub.d/60_fll-fromiso ###

    The drawback, besides having to call update-grub for updating grub.cfg, is, that this needs a lot of cooperation from the affected live ISOs and exact knowledge about distribution specific boot parameters. In case of sidux, these are fromhd= (the block device which holds the ISO), fromiso= (path to the ISO, relative to the afforementioned block device) and boot=fll, which calls the live-sidux specific initramfs scripts to locate root device and evaluate boot parameters. lang=, TZ=, hostname=, username= and the default quiet and noeject parameters are optional and configurable.

    While this works reliably for sidux and could be enhanced to cover additional distributions providing similar functionality, it still depends on a lot of cooperation from the live ISO and its initramfs implementation – in addition to a positive distribution recognition. Unfortunately these boot parameters for finding the root device from non-ElTorito block devices vary greatly between live distributions, if they’re implemented in the given distribution at all.

  8. Ah, booting *Linux* installers or liveCDs; well, memdisk won’t work for that, obviously. I’ve successfully used it to boot vendor foo (hard disk diagnostics etc.) which are silly enough to work.

  9. Hiya , searching for the best possible nearly insightful penny stock news letter? .
    I RECENTLY have definitely one you need to check out I try and give the best and brisk data, thus if financial firms of involvement to you personally delight check out my penny stock newsletter.

Comments are closed.