Quoting Michael Biebl (bi...@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. Cheers, David. -- 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/20150313013332.ga20...@alum.home
