Re: Bug#1031696: Use of symbolic links in non-free ISO images breaks file system transposition support
Hi James,
On 2023.03.15 00:47, James Addison wrote:
The problem, in both cases, was that I hadn't copied the '.disk' dotfile
directory from the install media ISO filesystem(s) in each case.
Ah, yes, the infamous '.disk/' directory.
If it's any consolation, you're not the first person to stumble on that
one when creating boot media using FST [1].
That caused this check to fail: https://sources.debian.org/src/cdrom-detect/1.102/debian/cdrom-detect.postinst/#L24
Indeed, Debian Installer identifies the installation media by looking
for a specific file in .disk/.
At this stage, since I believe it is relevant to this bug, I am going to
point out that, with GRUB also having recently pushed a fix that aims at
improving FST support [2], GRUB is going to follow Debian's lead in also
looking into a .disk/ directory to locate the boot media (by searching
for a '/.disk/<TIMEBASED_UUID>.uuid' file created by grub-mkrescue
during the ISO mastering process -- and yes, in case you wonder, we did
test that this new additional disk/ content is properly merged with
existing .disk/ data, if any is provided).
This means that, even if (as I understand it) Debian is not currently
using grub-mkrescue to generate its ISOHybrid images, those .disk/
directories are likely to be used by more than Debian moving forward,
and it is of course quite unfortunate that some OSes do treat dot
directories as hidden (for the record, Windows' File Explorer does *not*
hide them), which adds a potential hurdle for some users, whereas this
is all part of an effort to make the process of creating boot media
easier for people who may prefer an alternate way of doing so...
I am not sure who started to use .disk/ to store potentially important
installation media metadata (I can see that Ubuntu have been using it
since at least release 16.x, Mint since release 12.x, though I haven't
looked further than that) but I'm afraid that it has now become a
de-facto standard, that we have to contend with one way or another...
With that testing confirmed, I've regained confidence in the fix (although
would still appreciate independent verification).
If the fix finds its way into the testing images, I should be able to
also validate the changes soon-ish. If not, I'll see if I can build my
own ISOs to test this.
Regards,
/Pete
[1]
https://forums.raspberrypi.com/viewtopic.php?t=282839&sid=b7ef0bae203269b187c25b3a4b7247dd&start=25#p1763629
[2] https://lists.gnu.org/archive/html/grub-devel/2022-12/msg00222.html
Reply to: