On 03/11/2015 06:24 PM, David Wright wrote:
Quoting Jape Person (jap...@comcast.net):
I maintain some remote systems that I don't want running a full file
system check at inopportune times, but I do make certain that I
force a check and examine the results on a regular basis. Anyway,
that's why I don't simply modify grub behavior to include
"fsck.mode=force" on these systems.
I put that string, along with others, into the default grub
configuration and use a scripted method outlined in
https://lists.debian.org/debian-user/2015/03/msg00330.html
to modify and maintain grub.cfg itself, naughty but practical.
Debian will add a single/recovery submenu for you automatically,
but AFAICT not a fsck one. (File a bug?)
My script changes the advanced menu id to fsck, and the submenu to
fsck too. I then use a root-owned script to do a check.
--8<----
#! /bin/sh
# Reboot, forcing the disk partitions to be checked (which takes a
# while).
# Logged by adding date to a logfile. Last edited 2014 December 18
printf "\n\nRebooting the system and performing a full disk check.\n"
printf "\nPress ^C within 10 seconds to prevent this.\n\n"
sleep 10
date --rfc-3339=seconds >> some-log-file
# The kernel line referred to by the argument below should have had
# fsck.mode=force
# added to it.
grub-reboot 'fsck>fsck'
reboot
--8<----
The filesystems are all tune2fs'd to infinite mounts in up to a month.
The logfile (symlinked from other installations in the box) is
world-readable and checked whenever I log in, writing exhortations
after three weeks.
This was all modified from wheezy where it used the old shutdown,
but can't be used there as the force is ignored by wheezy kernels.
Cheers,
David.
Hello, David.
I'm going to study this at some length this weekend if I get the chance.
I want to see if I can adapt the ideas and methods to my use. I
appreciate your reply.
I had originally thought weeks ago (before posting the earlier thread)
of scripting changes to grub configuration and running update-grub
remotely each time I want to do a file system check. It just seems like
a pretty extreme approach, and maybe a little riskier than some method
that doesn't involve messing around with the grub configuration and
update-grub.
Still, I guess I haven't seen any evidence on the systems I maintain of
issues with reliability of the grub-pc components. Maybe I'll give it a
try when I have a little time to sweep up pieces if something goes wrong.
Again, thank you for your post.
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/5500c7e8.4020...@comcast.net