SoylentNews is people
SoylentNews
A Debian user has recently discovered that systemd prevents the skipping of fsck while booting:
With init, skipping a scheduled fsck during boot was easy, you just pressed Ctrl+c, it was obvious! Today I was late for an online conference. I got home, turned on my computer, and systemd decided it was time to run fsck on my 1TB hard drive. Ok, I just skip it, right? Well, Ctrl+c does not work, ESC does not work, nothing seems to work. I Googled for an answer on my phone but nothing. So, is there a mysterious set of commands they came up with to skip an fsck or is it yet another flaw?
One user chimed in with a hack to work around the flaw, but it involved specifying an argument on the kernel command line. Another user described this so-called "fix" as being "Pretty damn inconvenient and un-discoverable", while yet another pointed out that the "fix" merely prevents "systemd from running fsck in the first place", and it "does not let you cancel a systemd-initiated boot-time fsck which is already in progress."
Further investigation showed that this is a known bug with systemd that was first reported in mid-2011, and remains unfixed as of late December 2014. At least one other user has also fallen victim to this bug.
How could a severe bug of this nature even happen in the first place? How can it remain unfixed over three years after it was first reported?
(Score: 2) by Foobar Bazbot on Sunday December 21 2014, @03:30AM
I got home, turned on my computer, and systemd decided it was time to run fsck on my 1TB hard drive.
Not that it would be the first inexplicably dumb choice in systemd, but I suspect that the "decision" had nothing to do with systemd. It's perfectly fair to blame systemd for not starting fsck in such a way as to permit the user to cancel it, but it's not fair to blame it for a decision that, AFAIK, is still handled by fsck.
Normally init doesn't make decisions about what to check -- rather, all filesystems are fscked indiscriminately (e.g. by fsck -A), and the fsck running against each filesystem checks various flags (e.g. whether the filesystem was cleanly unmounted) to determine if a complete check is needed. The periodic checks (... has been mounted %u times without being checked or ... has gone %u days without being checked) are determined by comparing the mount count and last fsck time (read from the filesystem) with the maximum mount count/maximum time settings (also read from the filesystem), and have nothing to do with systemd. If you don't want your system to do these, or would prefer it do them less often, use tune2fs with the -c and/or -i options to tweak the maximum mounts and/or maximum time.
(Interesting note -- when poking about in the e2fstools source to find the text of the reasons for periodic checks, I noticed some code that effectively doubles the stated maximums if running on battery (subject to the defer_check_on_battery option in e2fsck.conf, default is true). Cool, and possibly a helpful dodge in such a "Boot NOW!" situation, if the machine in question is a laptop.)
(Score: 0) by Anonymous Coward on Sunday December 21 2014, @03:41AM
But it's not at all a problem that fsck chose to run when it did. It's perfectly fine that it ran, and in fact it's probably the right thing to do, especially if the filesystem may need to be repaired.
There's only one problem here, and that's that systemd is buggy and prevented this perfectly legitimate run of fsck to be canceled manually, when the operator deems that acceptable to do.
This is nothing but a problem with systemd, and only systemd.