Re: [OE-core] [PATCH] udev-extraconf: Allow optionally skipping systemd-fsck

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Mon, 2025-05-12 at 18:16 +0000, Mark Jonas via
lists.openembedded.org wrote:
> Hi Joshua,
> 
> 
> > > From: Ricardo Simoes <ricardo.simoes@pt.bosch.com>
> > > 
> > > When the fsck backend does not respect the exit codes predefined
> > > by
> > > fsck, systemd-fsck might not work as expected.
> > > 
> > > This is the case for fsck.fat from dosfstools [1]. When a FAT
> > > formatted and write protected partition is checked with fsck.fat
> > > it
> > > will terminate with exit code '6' [2]. What fsck.fat wants to
> > > signal
> > > is that a write protected device cannot be checked. However, that
> > code
> > > is interpreted by systemd-fsck as a bit mask:
> > > 
> > > - 2: System should be rebooted
> > > - 4: Filesystem errors left uncorrected
> > > 
> > > As a practical example, a write-protected, FAT formatted SD-card
> > will
> > > not be mounted in this case.
> > > 
> > > This patch introduces the environment variable
> > SKIP_SYSTEMD_MOUNT_FSCK.
> > > When SKIP_SYSTEMD_MOUNT_FSCK exists systemd-mount will be called
> > with
> > > the --fsck=no option. Thus, the partition will be mounted without
> > > running systemd-fsck.
> > > 
> > > In general, this new feature is useful when the filesystem is
> > > known
> > to
> > > be clean and the fsck backend does not respect the exit codes.
> > > 
> > > Finally, one way to use this new feature would be to add
> > > ENV{SKIP_SYSTEMD_MOUNT_FSCK}="1" to the udev rule calling the
> > > mount
> > > script.
> 
> 
> > This is a pretty generic work around for a very specific problem in
> > dosfstools. It would probably be better to patch dosfstools to have
> > the expected error codes instead.
> 
> You are right. We also thought at first that we should fix the
> problem in dosfstools. But the project appears to be abandoned. The
> last commit in the repository is from October 2023. And the last
> closed issue is from August 2023. Lastly, there is an issue which
> sounds as if the maintainer lost access to the repo
> (https://github.com/dosfstools/dosfstools/issues/210). But the
> maintainer(s) did not even reply.
> 
> Instead of fixing the problem upstream we could of course also add a
> patch to the meta-layer. But the patch would be rather big because
> the overall exit code generation is spread over the code. There is
> more to fix than only this single situation to make dosfstools adhere
> to the fsck standard return codes.
> 
> We would definitely not be able to maintain a fork of dosfstools.
> 
> How else could this be handled?

I think we should probably carry a patch to dosfstools until the
upstream situation gets resolved. I don't like doing that but
ultimately it will lead to a better end result. It is likely other
distros would be interested in such a patch too.

Attaching that patch to the github dosfstools so there was a patch
ready would also increase the chances of it merging too.

Cheers,

Richard