Okay, deep breath, and here goes...
I seem to wind up posting about forcing fsck on the boot partition every
few months. Over the past year or so I've had to change the way I
initiate a full file system check on the boot partition of my systems.
I used to use
----<begin>----
# touch /forcefsck
----<end>----
followed by a reboot to get fsck to run on my boot partitions.
At some time in the past I went from seeing the results of the boot-time
fsck at /var/log/fsck/checkroot to having to issue
----<begin>----
systemctl status systemd-fsck-root.service
----<end>----
to see the results of the check.
Because I wanted to stop using touch /forcefsck I went to inserting
----<begin>----
tune2fs -c -1 /dev/sda1
----<end>----
in the /etc/rc.local file and then issuing
----<begin>----
# tune2fs -c 1 /dev/sda1
----<end>----
and rebooting to get fsck to run.
Then, I stopped seeing the log of the boot-time fsck in the systemctl
status report for systemd-fsck-root.service, and I was told to look in
/run/initramfs/fsck.log.
In further conversations on this list I was told I could create an
additional grub menu entry which included fsck.mode=force and then use
the grub-reboot command to get the remote systems to select that entry
at the time of the next boot.
I was able to use systemctl to see status again, and everything was peachy.
Until some time after 04/11/2015 (the date I last ran fsck on the boot
partitions of my remote systems). And now using fsck.mode=fsck results
in this
----<begin>----
● systemd-fsck-root.service - File System Check on Root Device
Loaded: loaded (/lib/systemd/system/systemd-fsck-root.service; static)
Active: inactive (dead)
start condition failed at Sun 2015-04-26 12:47:03 EDT; 2min
12s ago
ConditionPathExists=!/run/initramfs/fsck-root was not met
Docs: man:systemd-fsck-root.service(8)
----<end>----
from the systemctl status command, and I get
----<begin>----
Log of fsck -a -t ext4 /dev/sda1
Sun Apr 26 16:58:03 2015
fsck from util-linux 2.25.2
/dev/sda1: clean, 207699/3571712 files, 4471865/14277376 blocks
Sun Apr 26 16:58:03 2015
----<end>----
in /run/initramfs/fsck.log.
Also, touch /forcefsck no longer forces fsck to run, with it yielding
the same results in systemctl status and fsck.log.
And now the tune2fs trick works again, and I get proper results in
/run/initramfs/fsck.log. But I had to fiddle around and test a bit
before I could discover this workaround.
SUMMARY:
It's possible that I don't have the sequence of these changes exactly
right, and this might not be a complete accounting of the changes,
inasmuch as I'm trying to relate changes in my maintenance process over
quite a few months. This is my hobby, not my job. But it seems to me
that this represents quite a bit of turmoil in the way this one little
corner of Debian testing works, and a fair amount of it has occurred
during the Jessie freeze.
Can anyone test to see if fsck.mode=force is still working on their
Jessie / testing systems? If so, I must have done something to all four
of my testing systems to screw things up. And, if fsck.mode=force has
stopped working, I wonder what broke it.
BTW, my systems are "testing" in the sense that I use "testing" in
/etc/apt/source.list instead of the release name. So I guess I'm on
Stretch now.
Heh. I wasn't even aware that the release was going to occur until I
checked the list this morning. Yeah, I'm a hobbyist.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/553d275c.9060...@comcast.net
