Bug#1008842: exfat-fuse does not provide exfat filesystem driver

[MichaIng]

Package: exfat-fuse
Version: 1.3.0-2

Since Debian Bullseye (also tested on Bookworm), the exfat-fuse package
does not provide the (FUSE-based) "exfat" filesystem driver, i.e. the
following commands fail if the exfat kernel module is not present, e.g.
when a different kernel is used, often the case with ARM SBCs:
-------
mount <exfat_filesystem_device> <mountpoint>
mount <mountpoint> # with related "exfat" entry in /etc/fstab
mount -t exfat <exfat_filesystem_device> <mountpoint>
-------

Until Buster, when the exfat filesystem type is detected or passed via
mount option, the FUSE driver is automatically invoked, since Bullseye
one needs to pass "exfat-fuse" as filesystem type explicitly, since
autodetection, as well as blkid and lsblk, still detect "exfat".

While it makes sense, respectively the FUSE driver for exFAT is obsolete
with a recent Linux version, including the Debian kernel on Bullseye, it
is not too uncommon that other older kernel versions are used,
especially on embedded devices, ARM SBCs etc where manufacturers enable
additional features, not present in upstream Linux yet, respectively not
present in the Linux version shipped with Debian Bullseye yet. So
generally it would be nice if "exfat-fuse" did enable mounting exFAT
drives as "exfat", like it did before. But of course when the native
exfat kernel module is present, it should be preferred.

The other option would be to have lsblk/blkid/mount detecting the
filesystem type as "exfat-fuse" instead of as "exfat", when the kernel
module is not present but "exfat-fuse" installed. But this wouldn't
cover cases where e.g. a Buster system with older non-Debian kernel and
explicit "exfat" fstab entry is upgraded to Bullseye.

I hope there is a way to keep exfat-fuse fully backwards compatible.

Related is that the package does not provide mount.exfat anymore, but
mount.exfat-fuse only. Probably a dpkg-alternative or postinst script
provided symlink could re-enable backwards compatibility. But an open
issue remains that "exfatprogs" does not provide mount.exfat either, so
I guess mounts would then keep invoking FUSE (using mount.exfat =>
mount.exfat-fuse) even if the kernel module + exfatprogs are installed
as well. A conflict between exfatprogs and exfat-fuse could then help
solving it, like it exists for exfat-utils.

Best regards,

Micha

[Sven Hoexter]

severity 1008842 wishlist
tags 1008842 wontfix
thanks

On Sat, Apr 02, 2022 at 05:07:06PM +0200, MichaIng wrote:

Hi,

> Since Debian Bullseye (also tested on Bookworm), the exfat-fuse package does
> not provide the (FUSE-based) "exfat" filesystem driver, i.e. the following
> commands fail if the exfat kernel module is not present, e.g. when a
> different kernel is used, often the case with ARM SBCs:

I gave my best and made sure the release notes have a pointer on how to
continue to use exfat-fuse if you insist to use it:
https://www.debian.org/releases/bullseye/amd64/release-notes/ch-whats-new.en.html#exfat-in-linux-kernel

It's also in the NEWS file of the package, e.g.
zless /usr/share/doc/exfat-fuse/NEWS.Debian.gz
on a system with exfat-fuse installed.


The decision tries to reflect what is the best default option for
a majority of our users. I do not plan to put additional work into
the current packaging to support some fringe cases. Holding me back
from a full removal of the fuse driver are some special cases of date
conversion, which seem to be only supported by the fuse driver at the
moment. Though that code is not released yet, that is why the current
Debian package contains a snapshot.

My focus is on providing exfatprogs and the Linux driver. I do not
believe Debian should support two implementations for this 3rd party
filesystem. My personal believe is also that people should not run
outdated and unsupported kernel versions. If you feel like doing so
all bets are off anyway, and creating yourself a symlink to get the
desired behaviour back is the smaller issue.

Sven

[MichaIng]

