On 03/12/2015 09:33 PM, David Wright wrote:
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.
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
--
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/55024691.1010...@comcast.net
