I agree with Andrei. El torito catalog contains bootable binaries. The fact that this binary follows FAT format is purely tangential and we should not put additional files there or access it either
Le 20 juin 2015 13:17, "Ross Lagerwall" <
address@hidden> a écrit :
On Mon, Jun 08, 2015 at 10:01:17PM +0300, Andrei Borzenkov wrote:
> В Mon, 8 Jun 2015 19:25:12 +0100
> Ross Lagerwall <address@hidden> пишет:
>
> > On Mon, Jun 08, 2015 at 08:50:48PM +0300, Andrei Borzenkov wrote:
> > > В Mon, 8 Jun 2015 18:31:06 +0100
> > > Ross Lagerwall <address@hidden> пишет:
> > >
> > > > On Mon, Jun 08, 2015 at 07:51:44PM +0300, Andrei Borzenkov wrote:
> > > > > В Sun, 7 Jun 2015 11:24:46 +0100
> > > > > Ross Lagerwall <address@hidden> пишет:
> > > > >
> > > > > > 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
> > >
> > > address@hidden:~/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
> > > address@hidden:~/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.
GRUB calculates a boot device based on the device path given by the
firmware so:
With a normal CD, the firmware gives it something like
/ACPI(a3401d0,0)/PCI(1,1)/ATAPI(0,0,0)/CD,1,899,1838) which points to
the embedded ESP. GRUB doesn't know how to use that because it doesn't
know how to read the El Torito catalog so it just uses the root of the
CD as the boot device, i.e. (cd0), so the prefix becomes
(cd0)/path/to/grub.
With a hybrid USB, the firmware gives it something like
/ACPI(a3401d0,0)/PCI(1,1)/ATA(0)/HD(1,MBR,0x769FCE30,172,63488) which
GRUB finds and matches with the embedded ESP pointed to by the MBR e.g.
(hd0,msdos2), so the prefix becomes (hd0,msdos2)/path/to/grub. In other
words, the image will _not_ look at the same place whichever way it is
booted.
While Thomas's suggestion [1] does work around the issue, I think
reading the catalog is a better-engineered solution.
[1]:
"A user once explained me his setup and mentioned
he runs grub-mkimage with "--config=", "iso9660" and
and that the "embedded grub.cfg" looks like
search.fs_label RECOVERY root
set prefix=($root)/boot/grub"
Regards
--
Ross Lagerwall
_______________________________________________
Grub-devel mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/grub-devel