Pete Batard

But I'm note sure what is based on. Is it Zero based? If it's the same field as the one in PVD, it should be the size of the volume, in logical sectors (i.e. in blocks of 2048 bytes). Not sure what you mean by zero based, but no, an ISO volume occupying 10 blocks would not have 9 in that field, it would have 10. So this field can be used like an LSN/RBA to tell us the virtual LSN/RBA of a subsequent El Torito image, if there was any, when expanding per the UEFI specs. And we can have many descriptors....

I don't remember iso format details. So it's difficult for me to change something in that code. Well, as far as I can see, this should be mostly around this section of the 7-zip code (sorry for using a GitHub mirror, but I couldn't find a repo here). What way we can detect that we must increase size of file to full image size? This is something I have recently added to libcdio, most specifically in this section (and while the code is GPLv3 licensed, since I am the author of these changes, I am happy...

I don't remember iso format details. So it's difficult for me to change something in that code. Well, as far as I can see, this should be mostly around this section of the 7-zip code (sorry for using a GitHub mirror, but I couldn't find a repo here). What way we can detect that we must increase size of file to full image size? This is something I have recently added to libcdio, most specifically in this section (and while the code is GPLv3 license, since I am the author of these changes, I am happy...

For completion, I'll point out that if you want to generate an ISO yourself using xorriso, you can follow these instructions.

32MB+ ISO-9660/El-Torito images, as defined by the UEFI specs, are not supported

Well, considering that a fix for this issue has now "magically" appeared in https://github.com/rhboot/gnu-efi/commit/9e6cb2150bee08e83ec0cdfb8d6c2f83975dd3df, which has been integrated into gnu-efi, and that none of the people responsible for the regression bothered to notify about this fix in the original bug report, I guess I'm going to entitle myself to some further snide remarks by pointing out what a nice "rolling the software forwards" this has been, when it looks like none the 3+ developers...

Just going to add that on a vanilla Ubuntu 23.04 system (that was released a couple weeks ago and is recent enough to come with binutils 2.40), the default gnu-efi apps are still broken. apt install git build-essential gcc-aarch64-linux-gnu git clone https://git.code.sf.net/p/gnu-efi/code gnu-efi cd gnu-efi aarch64-linux-gnu-objcopy --version # reports: "GNU objcopy (GNU Binutils for Ubuntu) 2.40" export CROSS_COMPILE=aarch64-linux-gnu- make apps Trying to run the resulting t.efi (a simple "Hello,...

Yes, my statement is imposing. First of all, you are being singled out here because you are the author of the commit that broke compatibility. And I'm also seeing two major things that one should fully expect to have seen happening from a BREAKING change (or at least one that you rightfully expected/knew would break compatibility with older platforms): Trying to detect the binutils version of support for whatever newer option you need as part of the build process, and only use the new approach in...