On Sat, 3 Sept 2022 at 18:57, Mike <deb...@norgie.net> wrote: > Thanks for the replies. > > Rereading my original request, I think perhaps I wasn't entirely clear > on a couple of points:
[...] Hi again. Those points seemed clear to me. > Maybe I'm being nostalgic but I seem to recall in days gone by that fsck > printed a progress bar out of hashes to show how it was getting along. [...] > TL;DR: When my server boots up and decdies to spent four hours fscking > the disks, I'd just like to see some indiction that it's still alive and > doing something :-) But what is now unclear is that your latest message does not give any indication if the replies that you already received have satisfied your request for help, or not. So I took another look at your request. I'm now able to provide more information than last time. Which I am writing up because learned a few things, so I thought I would share that with the list, so that we can help each other figure things out. There are four parts to this message: 1) Before systemd 2) Now with systemd 3) But what about initrd 4) Final part The final part is the only part that's actually useful, probably :) Part 1) Before systemd ---------------------- In the manpage 'man 5 fstab' read about the "sixth field". In the manpage 'man 8 fsck' read about the '-A' option. In the manpage 'man 8 fsck' read about the '-C' option. In the manpage 'man 8 e2fsck' read about the '-C' option. All of the above explains how fsck will work when /sbin/fsck or /usr/sbin/fsck is in use. Before systemd, that external binary was run by the init system during the boot process, and there would have been some script somewhere that a sysadmin could change its arguments. So the above information might have been of use in that situation. The manpage 'man 8 fsck' documents several environment variables that I had not noticed before, so just out of curiousity I went looking for how they might be used and I discovered the following. Part 2) Now with systemd ------------------------ /etc/fstab still works as described above. However there is documentation out there that suggests that the work of fsck has now been taken over by systemd-fsck, which is documented by 'man 8 systemd-fsck.service' and its friends. The /usr/lib/systemd/system/systemd-fsck-root.service file contains the line: ExecStart=/lib/systemd/systemd-fsck I looked at the source code for that file here: https://github.com/systemd/systemd/blob/main/src/fsck/fsck.c which is interesting because it says: "This program expects one or no arguments." revealing that there is no way for the system administrator to provide arguments or environment variables to the boot-time fsck process. The source code shows that systemd-fsck generates these arguments internally before it passes them to /sbin/fsck. I imagine that could be overcome by copying the above service file to /etc/lib/systemd/system/systemd-fsck-root.service and editing the above ExecStart line to use /sbin/fsck instead. I did try running /lib/systemd/systemd-fsck manually, but I don't have any large drives here that are unencrypted, so every filesystem that I have available to test just completed too quickly to show any progress bar. (More about that in part 4 ... ) Part 3) But what about initrd ----------------------------- When I looked at the Archlinux wiki at https://wiki.archlinux.org/title/Fsck it describes a different mechanism where fsck is done by the initrd. The Debian machinery is different, but this idea made me think that maybe this has nothing to do with systemd. So, I did boot a test machine (Debian 11) with "break=bottom" and had a dumb poke around the initrd, and I found this (transcribed by hand, blanks omitted): -----begin----- (initramfs) cat /run/initramfs/fsck.log Log of fsck -C -a -T -t ext4 /dev/sda2 Sat Sep 3 10:53:44 2022 SATPRO_X: clean, 34049/794624 files, 445226/3173376 blocks Sat Sep 3 10:53:44 2022 -----end----- And I also noticed that the console messages say (transcribed by hand): -----begin----- Begin: Will now check root file system ... fsck from util linux 2.36.1 [/sbin/fsck.ext4 (1) -- /dev/sda2] fsck.ext4 -a -C0 /dev/sda2 SATPRO_X: clean, 34049/794624 files, 445226/3173376 blocks done. -----end----- And after more poking around, I'm guessing that fsck is called from /usr/share/initramfs-tools/scripts function _checkfs_once() with '-C' (in the fsck.log above) and that fsck.ext4 reports (in the console message above) that it takes that to mean '-C0'. So, it is currently my naive understanding that all of this is happening in the initrd, before systemd starts. Which would mean that Part 2 of this message is completely irrelevant. Someone please do correct me if that is wrong. Part 4) Final part ------------------ > Someone asked about the file systems in use. Some are ext3 and some are > ext4. In case you are not aware, fsck on ext4 uses a completely different algorithm that is orders of magnitude faster than ext3. So if you convert your ancient ext3 filesystems to ext4, I expect you will find that the fsck process that used to take hours will then take only a minute or two, or even less, and so you won't care about the progress bar any more. And I suspect that is why no-one seems to care about this progress bar issue these days.
