2014/12/08 20:24 "Brian" <[email protected]>: > > On Mon 08 Dec 2014 at 10:12:55 +0100, Christian Groessler wrote: > > > On 12/08/14 09:44, Curt wrote: > > >On 2014-12-08, Stefan Monnier <[email protected]> wrote: > > >>Actually, it's *always* a surprise. These fsck happen at long enough > > >>intervals, that I can never know if it was "4 months ago" or "7 months > > >>ago", and neither can I remember which laptop/desktop has the delay set > > >>to 172 days vs 194 days vs 98 days vs ... > > >> > > >Can't you write a small script to obviate the limitations of your human > > >memory, like this little hacker here did? > > > > > >http://nwalsh.com/hacks/mountinfo/ > > >http://nwalsh.com/hacks/mountinfo/mountinfo > > > > > > Why don't the systemd proponents understand that someone might want to > > interrupt a running fsck? Don't scrutinize the reasons, just accept > > the fact. > > Please could we stick to the technical aspects of this problem. Attempts > to apportion responsibilty rarely lead anywhere.
Technical? What exactly do you mean by technical? It seems lately that the word "technical" in some contexts seems to have developed the meaning "achievable by appropriate incantation." That is not what I mean when I say "technical", at any rate. > > After all, it's *my* computer, and *I* want to be in control of it. > > Curt's link brings the number of discussable solutions to four. Here is > a fifth (which might utilise the mountinfo script): None of which address the real issue. Some developer made a seemingly minor, seemingly "logical" change in things, and the effect is that some user who had been depending on debian stable to be stable found his computer unusable without advance warning in a situation where he needed it. Sure, in the real world, especially with consumer grade OSses, things like this do sometimes happen. In the "real" world, expectations of high availabilty have to be bought with expensive service contracts from companies that are supposed to do all sorts of testing so that this kind of thing doesn't happen to the paying customer. Fedora users have been a volunteer group of testers, paid, essentially, in-kind for their testing. So debian users have been living in a dream world. Systemd marks the end of that dream world. That much, I'll grant you. > GRUB is made aware of an impending fsck. Booting thows it into a submenu > with the choice of doing a fsck or not. You control which route to take. This kind of thinking requires grub to be able to communicate with the OS which it is booting after it releases control. In other words, grub has to become a minimalistic OS. The grub group has been discussing that for several years. Xen is one of the results of that discussion. But grub, itself, is not there yet. What I want to know is why you don't seem to be aware that your suggestion is dependent on a possible future direction for grub, and cannot help anyone now who wants to be able to predict when an fsck becomes impending, to avoid an undesirable situation which had not existed before the upgrade to Jesse with the recommended stock init for Jesse. This is why we can call it unexpected: The fsck was expected, sure. But being unable to stop the fsck was not expected, unless you happened to have experienced it when it hit Fedora as part of systemd. Not everyone here is a Fedora refugee. Before you start crying about personal attacks, let me tell you that I have, as a professional engineer, faced similar criticisms of my technical choices at work. Facing this kind of criticism comes with the territory when you choose an engineering field, because every engineer makes mistakes. If an engineer reacts by blaming the user, he generally is told he can look for another job, preferably in another field. -- Joel Rees
