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