Re: Skipping fsck during boot with systemd?
On Sat 06 Dec 2014 at 07:21:30 -0500, The Wanderer wrote:
> (Quoting reordered slightly to make more what-replies-to-what sense.)
>
> On 12/06/2014 at 06:27 AM, Brian wrote:
>
> > On Sat 06 Dec 2014 at 10:10:05 +0000, Lisi Reisz wrote:
> >
> >> On Saturday 06 December 2014 09:44:38 Brian wrote:
>
> >>> His lateness and the scheduled fsck do not appear to be
> >>> correlated. A technique to speed things up has been given.
> >>
> >> But his lateness and his desire to interrupt the fsck on that
> >> particular occasion are directly causally linked. To say "Your
> >> mistake. You should have done so and so. You must live with the
> >> consequences if you didn't." is neither very pleasant nor very
> >> helpful. As I say, most of us are human and make mistakes
> >> sometimes.
> >>
> >> Eduardo probably usually wants fsck to run. Just not on that
> >> occasion. So your "solution" didn't even solve the problem.
> >
> > In what way does having two grub entries not answer the need to have
> > fsck run most of the time but not run on occasions which are deemed
> > inconvenient?
>
> In that it doesn't help when you picked the wrong grub entry, whether
> because you didn't know that a possible later fsck would not be
> interruptible or because you forgot that a fsck might happen or because
> you forgot that the option to pick the different grub entry might be
> available or because you were in too much of a hurry or because you
> simply missed the "automatically boot the default option" timeout.
I have the same reaction to the rm command (with or without the "-i"
option). Forgetfulness, lack of attention or haste have all lead to my
regretting hitting a key when I did.
People tell me pleasantly that one of life's little quirks is having to
live with the consequences of one's actions. I've been know to get a bit
shirty with that remark, but the passage of time has usually allowed me
to put some perspective on it.
> Both the ability to decide against doing something in advance, and the
> ability to abort that thing after the fact, are useful options to have.
> They address different aspects of the same need and the same problem.
>
> Being able to decide in advance "don't fsck this time" does not in any
> way make it less useful, or less reasonable, to be able to cancel a fsck
> which has already started. Both options are useful, and both are
> reasonable choices to have.
I agree that both options are useful. The problem is that the second
option doesn't exist yet. Regession or not, this leaves a determined
user with seeking another solution.
> >>> It is evident from this thread that the ability to abort an
> >>> in-progress fsck during boot may not be available yet (although
> >>> the links given indicate some untested possibilities). Another
> >>> suggestion would be to have a system detect an impending fsck and
> >>> have it substitute a grub.cfg with "fsck.mode=skip" in it for the
> >>> next boot.
>
> > A third suggestion is to use grub's scripting to present the user
> > with a choice of a fsck or not.
>
> I am dubious about whether reliably detecting an impending fsck in this
> way is practical, or maybe even possible, from the environment which is
> available from that stage of the boot process.
>
> Do you have any suggestions about a way to actually implement this?
The system echos '#GRUB_FSCK="yes"' to /etc/default/grub when a fsck is
due. The code in grub.cfg checks for the existence of this line and
boots with "fsck.mode=skip" if it is found. An 'if..;then...;else...;fi'
should do it.
Reply to: