Re: [PATCH] core/partmap: Add El Torito boot catalog parsing

[Ross Lagerwall <rosslagerwall@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4995 bytes --]

On Mon, Jun 08, 2015 at 08:50:48PM +0300, Andrei Borzenkov wrote:
> В Mon, 8 Jun 2015 18:31:06 +0100
> Ross Lagerwall <rosslagerwall@gmail.com> пишет:
> 
> > On Mon, Jun 08, 2015 at 07:51:44PM +0300, Andrei Borzenkov wrote:
> > > В Sun,  7 Jun 2015 11:24:46 +0100
> > > Ross Lagerwall <rosslagerwall@gmail.com> пишет:
> > > 
> > > > Add a module, part_eltorito, to allow parsing of the El Torito boot
> > > > catalog into partitions. This follows the El Torito Bootable CD-ROM
> > > > Format Specification Version 1.0 and the UEFI Specification 2.5.
> > > > In cases where the specification is unclear, the code follows the UEFI
> > > > reference implementation.
> > > > 
> > > > This is useful when booting CDs in UEFI mode. Before, GRUB would not be
> > > > able to use the embedded ESP from which it was executed, so it would
> > > > have a root and prefix set to the top level of the CD. This could result
> > > > in subtle configuration bugs, because the same ISO booted from a USB
> > > > disk (using isohybrid) would have its root and prefix set to the
> > > > embedded ESP because it can find it through the MBR.
> > > 
> > > You can already access ESP on hybrid image using e.g. (cd0,msdos1); why
> > > is it not enough?
> > 
> > This is about booting a CD in UEFI mode; it may not be a hybrid disc in
> > which case it doesn't have an MBR.
> > 
> 
> So you need to either add partition label or add additional driver to
> grub.efi. The former works already and does not require any new code.
> 
> > Also, in the case of a hybrid image booted using a CD, the mismatch between
> > the 2048 byte sectors of the CD and the 512 byte sector values used in the
> > MBR means that GRUB is not able to access the correctly ESP anyway.
> > 
> 
> It may depend on how you create partition table. Neither openSUSE DVD
> nor images created by grub-mkrescue have problems. Did you actually try
> it?
> 
> As example
> 
> bor@opensuse:~/src/grub> xorriso --indev /datastore/iso/openSUSE-13.2-DVD-x86_64.iso --report-el-torito plain --report-system-area plain
> xorriso 1.3.8 : RockRidge filesystem manipulator, libburnia project.
> 
> xorriso : NOTE : Loading ISO image tree from LBA 0
> xorriso : UPDATE : 6102 nodes read in 1 seconds
> xorriso : NOTE : Detected El-Torito boot information which currently is set to be discarded
> Drive current: -indev '/datastore/iso/openSUSE-13.2-DVD-x86_64.iso'
> Media current: stdio file, overwriteable
> Media status : is written , is appendable
> Boot record  : El Torito , MBR isohybrid cyl-align-off
> Media summary: 1 session, 2284287 data blocks, 4461m data, 31.5g free
> Volume id    : 'openSUSE-13.2-DVD-x86_640051'
> El Torito catalog  : 20  1
> El Torito images   :   N  Pltf  B   Emul  Ld_seg  Hdpt  Ldsiz         LBA
> El Torito boot img :   1  BIOS  y   none  0x0000  0x00      4        5826
> El Torito boot img :   2  UEFI  y   none  0x0000  0x00      1         896
> El Torito img path :   1  /boot/x86_64/loader/isolinux.bin
> El Torito img opts :   1  boot-info-table isohybrid-suitable
> El Torito img path :   2  /boot/x86_64/efi
> System area options: 0x00000202
> System area summary: MBR isohybrid cyl-align-off
> ISO image size/512 : 9137148
> Partition offset   : 0
> MBR heads per cyl  : 0
> MBR secs per head  : 0
> MBR partition table:   N Status  Type        Start       Blocks
> MBR partition      :   1   0x00  0xef         3584         8064
> MBR partition      :   2   0x80  0x17        11648      9126528
> MBR partition path :   1  /boot/x86_64/efi
> bor@opensuse:~/src/grub> 
> 
> You may consider using xorriso to create image, it does quite good job
> with hybrid images.

Yes I have tried, and I made a video of it :-)
https://rossl.org/junk/grub.webm

See that GRUB is not able to access (cd0,msdos2), which is the embedded
FAT partition.

> 
> > For these reasons, I think it is useful to parse the El Torito boot
> > catalog.
> > 
> 
> I'm not entirely opposed to it, I just do not see compelling reasons to
> do it :)
> 
> I actually think that viewing ESP as opaque binary executable and using
> ISO as primary data location is more generic and useful. This way you
> can have any amount of different platform binaries all sharing common
> /boot/grub on ISO with common configuration. Also information in El
> Torito boot image (as grub.cfg) is not as easily accessible as
> information on ISO. Making it hard to understand what image actually
> does.
> 

Except that the ESP isn't a binary executable, the firmware presents it
as a file system and gives it to GRUB as the boot location.

As it currently stands, the configurations are not shared, because
currently when booting the image using a CD it will look for the cfg at
(cd0)/..., and when booting the same image off a USB, it will look at
the FAT partition (hd0,msdos2)/... because it knows how to find it.

Cheers,
-- 
Ross Lagerwall

[-- Attachment #2: Type: application/pgp-signature, Size: 213 bytes --]