Skipping fsck during boot with systemd?
lists.debian.org
lists.debian.org
..
> 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.
this discussion made me angry, and i wasn't even involved. someone has a reasonable request, and it's immediately brushed off in one of the most passive aggressive statements of the 21st century thus far.
he advocates choice, and yet propagates dogma. idiot.
From an outsiders point of view, linux projects are filled with people like this. Linus, Ulrich Depper, etc. Really turns me off from ever contributing when these dudes (or girls I dunno) act like this.
In the Linux world, it seems to me that Linus has the users at heart, which unfortunately cannot be said of several others
Just watch this video of him disrupting a talk: https://www.youtube.com/watch?v=ZTdUmlGxVo0
The shenanigans start around 12 minutes in, and continue throughout.
The last few minutes are particularly weird. He even gets up on stage at around 53:40.
It's unbelievable!
Edit: I guess downvoters don't care about code smell. This is literally like an unrelated process pulling out someone else's argv and using it as their own. Ick.
> But the problem appears when system services seem to think that they own those flags, and nothing else matters, and they don't do something "sane" any more.
Then later:
> It does become a problem when you have a system service developer who thinks the universe revolves around him, and nobody else matters, and people sending him bug-reports are annoyances that should be ignored rather than acknowledged and fixed. At that point, it's a problem.
Next paragraph indicates the rant is directed at Kay Sievers, udev and systemd developer, and his "continued bad behavior".
It does ring true for me as a user, I have noticed systemd-based systems spam a lot of things that used to be "for the kernel" and a bit more sacred, like dmesg and command line.
That argument was followed with other 'bad luck, if you want tonchange your choice' examples, like rm-ing a file. The argument sucks, but at no point a hard reset was part of the suggestion, really. More a "Yeah, so why didn't you pass the parameter and why do you complain about that afterwards"
That said, both sides of the discussion became immature rather quickly (my favorite is the "I killed a Windows 8 laptop because only that stopped the updates") and the issue isn't all that big in the first place, because systemd might support fsck interruption in the future/it seems to be on the todo list and therefor accepted as a missing feature.
I use ZFS, which does this sort of thing in the background while the system is live. In fact, every read from a ZFS filesystem does a complete integrity check of everything that read depends on. If it finds an error during that process it fixes it before returning data to the caller, or returns a read error if it cannot. Those errors get collected and logged, so that if they do occur (usually due to faulty hardware) you can recover the effected files from backup.
This is much better than a surprise fsck when you're running late.
If you use ZFS, you probably are on FreeBSD. Then you would not see the advocacy of systemd that sometimes borders on insane, as a problem.
Its kind of like upgrading an outdoor carpentry project, like a deck, from nails to deck screws, then just in case you miss the feeling of hitting your thumb with a hammer, someone helpfully finds a link to install deck screws using a hammer. That's impressive in its own way, but ... I think I'll continue moving everything to Freebsd instead.
for you to suggest "not getting yourself in this situation in the first place", well, that's exactly the bullshit behaviour that i think most of us find utterly abhorrent.
Strictly speaking ext4 doesn't require it either, it's just highly recommended that there be a periodic e2fsck -f (i.e. check even if the journal is consistent and says the file system is clean), by default this is 180 days but the user can modify or disable this with tune2fs. It's possible to make it mount-count or time-dependent. See tune2fs -i.
Systemd people are not helping the community.
Also: https://rudd-o.com/linux-and-free-software/ways-in-which-zfs...
What's worrisome in this discussion is that the bug was reported 3 years ago, and acknowledge as upstream TODO, 2 years ago, but nothing has changed!
There are enough ironic/rude answers, failure to solve the problem or give a good workaround, etc
Now imagine this with paying customers.
https://lists.debian.org/20141213135648.GA14679@fishbowl.rw....
Basically it isn't possible to check at runtime if the next boot will require an fsck, so developer filed a bug asking for mechanism to do that:
I agree completely with what you're apparently trying to say in a general sense, but with respect to precisely how you phrased it, it could use a little work.
Q. I can't stop fsck.
Brian: You can add a parameter to kernel startup.
Q. This does not help because I want to stop one that has started. I should raise a bug.
Brian: Don't do that there is already a bug report at number ....Is this polite or helpful in solving the issue? It's being preachy about the idea that nobody ever makes wrong choices, ever, and should definitely never be given the opportunity to fix their mistakes.
His attitude wasn't "don't do that there is already a bug report". It was "well you made bad decisions by (a) wanting to stop fsck in the first place and (b) not being prepared for it happening i.e. by setting up two GRUB options".
I really hope Brian is not like that in real life interactions.
Maybe Maintainers or unofficial, or applicants, at most. Or not very proud of the participation so they semi-obfuscate their address.
Thanks.
But just so everyone knows, and so nobody finds themselves in this position, there is an easier way. By default, I believe systemd will skip the fsck if running on battery power (this is the case on Arch, at least). So if you know you are in a hurry but haven't added this to your GRUB config, the easiest thing to do is just boot the laptop and wait about ten seconds before plugging in the power cord (the fsck check happens early enough, so it'll have been skipped by that point). This doesn't help kill it if it's already in progress, but it has saved me many times.
Brian's response is laughably rude and unhelpful, but hopefully this will be a bit easier and more helpful than telling people to edit their GRUB config before-the-fact.
If you're trying to have an argument, you've picked the wrong person. I'm not defending Brian; I'm simply pointing out a relevant trick that I thought people reading this thread may find helpful.
You're just stating the obvious in a condescending fashion. Reddit is over there.
Now that we have robust disks and robust fs, I think that this fsck at boot setting could be relaxed. However, think of the people needing saving their data with an fsck because their HDD wasn't as robust as yours. It's not an easy choice to do. You can't even base your decision on the SMART metrics as the worst HDD, the one you want to check regularly, lie to/don't implement correctly SMART.
You can set it with tune2fs using -c count or -i interval. A machine that is often rebooted might do without the interval, and vice versa.
You can turn it off completely but don't do that unless you have reason to. Running a fsck regularnly brings a bit of peace of mind, especially if your file system has been through a lot of upgrades.
The filesystem maintainers seem to disagree: since 2011 mke2fs(8) creates new file systems without enforced fsck intervals.
http://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/commit/?id=...
# tune2fs -c 0 /dev/sda1
Or whatever his filesystems are. Then again, this is risky, and the OP should understand why.
... Especially since he didn't go out of his way to explain the exceptional circumstances that prompted him to try to skip fsck in the reported case... or did he?
so, you've given some information about setting the fsck counter to 0, so that it never happens. the only way anyone in this situation could utilise that information, would be to go back in time, run this command, and then boot again.
I am fully aware that the OP wants to cancel the fsck(8) in progress, and I am aware of both of the Debian and Systemd bugs in place to address the issue. Arguing on the Internet about whether or not he can or should Ctrl-C an active check, certainly when bugs already exist for both projects, is pointless.
Instead, to prevent additional filesystem checks, there are tools to make this possible. Unless he likes getting frustrated that he cannot press Ctrl-C during a check on boot, which doesn't seem to be the case. His system is booted now, so he has some options available to him:
* Do nothing, so the OP cannot press Ctrl-C on the next check.
* Disable filesystem checks from future boots.
* Switch from Systemd back to SysV Init.
The concept of "going back in time" during an active check, to change a kernel parameter, so it doesn't start to begin with is a strange one. Bugs have been filed, it's even on the TODO for Systemd. So, why not discuss alternatives to the issue until it's fixed?
> is there a mysterious set of commands they came up with to skip an fsck
the final sentence of the opening post.
> I am fully aware that the OP wants to cancel the fsck(8) in progress
well then why are you offering a priori fixes?
> Instead, to prevent additional filesystem checks, there are tools to make this possible
of course there are, but this is entirely irrelevant to the discussion at hand.
> The concept of "going back in time" during an active check, to change a kernel parameter, so it doesn't start to begin with is a strange one.
no strange, impossible. this is my point.
ok, imagine, someone had been in a car accident, and fractured their skull on the window because they weren't wearing their seatbelt. this discussion is akin to a doctor telling the patient (or whoever) that they could wear a seatbelt, and then this wouldn't have happened. just wear a seatbelt in future and you wont fracture your skull. just change the fsck counter/add a kernel boot parameter and fscks wont happen.