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. -- 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/20141206200913.gd20...@copernicus.demon.co.uk
