Stories
Slash Boxes
Comments

SoylentNews is people

posted by LaminatorX on Sunday December 21 2014, @02:05AM   Printer-friendly
from the fsking-pid0 dept.

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?

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by sjames on Sunday December 21 2014, @06:37AM

    by sjames (2882) on Sunday December 21 2014, @06:37AM (#127940) Journal

    They don't flip for no reason, they flip for a variety of reasons. Spike in vibration while writing an adjacent track, EMI in the drive cable, stray cosmic ray, power glitches, etc.

    In SOME of those cases the checksum doesn't match, but you won't know that unless something like a full fsck comes along and detects it for you. In others, the checksum will have been generated AFTER the data got corrupted and so it will perfectly validate the incorrect metadata. Fsck can sanity check that for you.

    Journaling in the file system is a great advancement, but it isn't a panacea. Paranoid? Perhaps, but we're talking about servers, not glorified solitaire and minesweeper machines :-)

    But Linux does respect user choice. You can use the -c and -i options of tune2fs to change the fsck interval or disable periodic fsck entirely. As long as you avoid systemd you can cancel an fsck if it's not a good time. You can manually command it to do the fsck and reset the countdown.

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 1) by tftp on Sunday December 21 2014, @06:55AM

    by tftp (806) on Sunday December 21 2014, @06:55AM (#127943) Homepage

    Paranoid? Perhaps, but we're talking about servers, not glorified solitaire and minesweeper machines :-)

    I agree about servers; but I recall that the darned thing activated when I powered up the laptop at a meeting :-) Don't even remember what it was, SUSE or RedHat.

    In others, the checksum will have been generated AFTER the data got corrupted and so it will perfectly validate the incorrect metadata.

    Checksums are calculated and checked by the hardware. The data rate is way too high to do it in a CPU. Besides, it has to be done atomically, on sector level, when HDD rewrites a sector. But sure, there is always a possibility to screw things up. It may be reasonable to be extra careful on servers. However desktops are just fine with lazy verification.

    • (Score: 2) by sjames on Sunday December 21 2014, @09:17AM

      by sjames (2882) on Sunday December 21 2014, @09:17AM (#127973) Journal

      I agree about servers; but I recall that the darned thing activated when I powered up the laptop at a meeting :-) Don't even remember what it was, SUSE or RedHat.

      An excellent example of why fsck might need to be cancelled.

      You know which use case best applies to your machine, so you must configure it if you want lazy verification.