Don't understand german? Read or subscribe to my english-only feed.

Booting ISO images from within GRUB2

You might be aware of GRUB’s loopback option for booting an ISO, I wrote about it in Boot an ISO via Grub2 more than a year ago. A few months ago Goswin von Brederlow came up with this idea:

grml functions great as rescue system. So it would be nice to have a boot entry for it in grub instead of having to go look for the CD when needed. To make installing and updating simple it would be great if one could install this as a normal debian package which would register itself in grub (and maybe lilo too).

What a lovely idea: no need for a CD or USB stick as long as the bootloader and the harddisk are still working. Minimal manual intervention needed to keep it up2date and working – sounds like the perfect rescue system. 8-)

Now since end of 2010 a new stable version of sysadmin’s favorite live system (AKA Grml 2010.12) is available and the great news is that we came up with two independent solutions known as grml-rescueboot and grub-imageboot. Having shipped them to one of my customers already I’d like to write some words about it and why you should also consider using it on all your systems where GRUB2 is available.

grml-rescueboot uses GRUB2 and its loopback feature for booting. Grml as well as Ubuntu provide all what’s needed out-of-the-box. If you’re interested in the details check out Jordan Uggla’s excellent Loopback.cfg webpage in the supergrubdisk wiki. The best about it: you can provide custom bootoptions automatically when booting Grml. For example just set CUSTOM_BOOTOPTIONS=”ssh=grml2011″ in /etc/default/grml-rescueboot and the Grml rescue system will automatically start the OpenSSH server with the specified argument as password for user grml. Of course you can use all the other nifty bootoptions like scripts/netscript/… to further customize your Grml rescue system. [A note to other distributions like Ubuntu: I’d be interested to establish a mechanism to pass kernel options for loopback boot in a standardized way, drop me a note if you’re interested in this.]

grub-imageboot uses GRUB2 and syslinux’ memdisk to boot ISOs and floppy images. It doesn’t rely on the loopback feature but instead maps the ISO into the memory directly. This is great for Linux ISOs that can’t and won’t support the the loopback feature (and have everything inside their initrd so the ISO doesn’t have to find itself during booting), like BIOS or firmware updates. Also for example FreeDOS and Alpharev are known to work just fine. But sadly memdisk ISO emulation doesn’t work with all Linux systems, as documented in the syslinux wiki. The good news is that Grml supports the memdiskfind/phram/mtdblock approach out-of-the-box. As far as I know therefore Grml is the first Debian based live system supporting memdisk ISO boot, though my patches already went to the Debian-Live project so if you’re using live-boot >=2.0.14-1 or >=2.0.12-1+grml.04 your live system should be able to boot via memdisk ISO emulation as well.

Summary: If you want to boot a Linux system which supports loopback.cfg use grml-rescueboot as its a more powerful tool to boot Linux live systems like Grml and Ubuntu. If you want to boot non-Linux systems (BIOS-/Firmware-Updates/FreeDOS/….) use grub-imageboot.

Alright – how do you deploy this solution? Just grab and install grml-rescueboot and/or grub-imageboot.

To deploy grml-rescueboot (adjust $VERSION if you want to use another flavour):

# choose Grml version:
VERSION=grml64-medium_2010.12

# create directory
mkdir -p /boot/grml

# download and verify ISO
cd /boot/grml
wget download.grml.org/${VERSION}.iso{,.md5}
md5sum -c ${VERSION}.iso.md5

To deploy grub-imageboot:

# choose Grml version:
VERSION=grml64-medium_2010.12

# create directory
mkdir -p /boot/images

# download and verify ISO
cd /boot/images
wget download.grml.org/${VERSION}.iso{,.md5}
md5sum -c ${VERSION}.iso.md5

That’s it! Now when running update-grub you should get something like:

# update-grub
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-2.6.36-grml64
Found initrd image: /boot/initrd.img-2.6.36-grml64
Found memtest86+ image: /boot/memtest86+.bin
Found memtest86+ multiboot image: /boot/memtest86+_multiboot.bin
  No volume groups found
Found Grml ISO image: /boot/grml/grml64-medium_2010.12.iso
Found memdisk: /boot/memdisk
Found iso image: /boot/images/grml64-medium_2010.12.iso
done

Voilą, when rebooting your system you should see something like:

Screenshot: grml-rescueboot

The “Grml Rescue System” entry is what grml-rescueboot provides and “Bootable ISO Image” is what’s provided by grub-imageboot. Just select the entry you’d like to use, press enter and and you should get the bootsplash of the according ISO.

BTW: I’ve tested this with Ubuntu 10.10 too, grml-rescueboot works out-of-the-box with the Ubuntu ISO as well, it just doesn’t support the memdisk ISO boot by grub-imageboot (yet).

Tip: if you want to use grml-rescueboot and grub-imageboot with the same ISOs without having them twice on the disk just point the configuration option IMAGES in /etc/default/grub-imageboot to the according directory (like /boot/grml).

Note: if you’re using the ext{2,3,4} filesystem on the partition that’s being used for /boot please be aware that you need GRUB >=1.98+20100804-12 (newer version is already available in Debian/unstable and hopefully migrates to squeeze in time) or GRUB >=1.99~20101122-1 because of the INDIRECT_BLOCKS support, see #543924 for the details.

PS: We think about providing grml-rescueboot and grub-imageboot within official Debian. If you’re interested in seeing integration support for other distributions as well please help and drop us a note.

5 Responses to “Booting ISO images from within GRUB2”

  1. Fabian Says:

    Yes, please get this (esp. grub-imageboot) into Debian ASAP. BTW, for the availability of the memdisk image, a dependency on syslinux-common (instead of syslinux) is sufficient!

    – Fabian

  2. mika Says:

    @Fabian: thanks for the information regarding syslinux-common, though I think we’ll stick with the dependency on syslinux to make sure the upgrade path keeps on working if there are any package renames.

    regards,
    -mika-

  3. Fabian Says:

    He, I don’t get it. Why do you install another entire boot loader package (i.e. syslinux) if you only want to use one file (which is in syslinux-common) with a different boot loader (i.e. grub-pc)? If the upgrade path gets broken by a package rename, there is the BTS to report this. ;)

  4. mika Says:

    The syslinux package is just a very small package (Installed-Size: 204), depending on the package(s) that are required to get all relevant files and features for appropriate “syslinux suite” support.

    If you depend on syslinux-common and e.g. the memdisk file moves to another package in the future, reporting a bug might not help, because you might get an answer like “why do you depend on a packaging specific package (syslinux-common) instead of the major one (syslinux) which takes care of a clean upgrade path?”, possibly tagged as “won’t fix”.

    If you still think a dependency just on syslinux-common would be important enough that it’s worth all the effort, please report it to the maintainer of grub-image (Alexander Wirt -> formorer (at) debian.org).

    regards,
    -mika-

  5. mika Says:

    Ok, Alexander adjusted the dependency (using syslinux-common now) and grub-imageboot is on its way to Debian NEW queue.

    regards,
    -mika-