[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

fsck.mode=force no longer working in testing?



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.


Reply to: