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

[Andrei Borzenkov <arvidjaar@gmail.com>]

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

В Mon, 8 Jun 2015 19:25:12 +0100
Ross Lagerwall <rosslagerwall@gmail.com> пишет:

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

OK. What about using GPT? it definitely works, just tested.

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

Image created by grub-mkrescue looks at the same place whatever way it
is booted. You need to set prefix to ()/path/to/grub then it will be
auto-filled with correct boot device name.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]