Skipping fsck during boot with systemd?

https://lists.debian.org/debian-user/2014/12/msg00184.html

by pwg • 12 years ago

61 79 12 years ago

lists.debian.org

Scramblejams• 12 years ago

That thread features a few participants I would never want talking to a customer.

raverbashing2• 12 years ago

This is a real problem. Really

There are enough ironic/rude answers, failure to solve the problem or give a good workaround, etc

Now imagine this with paying customers.

ash2• 12 years ago

The atmosphere on debian-users is… not very helpful.

getsat3• 12 years ago

That Brian guy in particular is a total cunt. Holy crap. Willful ignorance of specific issues being raised combined with smug superiority. I find people on IRC to be a lot more pleasant. I am never mailing a mailing list.

papaf• 12 years ago

I think he is being reasonable and helpful.

   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 ....

VLM3• 12 years ago

"is a total cunt"

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.

olgeni• 12 years ago

Uhm. What does "decided it was time to run fsck on my 1TB hard drive" mean? Decided how?

mackwic2• 12 years ago

Every n boot (n usually around 30) is scheduled a fsck at boot. It is more a legacy thing as ext4 is really robust. I remember checking my /home/lost+founds regularly in this time and often finding random stuff, music, documents where the i-node has been made orphan so that it doesn't belongs to any directory. Today, we have ntfs and ext4 with amazing journals which can replay most of the operation that has been made. So, when the Virtual-FS layer (the component of the kernel that map the bytes on your HDD to the logical file-tree in the exporer) detect an inconsistency it can replay and apply the correct state to the fs tree on the fly.

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.

xorcist• 12 years ago

This value is configurable per file system. It is set at install time but you can change it at will.

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.

laumars• 12 years ago

Thankfully ext4 fsck is significantly faster than ext3, which means any inconvenience for users running robust storage isn't as prolonged as it once was.

alaaibrahim• 12 years ago

So the solution to this, if you want to abort an fsck, go back in time, and pass fsck.mode=skip to the kernel parameters.

mackwic2• 12 years ago

A fairly bad answer, we can all admit that.

Certhas• 12 years ago

By clicking a few links further one also finds out that systemd has ctrl-c to cancel fsck on the ToDo list.

seba_dos1• 12 years ago

All right! To the Chron-O-John!

uaygsfdbzf• 12 years ago

There was a more productive thread on a related topic on debian-devel recently:

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:

https://bugs.debian.org/773267

jbk• 12 years ago

We should be very careful about fixing those kind of things, this is one of the biggest complaints against Windows, when you cannot shut down your machine, or boot wait a long time to boot it up, because it did the Windows Upgrade dance.

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!

db48x• 12 years ago

The real answer is to use a filesystem that doesn't require off-line integrity checks, and to disable automatic fsck when you're stuck with something that does.

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.

watt• 12 years ago

The real story is the toxic attitude of some people on debian-users mailing list.

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.

atoponce5• 12 years ago

https://pthree.org/2012/04/17/install-zfs-on-debian-gnulinux...

mbq• 12 years ago

Same holds for btrfs.

bensummers• 12 years ago

Didn't CoreOS just remove btrfs because it tended to break?

Also: https://rudd-o.com/linux-and-free-software/ways-in-which-zfs...

foxhill7• 12 years ago

no! the whole point of this post is to complain about the attitude of debian devs.

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.

fsniper3• 12 years ago

Of course zfs is superior to many fs in many ways. But this is also a systemd way of telling people to "use this, not anything other. That's the best".

Systemd people are not helping the community.

cmurf2• 12 years ago

Same for XFS and Btrfs, both of which should have fstab fs_passno set to 0, both of which have place holder fsck that don't actually do a file system check. The actual check is done from user space on an unmounted file system.

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.

Thetawaves• 12 years ago

TIL there isn't much professionalism in the systemd camp.

foxhill7• 12 years ago

these are debian developers, i believe.

VLM3• 12 years ago

Not as far as I know. Most devs I know will post with their @debian.org address (or perhaps @ubuntu) when doing debian work in public. Mostly. Also most devs refuse to wallow in the filth that is the mailing lists. On -dev or -project or -private you'll find devs, not so much on -users.

Maybe Maintainers or unofficial, or applicants, at most. Or not very proud of the participation so they semi-obfuscate their address.

atoponce5• 12 years ago

