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 Arik on Sunday December 21 2014, @02:16PM
It's no magic bullet but it does make dealing with it a bit easier.
"I consider it best practice to have a single root partition and a single swap partition, unless I have good reasons to do otherwise."
So first off, with that setup, any process can fill the hard disk with temp files and cause all kinds of problems here. It's a pretty big deal when that happens on the root partition.
Put /var on it's own partition, and make /tmp a link to /var/tmp, and the same occurrence becomes a trivial annoyance instead.
You should put /home on its own partition for the same reasons. Lots of stuff gets to write to the home directory, if any of it ever goes berserk, for any reason, having /home on its own slice saves lots of toil and trouble.
And /usr is where post-boot software is installed - in many systems the majority of the disk space is used for this. Giving this its own slice is done simply to reduce the total size of /. Because the larger a slice is the longer it takes to fsck it - and it's not a linear scale. A very small / partition will fsck before you can notice it and hit ctrl-c - which is exactly the behaviour we want here. A very large slice can take hours. It's always faster to fsck 10 100gb disks than to fsck the same disk in a single terabyte slice.
"Needlessly splitting of /usr or /home is just setting yourself up for pain when you discover you need more space for /home and less space for /usr than you expected, or vice versa."
That's why man invented the LVM. Your physical slices and logical system-facing slices are two totally different beasts now, and if you need more room on /var and /usr but less on /home than you expected (or vice versa) you just adjust the numbers and make it so without disturbing the physical partitioning in the slightest.
If laughter is the best medicine, who are the best doctors?
(Score: 1) by linuxrocks123 on Monday December 22 2014, @12:22AM
The "a poorly-behaved process can fill the whole hard disk" thing is not a good argument, imo, because the default settings for the ext filesystems is to only let root write to the disk when it's 95% full. I agree with the /home thing if you want to use multiple distros on the same machine, but I typically don't. "It makes fsck run faster" is a poor argument IMO because I have terabyte and larger filesystems and fsck still doesn't take an unreasonable amount of time to run on those. You can also just disable fsck entirely and rely on the journaling to fix any problems if you want.
I'm not sure what your point is about LVM; if you combine a bunch of slices with LVM, you still have a single filesystem on a large virtual device, so you'll still need to either periodically fsck or rely on journaling.