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.