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?
Related Stories
As long time SoylentNews community member Marand observed during some recent discussion of severe systemd boot problems, it turns out that systemd disables the magic SysRq key.
The magic SysReq key is described at Wikipedia as:
[...] a key combination understood by the Linux kernel, which allows the user to perform various low-level commands regardless of the system's state. It is often used to recover from freezes, or to reboot a computer without corrupting the filesystem.
A Fedora user who logged a bug report for this issue back in 2013 described the problem with systemd's unexpected and harmful default setting:
As systemd depends on many files on a rootfs, in case of any problems with rootfs, it is not able to do its basic function - control processes and (cleanly) shutdown/reboot when crtl-alt-del is pressed on local keyboard. As this is a feature, I'd like to ask to enable the sysrq by default on Fedora, otherwise it is not possible to reboot system even locally in case of emergency situation.
While that Fedora bug report is set to CLOSED NOTABUG, other Linux distros, like Mageia and Debian GNU/Linux, have restored the proper behavior.
Now that this problem has come to light, all Fedora users should evaluate whether or not they need to fix their systems to work around systemd's incorrect default setting. Users of other Linux distributions using systemd should also evaluate their systems, too, in case their distro has not yet fixed this unexpected bug.
First to say... (Score:1, Funny)
Haven't seen this for a while (Score:2, Interesting)
In 2000's I was running quite a lot of Linux, and this problem was always bothering me. It looked like the computer's needs are above user's needs. To compare, Windows never ran fsck unless the FS was in a pretty bad shape. These days I have either servers (Ubuntu LTS) that aren't frequently rebooted, or desktops (Mint) in VM that never need fsck. Maybe journaling FS help here, as integrity of the FS can be easily determined without going through terabytes of data. Running the check on a modern HDD may be an hour-long distraction, and most certainly the OS should not run it without a positive confirmation.
It's easy how it could happen (Score:4, Insightful)
These are the same jerks that used 'debug' in their module, then generated so many messages that they killed kernel debugging. When called on it they basically said "anybody can use debug, pound sand".
People with this kind of attitude are capable of all kinds of fuckwittery.
fsck is so 90s (Score:2)
What is this fsck you speak of? [zfsonlinux.org]
Jesus Christ. Is this for real? (Score:3, Insightful)
I can't believe what has happened to Debian, and Linux in general.
I first started using Linux after Windows 95 kept crapping out on me. Linux was better in so many ways. It was stable! It had great filesystems! It performed better! And it didn't cost me anything, other than some time to set it up and learn how to use it!
Linux used to make me better off. But today? Linux is a fucking joke. It's inferior to Windows and OS X, I'm sad to say.
Why would anyone want to use Linux when they're subjected to systemd, or GNOME 3, or any of that other crap that's ruining the Linux experience? Why?
Who decided it was time for fsck? (Score:2)
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.)
I'm just fine over here in my nice little tent. (Score:4, Informative)
In the Epoch Init System [universe2.us], if you have such a job set up you want to kill, hit CTRL-ALT-DEL and it kills that job and continues to the next one. Hit CTRL-ALT-DEL again in the next 5 seconds, it starts rebooting orderly. I can't tell you how useful that has proven to be for me.
Let all with undamaged ears still able to hear find solace in melancholic music.
For crying out loud, come on (Score:2)
I dislike systemd, I don't use it (or pulseaudio, or consolekit, or udev, or...). I fully sympathize with those who encounter difficulties while forced to use it at gunpoint by roving bands of militants. My heart goes out to those who cannot install a different operating system without endangering the lives of their captive families, as well as to those whose computers have been rigged with explosives, wired to detonate if the network card attempts to download Gentoo, Slackware, *BSD, etc.
However, this is a site I want to come to to read news, not to have a daily 2 minutes of hate against that which does not share my ideological beliefs. If I want to have a lengthy conversation about why the software I use is the best software, why my political views are the best political views, or why my preferred brand of orange juice is the only digestible stuff on the market, my house contains enough mirrors for the purpose.
--------
In all seriousness, I get that stories on Gnome 3/systemd/U.S.A. politics/etc. generate comments and all that, but I don't think the price is worth it.
(I appreciated the story on NTP, however. That was informative news.)
Re:For crying out loud, come on (Score:4, Informative)
However, this is a site I want to come to to read news, not to have a daily 2 minutes of hate against that which does not share my ideological beliefs.
I actually found this one to be informative and useful for me. I expected another useless flamebait summary, but instead got informed of a potential gotcha with systemd as init. Reading the linked bug report thread, including its followups, also taught me that systemd also likes to disable magic sysrq keys [wikipedia.org].
Redhat considers this NOTABUG [redhat.com], Mageia did too but bowed to pressure and re-enabled it [mageia.org], and Debian decided it wasn't systemd's place to change this and re-enabled sysrq [debian.org].
Thanks to this article, I learned about two systemd gotchas I need to remember when dealing with systemd-enabled machines. The sysrq one is especially a big deal, because the times you need the sysreq keys, things are already too hosed to play with trying to enable them. It's not something you need often, but you expect it to work when you do. I saved a laptop from a reboot earlier today using sysrq-k on Xorg, in fact. I would have been pissed if my init had one day decided I'm not adult enough to use them and forced me to cut power instead.
So, while I agree that we had a pretty bad string of AC systemd troll submissions before, this particular submission has merit, because it's actually providing a link to some useful info I (and likely others) wouldn't have known about otherwise. This is something the systemd users may want to know, and in fact, it's probably more useful to them than to systemd haters.
Parent
Is it baseball? There isnt any crying in baseball! (Score:1)
Second, quit turning your dang laptop off. Suspend to disk. It's not the 90s anymore, we've had it for years, it works like a dream, use it.
Lastly, systemd. Of course it isnt going to let you interrupt it once it decides to do something, you grubby luser.
That really seems to be their attitude. And it's one that will be self-fulfilling, I feel. People that accept that categorization of themselves will be happy to have less responsibility and less to think about as they are given fewer choices to make.
And those that disagree, will simply avoid the systemd infection. There are still great Linux based systems without them - Slackware and Gentoo are the largest. There are still BSDs too if it comes to that.
So in summary, in order to find yourself dealing with this problem as described, you have to have made 3 big mistakes - single slice partitioning, shutting your laptop down instead of suspending work, AND using systemd.
Three strikes and you are out.
Friends dont let friend enable ecmascript.
It figures (Score:3, Informative)
In my testing, it also refuses to mount a btrfs filesystem in degraded mode. It dumps you to the emergency shell every time. When I researched the issue, I saw that the same problem exists for soft raid. Thus far, no solution has been offered.
Standard practice since tape drives... (Score:2)
It's been standard practice to run disk data tests in boot time since before UNIX. Only exceptions I can think of were a few embedded systems with a burned firmware and DOS.
Hell, even the bios is running a checksum on itself to test for corrupting and tampering...
NSFW unless FSM said otherwise.
"Severe" "bug" (Score:2)
How is this bug severe? fsck never takes more than a second for me, using a partitioned 1TB HDD on a laptop running Arch (and yes, systemd). Unless, of course, your file system is farked, in which case why the hell do you want to skip it?
I agree that having the option is nice, but if it were me, this feature request (not bug!) would be pretty near the bottom of the pile.
Re:systemd was probably planted... (Score:0)
When do you think it will be fixed by?
I thought that GNOME 3 would have been fixed by now. That still hasn't happened.
I thought that Firefox would have been fixed by now. That still hasn't happened.
Debian has been broken for a few months now. When will it get fixed? Will I have to wait 5 years? A decade?
Parent