systemd-fsck terminated by signal PIPE

[Fernando]

I have my Raspberry Pi 4 configured to perform a file system check to both the SDCard and my external HDD using an USB enclosure which is connected to one of the USB 3.0 ports. Here's the cmdline.txt file and /etc/fstab:

cmdline.txt
``
root=PARTUUID=77bc596e-02 rootfstype=ext4 fsck.repair=yes fsck.mode=force rootwait quiet
``

/etc/fstab
``
proc /proc proc defaults 0 0
PARTUUID=77bc596e-01 /boot vfat defaults 0 2
PARTUUID=77bc596e-02 / ext4 defaults,noatime 0 1
/var/lib/unifi/logs /var/log/unifi auto defaults,auto,nofail,users,rw,bind 0 0
PARTUUID=655db280-01 /mnt/disk ext4 defaults,auto,nofail,users,rw 0 2
/mnt/disk/media/jellymusic /home/ferferga/jellymusic auto defaults,auto,nofail,users,rw,bind 0 0
/mnt/disk/docker /var/lib/docker auto defaults,auto,nofail,users,rw,bind 0 0
``

However, the filesystem check for the HDD fails, with the following errors outputted to syslog, dmesg.log and journalctl -b:

```
systemd-fsck[308]: fsck terminated by signal PIPE.
systemd[1]: systemd-fsck@dev-disk-by\x2dpartuuid-655db280\x2d01.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: systemd-fsck@dev-disk-by\x2dpartuuid-655db280\x2d01.service: Failed with result 'exit-code'.
systemd[1]: Failed to start File System Check on /dev/disk/by-partuuid/655db280-01.
```

This was working correctly in Buster, but suddenly one day it stopped working: The fsck.ext4 process started running in the background until it finished but the drive wasn't mounted to /mnt/disk as it should.

I had no time at that moment to debug the issue and Bullseye was around the corner, so I decided to wait until Bullseye before re-enabling the filesystem check for the HDD. Yesterday, PiOS Bullseye was released and I re-enabled the filesystem check. Same problem as with Buster, so I decided to debug the issue.

After some digging using htop to see the startup process, I saw the following systemd-fsck processes running:

``
/sbin/fsck -y -T -l -M -f -C5 /dev/disk/by-partuuid/655db280-01
/lib/systemd/systemd-fsck /dev/disk/by-partuuid/655db280-01
fsck.ext4 -y -f -C5 /dev/sda1
``

Only ``fsck.ext4`` is taking up memory and CPU time at boot, so it confirms that it's the actual process performing the check while the others are waiting for results. After some time (2 min. aprox.), fsck.ext4 disappears and /sbin/fsck and systemd-fsck do it as well. *This is the point where the syslog, dmesg and journalctl log is written to the journal*.

I ran fsck.ext4 command manually in the following way (messages were translated from Spanish, sorry for the mispellings):

``
ferferga@pi:- $ sudo fsck.ext4 -y-f-C 5 /dev/sda1
Error al validar el descriptor de ficheros 5: Bad file descriptor
e2fsck: Invalid completion information file descriptor

ferferga@pi:- $ sudo fsck.ext4 -y -f /dev/sdal
e2fsck 1.46.2 (28-Feb-2021)

Paso 1: Verifying i-nodes, blocks and sizes
...
``

As you can see, the filesystem check went successfully as soon as I removed the ``-C5`` parameter. However, everything it's really strange because, as I said above, when system boots the fsck process is actually taking CPU time and memory, it's not exiting straightaway.

It's important to note that the drive passes all the filesystem checks and works perfectly, so I discard that fsck exists because the drive is corrupted or something like that. I also checked all the unit files of systemd-fsck and I'm not able to find where that parameter is appended by the systemd daemon, so I guess it's something that the binary itself decides. Honestly I'm not sure what else to check, but it looks like systemd-fsck rely in the -C parameter of fsck that it's not supported anymore.

Some other useful information:

Output of uname -a:
``
Linux pi 5.10.63-v7l+ #1459 SMP Wed Oct 6 16:41:57 BST 2021 armv7l GNU/Linux
``

Output of e2fsck:
``
e2fsck 1.46.2 (28-Feb-2021)
``

Output of fsck --version:
``
fsck from util-linux 2.36.1
``

Output of systemd --version:
``
systemd 247 (247.3-6+rpi1)
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +ZSTD +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=unified
``

Thank you very much in advance for all the support.