Hi,
Pete Batard wrote:
> If you are
> going to set a EFI partition to a size of 0 or 1, then the image will occupy
> all sectors from the LSN to the end of the volume.
I understand that this was specified as a last resort because
- UEFI did not want to invent a new competitor to El Torito,
- the El Torito boot catalog only has 16 bits for the field which
describes the load size,
- and UEFI found no other field to express the size of the EFI System
Partition.
> Therefore, on systems that comply with the UEFI specs, that
> 1-boot-noemul.img image at sector 34 will actually include the data from the
> 0-boot-noemul.img at LSN 20514, and the size of the image that the system
> will process will be further extended by 2048 bytes... which makes me think
> that xorriso is somewhat abusing the UEFI specs.
The specs do not prescribe a particular sequence of boot images or their
position within the overall body of an ISO 9660 filesystem.
Sure, it would be better to have the oversized EFI image near the end of
the filesystem data range. This would reduce the trailing backpack that is
caused by the fallback prescription in UEFI specs.
But achieving that position would be up to the ISO producer. The reader
must not flatly assume it.
> Especially, as opposed to what Thomas stated in his other reply, nowhere
> does it states that: "The real size is the size of the FAT filesystem in
> such an image". Instead, UEFI is quite explicit that the real size is the
> size from the LSN to the end of the volume.
The size that matters is indeed the size of the FAT filesystem which
starts at the LBA which is given in the boot catalog.
The size which is spedified in UEFI for values 0 or 1 is just a coarse
workaround for a situation where the catalog format is insufficient and
where any EFI firmware can get a better size by looking into the FAT
filesystem.
Actually the exact partition size does not matter for a filesystem driver
as long as the partition is not smaller than the file system.
> So I'm going to ask Thomas, though I suspect the answer is "ISOHybrid
> tweaking", is: Why is xorriso is placing the images that way?
No isohybrid is involved in the proposed xorriso run.
The immediate reason for the sequence of file data content is in the
alphabetic order of the paths in the ISO:
/efi.img comes before /isolinux.bin .
(Reason is that ISO 9660 prescribes alphabetically sorted file names
directories. Putting the content in the same sequence gives fewer moves
of the CD read head when copying out the files in the sequence given in
the directory. Fewer moves = fewer clonks and better copy throughput.)
It is possible to influence this content sequence by the -as mkisofs
option --sort-weight. If you attribute a low weight to /efi.img then its
content will swim up to the end of the resulting filesystem.
$ xorriso ...options.used.in.40.MB.example... \
--sort-weight -1000000000 /efi.img
...
$ xorriso -indev test.iso -report_el_torito plain
...
El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA
El Torito boot img : 1 BIOS y none 0x0000 0x00 4 34
El Torito boot img : 2 UEFI y none 0x0000 0x00 0 54
El Torito img path : 1 /isolinux.bin
El Torito img opts : 1 boot-info-table
El Torito img path : 2 /efi.img
But it is tradition among Linux installation ISO producers to apply a
high weight to boot images in order to get their content to low block
addresses.
So expect the whole bulk of data file content to come after the content
of the boot images.
(Reason is probably an old bug of ISOLINUX which cleared a processor
register by 16 bit before it gets used as 32 bit. Previously the register
held the address of the legacy boot image. If that address is lower than
65536, then the high bits of the register are already 0 and nothing bad
happens.
Thus grow our urban legends and will influence the properties of ISO
filesystems long after the bug in ISOLINUX was fixed.)
> also have to state that modifying the current proposal to handle xorriso's
> way of placing the ESP is going to be problematic because for one thing,
The sequence of data files is by default the same as in mkisofs or
genisoimage:
$ genisoimage -v -o test.iso isolinux.bin efi.img
...
$ xorriso -indev test.iso -find / -exec report_lba --
...
Report layout: xt , Startlba , Blocks , Filesize , ISO image path
File data lba: 0 , 24 , 20480 , 41943040 , '/EFI.IMG'
File data lba: 0 , 20504 , 20 , 40960 , '/ISOLINUX.BIN'
Note the address numbers under "Startlba".
> so we're going to have to craft a new codepath
> for the non-compliant xorriso layout,
You just have to drop the assumption about the convenience of the position
of the EFI System Partition.
> I am very much trying to
> avoid having to sink time into full blown processing of platform id
I wonder why you are so opposed to expanding the if-construct
+ if (br[j].boot_id == 0x88 && br[j].media_type == 0) {
+ p_iso->boot_img[k].lsn = br[j].image_lsn;
+ p_iso->boot_img[k++].num_sectors = br[j].num_sectors;
+ }
to
+ if (br[j].boot_id == 0x88 && br[j].media_type == 0) {
+ p_iso->boot_img[k].lsn = br[j].image_lsn;
+ p_iso->boot_img[k++].num_sectors = br[j].num_sectors;
+ } else if (br[j].boot_id == 0x01 || br[j].boot_id == 0x90 ||
+ br[j].boot_id == 0x91) {
+ platform_id = br[j].media_type;
+ }
and to using the current value of platform_id for the further records
where br[j].boot_id == 0x88.
(Initialize platform_id to 0, if you do not want to rely on the
prescription that the first catalog record has br[j].boot_id == 0x01.)
It is not very helpful to a future code reader's understanding to call
the platform id byte of a Validation Entry "br[j].media_type".
But that is a consequence of the decision to load the bytes by a struct
and to have only one struct type for all catalog records.
New objection:
This reading by struct will probably give a byte-swapped result in the
.num_sectors fields if the program is run on a big-endian processor.
(Avoidable by reading the records as character array and interpreting
them byte by byte as described in the El Torito specs.)
> Finally, for the record, since I am also looking at what 7-zip does, it also
> happens that 7-zip has the same issue, i.e. it sees the 40 MB image as
> having a 0-byte size and cannot open or extract it.
I take this as opportunity to express my doubts that 7z is the best
paragon for an El Torito interpreter.
7z is not up to the real existing examples of Linux ISO 9660 installation
images. Not only by misinterpreting the size of an EFI image but also
by ignoring the important property "platform id" in its representation
as names of pseudo-files.
Possibly its El Torito code was not renewed since EFI appeared and only
expects legacy BIOS boot images.
Have a nice day :)
Thomas