I would also love to be able to ship recent Linux versions in all cases,
but as of sadly common practice of many SoC and SBC manufacturers, to
not produce open source hardware/firmware/drivers, and to provide own
outdated kernel versions with driver and firmware blobs instead of
contributing those upstream in the first place, often SBCs are not
(fully) functional with upstream and Debian Linux versions.

However, I fully understand the decision to not put efforts in
"supporting" this manufacturer behaviour.

Interesting is, that I now successfully solved it by creating the
/sbin/mount.exfat => mount.exfat-fuse symlink. I though I tested this
already, without success. That seems sufficiently simple. When the
kernel modules becomes available later and exfat-fuse it purged, even
leaving the symlink pointing to nowhere in place does not break mounting
exfat filesystems with the native Linux driver, so it is quite save to
create it, when stuck with an old Linux version:

-------
ln -s mount.exfat-fuse /sbin/mount.exfat
-------

Best regards,

Micha

[Sven Hoexter]

On Sat, Apr 02, 2022 at 07:24:41PM +0200, MichaIng wrote:

Hi,

> I would also love to be able to ship recent Linux versions in all cases, but
> as of sadly common practice of many SoC and SBC manufacturers, to not
> produce open source hardware/firmware/drivers, and to provide own outdated
> kernel versions with driver and firmware blobs instead of contributing those
> upstream in the first place, often SBCs are not (fully) functional with
> upstream and Debian Linux versions.

May I ask what your userbase is actually doing with the exFAT support on those
assumingly older SBCs which are limited to old kernels? I usually see exFAT on
removable media for video or image data. Since the fuse driver is slow and
high on CPU usage, it must perform horribly on those devices. I would avoid
a fuse driver on those devices, and if possible, use something more sensible
like ext4 or try to stick to vfat.

I'm just wondering if it's worth to keep exfat-fuse for another Debian stable
release or not. Right now it's a rather low maintenance effort.

Sven

[MichaIng]

I'm not sure about the exact reasons why these users use exFAT. When
aiming to mount a filesystem on Windows as well, NTFS performs just as
bad and vfat has file and filesystem size limitations, so I can imagine
cases where one needs to stick with exFAT.

Some of the SBCs have a quite powerful CPU, like the RK3399 SoC, being
used on SBCs where the manufacturer ships Linux 4.4 with official
images. And/or the drive may be used as backup/data grave only, where
performance doesn't matter that much. In this particular RK3399 case we
use mainline kernel in the meantime, but some users have the old image
in use and a kernel upgrade is not easily possible without flashing new
bootloader an in cases even a different partitioning is required
(dedicated boot FAT partition vs single ext4 root+boot partition) etc.

Since native exFAT support came with Linux 5.10, i.e. not being so old,
I suggest to keep exfat-fuse for at least Debian Bookworm, if
maintenance effort is not that high. Not sure whether there are download
stats available for the APT packages, which would also be a good
indicator whether it's still much used or not?

Best regards,

Micha

[Sven Hoexter]

On Fri, Apr 08, 2022 at 07:59:34PM +0200, MichaIng wrote:

Hi,

> Since native exFAT support came with Linux 5.10, i.e. not being so old, I

It's already in 5.7, thought that might not change much because the first
Debian stable release kernel with support was 5.10. Probably similar for your
situation.

> suggest to keep exfat-fuse for at least Debian Bookworm, if maintenance
> effort is not that high. Not sure whether there are download stats available
> for the APT packages, which would also be a good indicator whether it's
> still much used or not?

There is popcon
https://qa.debian.org/popcon.php?package=fuse-exfat

The problem is that it doesn't tell you much about actual usage because
most users won't invoke the mount wrapper directly, and in the past
the package was installed a lot due to depedencies by desktop environments.

Similar is the data in the opposite direction if you look e.g. at exfatprogs
https://qa.debian.org/popcon.php?package=exfatprogs
It's on a steep rise since udisks2 got patched in a point release to prefer
it over exfat-utils, and all reverse depedencies in testing/unstabled got
changed.

If it's going to get in the way for e.g. a fuse3 migration
https://release.debian.org/transitions/html/fuse-to-fuse3.html
I might still drop it, otherwise I'll try to keep it for another cycle.

Sven