Re: Skipping fsck during boot with systemd?
On Mon 08 Dec 2014 at 10:51:01 +0000, Bonno Bloksma wrote:
> Hi Brian,
>
> >> Brian <ad44@cityscape.co.uk> wrote:
> >>
> >> > But remember our current slogan "Linux is all about choice". One can
> >> > choose to boot with or without "fsck.mode=skip".
> >>
> >> What about the choice to stop fsck it if it has started at an inconvenient moment ?
> >
> > Remedial action is not needed because the right choice was made from
> > the grub menu. If it wasn't, you get to live with the consequences
> > and don't do it again.
>
> I guess you never were in a hurry to get a system up and running again
> during production hours where a fschk takes a looong time. As normally
> a reboot takes place at night and I DO want a fschk to be performed at
> that time if needed this is the default boot option.
I think you might want to investigate using GRUB's datehook module, It
will allow changing the default boot option depending on the date and
the time of day. It looks ideal for doing what you describe.
> So in your opinion everyone with a production system needs a third
> grub line apart from the 2 default lines. If that many people NEED it
> then why is it not a default 3rd line in all installations? Also,
> just about "never" will that fschk start when I do a manual reboot so
> why would I remember to choose option 3 at the reboot. Also... a
> server nowadays takes minutes for the hardware check to complete a
> reboot, after that I have only 5 seconds to select the proper boot
> option in your scenario. Or do you want me to lengthen ALL reboots by
> lengthening the Grub boot screen?
No, that is not my opinion. The solution you refer to may not suit
everyone. But there are another five to consider. :)
> All of this was never necessary as we could cancel an unneeded fschk
> that was merely performed because a certain number of days had passed.
> That was the proper way, to take action when it is needed. Not to
> allways take action in preemptive way in a short (seconds) windows
> when it is almost never needed.
>
> I hope this clarifies things a bit, I hope we get the option back to
> stop a scheduled fschk that is performed at an inconvenient moment.
I too hope it comes back. Meanwhile, you are stll faced with preventing
a scheduled fsck from going ahead.
Reply to: