Hi,
many thanks for your reply and linking that FAQ, this clarifies things.
I also found the linked older bug report about the very same question:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825945
I personally would prefer more compatibility here, possibly combined
with a flag to confirm direct overwrite of files without backup link.
The benefit of a FAT /boot partition is precisely that it is easily
possible to access and fix it from other OSes, so the acknowledged risk
of an unbootable system in case of a power loss during file writes is
somehow covered by the very reason why one chose such a partitioning.
As said, there is hardware which simply requires the boot partition to
be FAT, and the workarounds for this dpkg limitation force package
maintainers/admins to use much riskier methods, like removing all
existing kernel files via kernel preinst hook, which extends the time
frame significantly in which a power loss would render the system
unbootable, compared to having that risk during individual file write
only. Common reasons on such systems for being unbootable are not
because of a failed package install or power loss, but because of the
kernel or bootloader or initramfs itself being faulty, falsely generated
or falsely configured and in such case it is very helpful if the
filesystem can be accessed and fixed from e.g. Windows or macOS.
Just to clarify: I know this mostly from ARM SBCs, which are currently
still mostly shipped with a manufacturer or 3rd party kernel and
bootloader (not the Debian ones) and a /boot FAT partition is either
strictly required by the hardware or explicitly chosen by the image
provider, for mentioned reasons, despite the difficulties with dpkg. If
dpkg would support FAT, it would lower the risk of kernel package
installs on those systems.
In the FAQ it is mentioned
> As part of the dpkg credo, preserving human configuration is of
utmost importance
and one could see a FAT partition mounted into root as a human
configuration decision, despite the obvious downsides and limitations of
FAT. And the question is whether this decision itself is seen as the
bigger risk, or the workarounds done to cover the missing dpkg support
for it.
However, I see that this is a long done design decision, I fully
understand the reasons behind it and the chance to change that hence
being close to zero. So yes feel free to close the issue :).
Best regards,
Micha
