[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: Andrei Borzenkov
Subject: Re: Booting El Torito image from a partition table
Date: Sat, 28 Nov 2015 10:50:35 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

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?

> 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]