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" <rosslagerw...@gmail.com> 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 <rosslagerw...@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 <rosslagerw...@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 <rosslagerw...@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. > > 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 > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel > >
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
