Writing a xorriso-modified ubuntu image fails with 'ISO image extraction failure' on v4.5, but succeeds with <v4.5

[dseeley]

Writing a xorriso-modified ubuntu image fails with 'ISO image extraction failure' on v4.5, but succeeds with from rufus.

[pbatard]

Oh and for those who might wonder why older versions of Rufus worked, it's simply because we didn't process and try to extract El-Torito boot records then. And I'll grant that this content does not technically need to be extracted to create bootable media when using Rufus' ISO mode, but one of the goal of Rufus is to provide as much as the original data as we can, which is why we decided to start extracting these records (and some ISOs <cough>Mint<cough> do require us to actually pick some content from the El-Torito images, so we have to process these records, which we'll expect to be valid anyway).

[pbatard]

OK, I'll close this issue then. But you will still be able to comment on it if needed.

[dseeley]

OK - Thank you for investigating. I'll see what options are available.

[pbatard]

I'm afraid that I'm going to need access to an ISO that can replicate the issue to investigate this (I am not going to attempt to recreate an ISO, as there are too many environmental elements that could make it fail to replicate the issue and I'm afraid I don't have the luxury to invest time trying to replicate an image).

So can you please upload a problematic ISO somewhere on a file sharing site?

If you don't want to make it public, you can email me the link privately to: [email protected].

Also, the fact that you use -indev ubuntu-24.04-live-server-amd64.iso to modify an existing ISO rather than create one from scratch, could indicate that this may be an issue with xorisso not properly updating the El-Torito bootloaders rather than an issue with Rufus (as Rufus 4.5 is now a bit more stringent about ISO-9660 compliance).

[dseeley]

Thank you for looking - I'll send a link.

[pbatard]

Thanks for sharing your ISO.

From looking at it, it would seem that the root of the issue is that it wasn't mastered properly.

If we look at the El Torito Section Entry for the problematic boot image (at address 0x096860 in your ISO), and broken into the relevant fields, we get:

88 00 0000 00 00 9C27 6E791400 00 00000000000000000000000000000000000000

The first bunch of fields are not directly relevant, but then we get to the 9C27 6E791400 part.

6E791400 (Little-Endian) translates to 0x0014796E which is 1341806 in decimal, a.k.a. the address (or LSN in ISO-9660 parlance) of the first ISO-9660 2408-byte block where the bootable image data should be read. So that tells us that the 1-boot-noemul.img bootable image starts at byte 1341806 x 2048 = 2,748,018,688 of your 2,748,383,232-byte ISO. So far so good.

Then 9C27 (Little-Endian) translates to 0x279C which is 10140 virtual image sectors of 512 bytes, which now tells us that the bootable image should be exactly 5,191,680 bytes in size.

However, when you add this all up, it so happens that your El-Torito boot records declares a bootable image starting at 2,748,018,688 and ending at byte 2,748,018,688 + 5,191,680 - 1 = 2,753,210,367 of your 2,748,383,232-byte ISO.

And therein is your problem. 2,748,018,688 + 5,191,680 is greater than 2,748,383,232. In its present state, your ISO declares a bootable image that goes past the actual size of the ISO!

Now, there is some software out there (e.g. 7-zip) that will just ignore such an overflow, and truncate the bootable image if it reaches the end of the ISO file. But Rufus (and other software that do attempt to respect the El Torito specs) don't. So you will have to fix your ISO, because, from where I stand, the root of the issue is that your ISO is not ISO-9660/El-Torito compliant in the first place, and if you want to interoperate with other software, you want to address that.