Re: Booting El Torito image from a partition table

[Emilio Lazo Zaia]

Hello Andrei. Thanks for your answer!

On 28/11/15 03:20, Andrei Borzenkov wrote:
> 28.11.2015 00:30, Emilio Lazo Zaia пишет:
> > Hello
> >
> > 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
or
# 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 http://www.slax.org/download/7.0.8/slax-Russian-7.0.8-i486.iso

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?

Emilio.

[1] http://support.kaspersky.com/viruses/rescuedisk#downloads
[2] 
https://forja.cenatic.es/frs/download.php/file/1844/super_grub2_disk_hybrid_2.02s3.iso
[3] http://www.supergrubdisk.org/rescatux/
[4] http://www.slax.org/download/7.0.8/slax-Russian-7.0.8-i486.iso

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