Package: non-free
Version: firmware-11.6.0
Not sure if this is something that should be sent to the official bug
tracker, since it's an issue with cdimage/unofficial/non-free, but I
would like to report that the current cd-including-firmware images, such
as 'firmware-11.6.0-amd64-netinst.iso' have a major issue in that,
unlike what is the case for the official Debian installation ISOs, such
as 'debian-11.6.0-amd64-netinst.iso', they do not support UEFI file
system transposition.
As a reminder, file system transposition means the ability to take the
content of a UEFI bootable media and copy it, at the file system level,
to a partition that was independently created and formatted by the user,
while preserving the ability of the resulting media to still boot in
UEFI mode (thus leveraging the cornerstone of UEFI, as opposed to BIOS,
which is the ability to create boot media by copying content at the file
system level rather than at the block level).
In short, the expectation of many UEFI users -- and I have to commend
Debian for having done a stellar job over the past few years to ensure
that this is properly supported with official ISOs through, for
instance, switching boot media detection to detecting the presence of a
specific file rather than looking for a specific partition label or UUID
-- is that they should be able to a USB media to FAT32 and then extract
the full content from the Debian ISO there, to end up with a media that
they can use to both boot and install Debian.
This method has the advantage of not relying on a specific utility to be
able to create the media (noting that even something as basic as 'dd' is
for instance not available on Windows platforms) to instead rely
entirely on the native tools provided by their OS, and that have the
advantage of usually coming with a GUI that users might also be more
comfortable with.
Now, the problem is that, when using file system transposition, one
cannot rely on symbolic links (such as the ones used by Rock Ridge on
top of an ISO9660 file system) to be preserved during ISO file
extraction, as, for instance, FAT32 has no support for them whereas it
is the file system most people are likely to use for UEFI file system
transposition.
Yet, the current '/firmware/' structure of
'debian-11.6.0-amd64-netinst.iso' is such that a file like:
'/firmware/amd64-microcode_3.20191218.1_amd64.deb'
is actually a symbolic link to:
'../pool/non-free/f/firmware-nonfree/firmware-amd-graphics_20210315-3_all.deb'
So this means that during file system transposition to FAT32,
'/firmware/amd64-microcode_3.20191218.1_amd64.deb' will either be lost
or contain invalid content, and the Debian installer, which is designed
to look into /firmware/... to look for packages, will be unable to
locate the firmware files that the people who chose to use
'firmware-11.6.0-amd64-netinst.iso' want it to be able to locate.
In short, whereas symbolic links are fine for non-critical things like
documentation, they should not be used for files that need to be located
by the debian installer, because doing so breaks file system
transposition support.
As such, we *strongly* recommend, for the sake of making the Debian ISOs
work for everyone (rather than only those who will copy the image
through dd, which is a subset of users), that, instead of having
'/firmware/xyz.deb' symbolic links pointing to
'../pool/non-free/x/xyz.deb', the reverse should be used, on account
that '/firmware/' is the directory where Debian-installer will be trying
to locate the firmware packages and therefore the physical files should
always reside there.
Or, even better, Debian should look into symbolic links altogether, as
they can not be relied on and are a source of trouble.
Regards,
/Pete
