Your message dated Tue, 15 Mar 2022 04:04:27 +0100
with message-id <[email protected]>
and subject line Re: Bug#995332: Package reinstalls/upgrades with files on FAT
partitions fail
has caused the Debian Bug report #995332,
regarding Package reinstalls/upgrades with files on FAT partitions fail
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
995332: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995332
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: dpkg
Version: 1.20.9
I recognised just recently that dpkg is not able to gracefully replace
files on FAT partitions, e.g. when reinstalling or upgrading a package.
It seems to try creating a file link as backup, while FAT does not
supports links:
-------
unable to make backup link of './path/to/file' before installing new
version: Operation not permitted
-------
This seems to be an expected behaviour, at least I found multiple cases
where e.g. SBC OS images are shipped with a dedicated /boot FAT
partition, and measures have been taken to remove existing files from
/boot before kernel upgrades or via dpkg-divert loops.
Of course Debian is a Linux distribution and the root filesystem needs
to support UNIX permissions, symlinks and hard links (?) for the system
to function properly, but it is not uncommon to mount FAT partitions
into the system, especially using a FAT partition for /boot is required
for some ARM SBCs to boot and beneficial otherwise to allow fixing boot
configuration issues or pre-configuring the system as well from Windows
or macOS systems.
So my question is whether it wouldn't be feasible to handle the
replacement of package files on FAT partitions (and other filesystem
types with no link support) gracefully. A backup could be created
differently if this is seen mandatory.
Best regards,
MichaIng
--- End Message ---
--- Begin Message ---
Hi!
On Mon, 2021-10-04 at 13:33:22 +0200, MichaIng wrote:
> 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.
As mentioned on the FAQ, modern EFI base systems use FAT32 partitions,
and those are handled properly by the current kernel hooks. In
addition this should be way safer than letting dpkg handle the
installation. Consider that dpkg would unpack the kernel, but the
initramfs would not have been generated yet, which would render the
system unbootable for a longer period of time. So generating the
initramfs via a kernel hook, and then installing both (overwriting old
versions if need be), should be way safer than the alternative.
> 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.
That reading looks a bit like cheating though. I'd expect that
"Preserving human configuration" for something that is explicitly listed
as unsupported would not be presumed to be included there. :)
> 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 :).
Yeah, I'm doing that now.
Thanks,
Guillem
--- End Message ---
