Re: "Run fsck manually"..?
On Wed 03 Feb 2021 at 07:32:25 (-0500), Greg Wooledge wrote:
> On Tue, Feb 02, 2021 at 10:01:30PM -0600, David Wright wrote:
> > > # touch /forcefsck
> >
> > I think this is somewhat out of date, is it not.
>
> It is, yes. That no longer works in systemd.
>
> > I force fsck by adding forcefsck in grub, ie press e in
> > the grub menu, move the cursor to the end of the linux line,
> > type forcefsck and press Ctrl-X or F10 to boot. For example,
> >
> > linux /boot/vmlinuz-4.19.0-14-amd64 root=LABEL=toto04 ro systemd.show_status=true quiet forcefsck
>
> The instructions from the bot in #debian say to add fsck.mode=force
> to the kernel parameters. Perhaps your variant is some sort of alias.
T'other way, I think, but no matter. For the record, there are
two different "strengths" for fsck:
fastboot|fsck.mode=skip)
fastboot=y
;;
forcefsck|fsck.mode=force)
forcefsck=y
;;
fsckfix|fsck.repair=yes)
fsckfix=y
;;
fsck.repair=no)
fsckfix=n
;;
> I am not aware of any one-shot variant that can be used *before*
> rebooting, without being physically present at the console. Sadly.
> The closest approximation would be to permanently edit the grub menu,
> reboot, and then restore your backup copy of the grub menu.
If you have a separate /boot that is not on a filesystem needing
fscking, then you can use the normal mechanism supported by grub¹.
On my systems, I would run a script containing grub-reboot 'fsck>fsck'
followed by either reboot or /sbin/shutdown -P now (to leave
checking until the next day).
Yes, it involves either editing the Grub menu, or learning how to
change it the official way through the scripts in /etc/grub.d/.
Being lazy, I just postprocess grub.cfg whenever it's upgraded.
My script² takes advantage of the fact that the first menuentry
and the first ("Advanced") submenu's menuentry are identical,
so all it has to do is change the labelling of the submenu and
menuentry (hence 'fsck>fsck' above) and add forcefsck to the
kernel line.
I suppose you could do it through a /etc/grub.d/40_custom entry,
keeping it up to date by using the symlinks in /, or by manually
maintaining corresponding symlinks in /boot if it's separate.
I've never bothered with automating a fsckfix option—if things
are that bad, I want to be present when fsck runs.
¹ It writes to the file /boot/grub/grubenv, hence the caution.
² The principal function of my script is to convert all the
UUIDs into LABELs by looking up /run/udev/data/.
Cheers,
David.
Reply to: