Re: [Libcdio-devel] libcdio tools cannot read multi-exent files with Joliet exensions on

[Pete Batard]

On 2022.06.26 08:25, Thomas Schmitt wrote:
> > the Gentoo
> > people did make sure that they placed a duplicate of the ESP image content
> > on the ISO file system structure (Now, wouldn't it be *nice* if xorriso did
> > that on its own... ;))
>
> Wouldn't help if Gentoo hadn't thought of it, because they are still using
> mkisofs.

Good point, I hadn't seen that they weren't using xorriso.

On the other hand, and that's not to throw shade at xorriso because 
that's really a GRUB issue in the first place, that's probably why we're 
not running into the current pitfall of early UEFI boot breakage when 
extracting the ISO content to an NTFS partition, on account that 
grub-mkrescue, and by extension xorriso, was not being used to create 
this specific image...

> xorriso (1.5.5 in git) now has the proposed warning messages:
>
>    xorriso : WARNING : EFI boot equipment is provided but no directory /EFI/BOOT
>    xorriso : WARNING : will emerge in the ISO filesystem. A popular method to
>    xorriso : WARNING : prepare a USB stick on MS-Windows relies on having in the
>    xorriso : WARNING : ISO filesystem a copy of the EFI system partition tree.

Nice, but, as I pointed out, that "popular" method is not just for 
Windows and, in the context of trying to enlighten Linux distro 
maintainers about the pleas of their users, I see it as a bit reductive 
to present the issue as mostly a Windows centric problem, when it isn't.

As I pointed out on the GRUB mailing list, there can be major advantages 
to using the EFI file extraction method, even if you're using an OS 
where dd is easily accessible and is promoted as the default method of 
dealing with an ISOHybrid.

> My offer stands to add another warning line with the URL of a document
> which describes the needs of the unpacking method(s).

I appreciate that, and I'll get back to you on it off list. Haven't had 
a chance to do that yet due to prioritization (which is also the reason 
I needed to push a BETA of Rufus 3.19 on Friday, and not because there 
was a particularly important bug to fix).

> I would also be willing to adopt such a description for the docs of libisofs
> and GNU xorriso, if your license permits it.

As you probably guessed, I'm still seeing duplication of the ESP image 
content as something that xorriso should be doing, and just to give you 
an idea of what I'm now leaning towards when I get back to you off list 
(still no idea when I'll do that, as this xorriso matter is not that 
high on my current priority list right now) would be to enforce a 
2048-byte cluster size for the FAT image, since people are explicitly 
creating that image for xorriso and therefore have easy control over its 
parameters and last time I checked one can use a 2048 cluster size for 
FAT volumes up to at least 8GB in size. Then, instead of trying to 
extract and duplicate the files, xorriso should "simply" be able to map 
the existing FAT files into the ISO-9660 index, as (provided that there 
is no fragmentation of the FAT image, which would be another item that 
xorriso would need to checked) everything should be nicely laid out for 
it to do so.

Of course, I haven't looked at it in details, so maybe there's a major 
roadblock there. But if achievable, and despite the extra constraint it 
would push on the ESP image creation (with xorriso returning an error if 
the ESP image fed to it doesn't use a 2048-byte cluster size), I think 
this could be an elegant solution to the issue.

> > their build of GRUB 2.0 does include the ntfs module [...]
> > the boot kernel is still missing an NTFS driver,
>
> These and any other constraints should be documented in a quick-to-read
> manner.

Yup, I agree, and I have some vague plan to do just that when I can free 
up some time to deal with this specific matter.

Regards,

/Pete