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

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

On Wed, 2025-05-14 at 15:20 +0000, Jonas Mark (BT-FS/ENG1-Mue) wrote:
> Hi Richard,
> 
> > > > > 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
> > t
> > > 
> > hub.com%2Fdosfstools%2Fdosfstools%2Fissues%2F210&data=05%7C02%7Cmar
> > k.j
> > > 
> > onas%40de.bosch.com%7C366c7afff6bf4fdb0e9e08dd91fa9948%7C0ae51e1907
> > c84
> > > 
> > e4bbb6d648ee58410f4%7C0%7C0%7C638827227685038915%7CUnknown%7CTWFpbG
> > Zsb
> > > 
> > 3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFO
> > Ijo
> > > 
> > iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=TjSjj9oZY%2FF6bshgCGRu
> > acv
> > > mS4B6Tatxhs28iLyT%2BWw%3D&reserved=0). 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.
> 
> We looked into dosfstools. For a complete fix of fsck.fat many places
> with direct calls to exit() need changes. On top, some of that code
> is shared between fsck.fat and other tools. And we are under the
> impression it would not desirable to change the exit codes of these
> tools, too. For example, the fixing the very problem which triggered
> us would also change the return code of the fatlabel tool. On top,
> just a simple change of the exit code would be "half wrong" because
> the point where the exit is called does not exactly represent fsck
> "fs left uncorrected" but is even hit when the fs is checked but does
> not need fixing because it is just fine. But on a write-protected fs
> the error occurs before the checking.
> 
> see src/io.c line 63
> https://github.com/dosfstools/dosfstools/blob/289a48b9cb5b3c589391d28aa2515c325c932c7a/src/io.c#L63
> 
> Taking into account the time we have at hand and the complexity of
> the undertaking we do not see ourselves in the position to supply a
> proper fix for fsck. That is, dosfstools issue #89
> (https://github.com/dosfstools/dosfstools/issues/89) cannot be
> tackled by us.

I would probably suggest just changing fatlabel too, I think the fsck
exit codes are much more important. As long as it is documented in
release notes, I'd hope that would be ok.

A quick count shows 33 exit codes in the dosfsutils sources so there
aren't that many.

The trouble is if I take a workaround, this is never going to get fixed
and the issues will just compound over time. I'm therefore still not
really wanting to work around it, particularly as other systems will be
similarly affected, not just us.

Failing that, could there be a wrapper added around the tool to convert
to the right exit codes?

Cheers,

Richard