Offline filesystem integrety checks should not be stopped.There is a reason they take place to begin with. From the OP, it sounds like Eduardo takes every opportunity to stop filesystems checks from happening when booting. So long as he has a policy of doing them manually, and understand why they take place, that's fine. So, instead, he should just:

# tune2fs -c 0 /dev/sda1

Or whatever his filesystems are. Then again, this is risky, and the OP should understand why.

foxhill7• 12 years ago

so your fix involves time travel, and you think that's reasonable?

atoponce5• 12 years ago

Time travel? Huh? I'm only stating that if the OP does not want his filesystem checks taking place on boot, rather than Ctrl-C them on every boot, to just disable them completely. Who said anything about time travel?

boomlinde2• 12 years ago

I don't that there is any basis for your assumptions about the poster. What makes you think that he takes every opportunity to stop filesystems checks? Did you read a part of the message that I did not?

atoponce5• 12 years ago

His opening sentence makes it pretty clear that he's executed Ctrl-C enough that he's familiar with it, likely executed it more than once, and expected it to work in Systemd.

dschiptsov• 12 years ago

so, we need systemd-fsckd.

retrogradeorbit4• 12 years ago

That's some good irony. But on the other hand, just you watch...

ultrafez• 12 years ago

Some would already argue systemd is already fsckd.

userbinator• 12 years ago

The way I interpreted his "solution" of "add a kernel boot parameter" was if you want to interrupt the fsck, you should hard-reset the machine to add it on the next boot, making it even more likely your filesystem will need fsck'ing. fsck itself is AFAIK safe with ctrl+c (i.e. it won't corrupt the filesystem further to interrupt it) so this change means users who really want to cancel a fsck have to take the route of possibly causing filesystem corruption themselves. Absolutely fscking insane.

lclarkmichalek• 12 years ago

It's really not hard to add a kernel book param if you're booting via grub

foxhill7• 12 years ago

sigh i don't even.

darklajid• 12 years ago

No, the discussion was mostly about the parameter as a way to suppress fsck if you know you're in a hurry at boot time.

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.

asveikau3• 12 years ago

Is anyone else grossed out with the fact that systemd is parsing the kernel's command line? This is like if some program started reading unrelated crap from another program's command line, just because.

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.

Jasper_• 12 years ago

The kernel command line has widely been considered an API to userspace. That's why the kernel exports it in /proc/cmdline.

the_why_of_y4• 12 years ago

Linus Torvalds thinks it's perfectly fine and exactly how /proc/cmdline was intended to be used, but what does he know anyway? If systemd is doing it, it must be wrong.

http://lwn.net/Articles/593677/

foxhill7• 12 years ago

But remember our current slogan "Linux is all about choice". One can choose to boot with or without "fsck.mode=skip".

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.

mox1• 12 years ago

I wonder if Mr/Mrs ad44@cityscape.co.uk talks to his friends and family like that, what an asshole.

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.

Jakuv2000• 12 years ago

Don't forget Lennart.

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!

pXMzR2A• 12 years ago

these dudes (or girls I dunno)

https://en.wikipedia.org/wiki/Ada_Initiative

ash2• 12 years ago

I think there's an important difference between Linus and some debian-users posters. Linus directs most of his rants towards developers who don't care about users. "Don't break user space" rule is all about users. Compare with some debian-users participants.

rasz_pl• 12 years ago

I love trolling from Brian <ad44@cityscape.co.uk> Every single answer is "you are holding it wrong". And people wonder what is wrong with systemd and its proponents ....

chimeracoder2• 12 years ago

This answer totally sucks, I agree. And I have run into this annoyance myself (I've been using systemd for almost three years).

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.

fsniper3• 12 years ago

Well, this answer is a workaround. And I'm sorry it's a ridiculous one. What if I'm not on a laptop? What if this is a server system?

chimeracoder2• 12 years ago

this answer is a workaround. And I'm sorry it's a ridiculous one.

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.

Aardwolf• 12 years ago

Can someone explain why systemd which seems so hated (by me too due to wrong philosophical decisions), yet managed to convince almost all big distros (including the one I use) to use systemd by default?

Thanks.

the_why_of_y4• 12 years ago

Thankfully mke2fs(8) has been changed not to enable enforced fsck intervals some years ago (in 2011), so it's no longer necessary to manually disable it with "tune2fs -i 0 -c 0" on new deployments.

Skipping fsck during boot with systemd?

Related Stories