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

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

[mark.jonas]

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.

[1] https://github.com/dosfstools/dosfstools/issues/89
[2] https://github.com/dosfstools/dosfstools/blob/v4.2/src/io.c#L63

Signed-off-by: Ricardo Simoes <ricardo.simoes@pt.bosch.com>
Signed-off-by: Mark Jonas <mark.jonas@de.bosch.com>
---
 meta/recipes-core/udev/udev-extraconf/mount.sh | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/meta/recipes-core/udev/udev-extraconf/mount.sh b/meta/recipes-core/udev/udev-extraconf/mount.sh
index 0cbae48729..d6de05f0b6 100644
--- a/meta/recipes-core/udev/udev-extraconf/mount.sh
+++ b/meta/recipes-core/udev/udev-extraconf/mount.sh
@@ -83,6 +83,10 @@ automount_systemd() {
 
     MOUNT="$MOUNT -o silent"
 
+    if [ -n "${SKIP_SYSTEMD_MOUNT_FSCK+isset}" ]; then
+        MOUNT="$MOUNT --fsck=no"
+    fi
+
     # If filesystemtype is vfat, change the ownership group to mount group, and
     # grant it with  w/r/x permissions.
     case $ID_FS_TYPE in
-- 
2.34.1

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

[Joshua Watt]

On Fri, May 9, 2025 at 3:44 AM <mark.jonas@de.bosch.com> wrote:
>
> 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.
>
> [1] https://github.com/dosfstools/dosfstools/issues/89
> [2] https://github.com/dosfstools/dosfstools/blob/v4.2/src/io.c#L63

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.

>
> Signed-off-by: Ricardo Simoes <ricardo.simoes@pt.bosch.com>
> Signed-off-by: Mark Jonas <mark.jonas@de.bosch.com>
> ---
>  meta/recipes-core/udev/udev-extraconf/mount.sh | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/meta/recipes-core/udev/udev-extraconf/mount.sh b/meta/recipes-core/udev/udev-extraconf/mount.sh
> index 0cbae48729..d6de05f0b6 100644
> --- a/meta/recipes-core/udev/udev-extraconf/mount.sh
> +++ b/meta/recipes-core/udev/udev-extraconf/mount.sh
> @@ -83,6 +83,10 @@ automount_systemd() {
>
>      MOUNT="$MOUNT -o silent"
>
> +    if [ -n "${SKIP_SYSTEMD_MOUNT_FSCK+isset}" ]; then
> +        MOUNT="$MOUNT --fsck=no"
> +    fi
> +
>      # If filesystemtype is vfat, change the ownership group to mount group, and
>      # grant it with  w/r/x permissions.
>      case $ID_FS_TYPE in
> --
> 2.34.1
>

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

[Jonas Mark (BT-FS/ENG1-Mue)]

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?

Cheers,
Mark

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

[Richard Purdie]

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

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

[Jonas Mark (BT-FS/ENG1-Mue)]

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%2Fgit
> >
> hub.com%2Fdosfstools%2Fdosfstools%2Fissues%2F210&data=05%7C02%7Cmark.j
> >
> onas%40de.bosch.com%7C366c7afff6bf4fdb0e9e08dd91fa9948%7C0ae51e1907c84
> >
> e4bbb6d648ee58410f4%7C0%7C0%7C638827227685038915%7CUnknown%7CTWFpbGZsb
> >
> 3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo
> >
> iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=TjSjj9oZY%2FF6bshgCGRuacv
> > 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.

Cheers,
Mark

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

[Richard Purdie]

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

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

[Jonas Mark (BT-FS/ENG1-Mue)]

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
> > > >
> > > (
[..]
> > > > 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
> >
[..]
> >
> > 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
> >
[..]
> qN199Aw%2FOtF6izexCFU%3D&reserved=0) 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.

If it is as easy as documenting this in the release notes it sounds way more doable.

We will look into it and probably come back with the result next week.

> 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.

We understand your role and responsibilities and thus accept this decision.

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

Yes, that would be possible, too. After looking at each of the individual exit() calls we should have a better idea of the feasibility as well.

Cheers,
Mark