[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libcdio-devel] libcdio tools cannot read multi-exent files with Jol

From: Pete Batard
Subject: Re: [Libcdio-devel] libcdio tools cannot read multi-exent files with Joliet exensions on
Date: Sun, 26 Jun 2022 09:46:20 +0100
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0

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

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

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]