Systemd-fsck output

Question

Hallo,
i have some questions about systemd-fsck output shown in the console during the system boot. it looks like this:
/dev/mapper/vg-root: clean, 82501/1310720 files, 647916/5242880 blocks
systemd-fsck[234]: /dev/sda2: clean, 337/64000 files, 88881/256000 blocks
systemd-fsck[233]: /dev/mapper/vg-home: clean, 30217/5283840 files, 961660/21116928 blocks
systemd-fsck[232]: /dev/mapper/vg-var: clean, 19485/851968 files, 846527/3407872 blocks
systemd-fsck[238]: fsck.fat 3.0.20 (12 Jun 2013)
systemd-fsck[238]: /dev/sda1: 251 files, 3820/403266 clusters
is it actually running any test?
assuming the above shown output means something like "ok" or "there is no problem", i then want to hide it, so i created a file /etc/systemd/system/[email protected]/custom.conf with the content:
# dont show systemd-fsck results in the console, if everything is ok
[Service]
StandardOutput=journal
StandardError=journal+console
this seems to work pretty nice, but there is one line remaining in the console, the very first one about the root partition. it seems somewhat different to the other lines, in that it misses the prefix systemd-fsck and it can't be found by journalctl
how could i hide this first line?
Is it right, that in case systemd-fsck detects any file system error it still would output these on the console because of the setting StandardError=journal+console?

Answer 1

When you remove the fsck hook from the initramfs, you aren't hiding the output. Rather the test is not being run. Personally, I think that not running an important check on the integrity of your file systems simply to hide a few lines of output on the console reflects rather weird priorities but obviously that's up to you.
For whatever it is worth, I have had cases in which stuff has gone wrong and fsck has identified the need to look at the file system journal. In every single case, the automated routine has examined, repaired and mounted the file system correctly. It has never prevented booting and I have seen almost no file system corruption with the exception of something on a fat 32 system which is obviously not journalled. Given that my system was for a while routinely shutting off in the dirtiest way possible, I think this reflects the robustness of both the file system and the associated maintenance tools like fsck and I would put up with a great deal more than a few lines of text on the console in exchange for this sort of security. My data is the most important thing on the computer and I will use whatever means are reasonably available to me to protect it.
Of course, if nothing like this has (yet) happened to you, you may not (yet) appreciate the system's robustness. But sooner or later, you almost certainly will. (Unless your data is unimportant to you, of course. That would be different.)