[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 07:38 PM, Michael Biebl wrote:
Am 2015-03-13 00:17, schrieb Jape Person:
I did realize that "touch /forcefsck" was still working, and that's
what I'm using now. I was just trying to get with the times and use
whatever I'm supposed to use now.

What I didn't know was that all the -F flag on shutdown was doing was
to create that file. Funny that.

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".

That makes sense. Of course, I wouldn't have used "touch /forcefsck" (and now that I know, "shutdown -F") if I had actually thought there was something wrong with the file system, though I realize that begs the question a little. I do full daily backups of each system with hashing of all of the files on source and target to external drives and permanent media, so a failure of the drive wouldn't really be a big deal. It would just warn me that I needed to replace the drive and restore from the most recent backup. I just ran fsck on each system each weekend for a little assurance before starting the next week's use of the systems, and for the data that a full fsck provides on non-contiguous files.

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.

Yes, I'm referring to the 0.116 -> 0.119 version upgrade. I did file a bug report (Debian BTS #780352) to see whether or not the maintainers were aware of this effect of the upgrade and, if so, whether or not they might plan to fix it.

Again, thank you for your cogent and concise explanations. They're helpful to one who habitually stumbles about in the darkness.

;-)

Best,
JP


Reply to: