[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Booting El Torito image from a partition table

From: Emilio Lazo Zaia
Subject: Re: Booting El Torito image from a partition table
Date: Sat, 28 Nov 2015 12:25:07 -0430
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Icedove/42.0

Hello Andrei. Thanks for your answer!

On 28/11/15 03:20, Andrei Borzenkov wrote:
28.11.2015 00:30, Emilio Lazo Zaia пишет:

I have a bootable iso9660 hybrid image (mbr + eltorito) that was made
with GRUB2 as its boot loader.

I would like to boot this ISO image from a partition table, i.e. boot
into this ISO image but dumping the image to a partition on a GPT or MBR
partition table, instead of dumping it to the partition table itself.

My disk contains only iso9660 images, one per partition. It boots with
SYSLINUX -stored for example in the first partition- and using chain.c32
module I can chainload into another partition's boot sector without
issues if the ISO image boots with ISOLINUX.

I wonder what code on this ISO image does. Does it work with partition
as read-only iso9660 image then? Out of curiosity, what do you use it for?
It is simply an iso9660 bootable hybrid image with GRUB as its boot loader. Yes, it works as read-only iso9660 because is a live distro. The case that concerns us is for example Kaspersky Rescue Disk [1], but the same applies to Super GRUB2 Disk [2], Rescatux [3] and any other GRUB bootable CD.

If these live distros were ISOLINUX based there would be no problem because ISOLINUX comes with
two hybrid versions of MBR code: isohdpfx.bin and isohdppx.bin.

The first one is what live distros normally uses (that's the same as running isohybrid over the resulting ISO image). This way we can burn the image to some optical media or dump it to a device,
e.g. /dev/sdd.

The latter, isohdppx.bin, the same as running isohybrid -partok, is also an MBR code which converts an iso9660 bootable image to hybrid, so it can be dumped to a device _but_inside_a_partition_, e.g. /dev/sdd3.

That way all linux distros which uses ISOLINUX can become bootable _from_a_partition_, but GRUB2 distros like Kaspersky, Super GRUB2 Disk, Rescatux and others don't, because boot_hybrid.img code from GRUB2
seems not supporting booting from a partition.

Steps to test:

# dd if=/dev/null of=test.bin bs=1M seek=300
# losetup /dev/loop0 test.bin

Run fdisk to create the partition:

# fdisk /dev/loop0

create the first partition with the whole space and make it bootable, save and exit.

Check if /dev/loop0 is now partitioned:

# ls -l /dev/loop0p1

if not, we should apply these additional steps: :-)

# losetup -d /dev/loop0
# rmmod loop
# modprobe loop max_part=15
# losetup /dev/loop0 test.bin
# ls -l /dev/loop0p1

Now we have a partitioned loop device. We'll install a generic MBR (provided by SYSLINUX or by 'mbr' package)

# dd if=/usr/lib/syslinux/mbr/mbr.bin of=/dev/loop0
# install-mbr /dev/loop0

Download SGD [2] , Kaspersky [1] or Rescatux [3]. All three are hybrid GRUB iso9660 images. Dump one of them into /dev/loop1p1

# cat [...].iso > /dev/loop1p1

Run under kvm or qemu. It will hang on "GRUB":

# qemu -hda /dev/loop1

Now download almost whatever live distro. We'll try with SLAX [4] because it is small:

# wget

Make it hybrid "partOK" and dump it into the partitioned device:

# isohybrid -partok slax-Russian-7.0.8-i486.iso
# cat slax-Russian-7.0.8-i486.iso > /dev/loop1p1

Test again with virtualization or emulation. It will show the SLAX splash welcome screen.

# qemu -hda /dev/loop1

Of course isohdppx.bin code and isohybrid binary are ISOLINUX specific, so we can't combine them with GRUB2. The problem here seems to be that GRUB2 boot_hybrid.img don't pass partition information to core.img because it wasn't designed to handle partitioned devices. Right?



All ISOLINUX images can become hybrid with isohybrid (or dumping
isohdppx.bin to its beginning), but GRUB2 images can't become hybrid in
the sense of booting also from a partition table; so it seems that
boot_hybrid.img from GRUB2 does not support this scenario, only for
images that were dumped to the beginning of a disk.

I did post a similar question in the SYSLINUX mailing list [1] asking if
a patch or workaround is possible in SYSLINUX but the answer was negative.

There is a solution for this scenario or indeed the boot_hybrid.img from
GRUB2 may be patched to support this?

As far as I can tell isohdppx.bin works only with Syslinux MBR code (and
same can be said about isolinux.bin). At the end we must know absolute
disk location and isohdppx.bin and isolinux.bin rely on Syslinux MBR to
pass partition information (most important, partition offset) to them. I
assume the same information is also passed by chainloader.

So while GRUB2 of course could be patched, it effectively means
reimplementing Syslinux and need to permanently keep it in sync with any

Can syslinux chainloader load more than 512 bytes? Then it /may/ be
possible to create small core.img which is placed after initial boot
block in system area. You would then load this core.img that will search
for suitable partition. Actually this core.img can be located anywhere
on image, it is just that placing it in system area makes it easier to find.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]