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

Re: How can I force a full fsck on a remote system at next reboot?



On 03/12/2015 09:33 PM, David Wright wrote:
Quoting Michael Biebl (biebl@debian.org):
Am 2015-03-13 00:17, schrieb Jape Person:

Right, you're not the only one. There were quite a few people, when
they noticed file system errors in the system log, they thought it
might be a good idea to force a file system check and reboot via
shutdown -F, not realizing that this caused writes to a file system
which already had problems. That this is not a good idea is
hopefully obvious.
That's basically the whole reason, why the usage of /forcefsck is
discouraged and the -F command line switch was removed from
shutdown, to hide this "feature".

Presumably also because, with errors=remount-ro in /etc/fstab,
/forcesck wouldn't get created, which is just as well in view
of your first point.

I will check the man pages for grub-set-default. It seems like the
approach of using grub for this function on remote systems may be a
little easier than I was thinking it would be earlier on.

BTW, do you have any thoughts as to why the recent upgrade in
initramfs-tools would defeat the strategy I was using -- setting
maximum mount count to zero with a line in rc.local and then invoking
tune2fs to change it to a value of one, and then rebooting?

Unfortuantely not. I haven't looked into detail yet, what the
changes in initramfs-tools (I assume you refer to 0.119 here) do.

My understanding of this change, which may well be wrong, is that the
fsck now takes place *before* / is mounted, whereas it used to happen
after / was mounted ro but before it was remounted rw.

And I think this is all about the fsck that says "clean" rather than
the fsck that checks everything, which is what fsck.mode=force is for.

Yes, I saw that the order of operations concerning fsck had changed when I saw the interactive notice during the upgrade (aptitude). That's why I immediately tested my systems to see if the old strategy of setting maximum mount count of zero in the rc.local file and then running "tune2fs -c 1 /dev/sda1" and reboot to invoke fsck would still work. It wouldn't. I wasn't surprised. But I am looking for a convenient way to restore my ability to force fsck to run on remote systems at will (without using the deprecated method).

When I get a bit of time to read (and understand) the man pages Michael pointed me at, I should be okay.

Still, I wonder if the upgrade was really meant to result in this particular effect. I wouldn't expect that type of change to come down the pike during a freeze, though I'd understand if it was done out of real need.

Best,
JP


Reply to: