

Skipping fsck during boot with systemd? - pwg
https://lists.debian.org/debian-user/2014/12/msg00184.html

======
foxhill
> 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
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
Don't forget Lennart.

Just watch this video of him disrupting a talk:
[https://www.youtube.com/watch?v=ZTdUmlGxVo0](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!

~~~
the_why_of_y
Yes it is quite unbelievable how much bullshit and mis-information the
presenter is talking, luckily somebody who actually knows the stuff was in the
audience to point out some of the actual requirements of modern desktops.

~~~
digi_owl
That "modern desktop" is why many stopped using Windows in the first place.

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

~~~
mackwic
A fairly bad answer, we can all admit that.

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

~~~
teraflop
According to that thread, it has been on the TODO list for 3.5 years with no
further signs of being implemented.

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

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

~~~
the_why_of_y
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/](http://lwn.net/Articles/593677/)

~~~
asveikau
There is a lot of strong criticism of systemd in that thread. I was actually
considering posting it as sympathetic to my point. It simultaneously expresses
what both of us are saying. (You can read the command line, but don't do it
for stupid shit.) From your link:

> But the problem appears when system services seem to think that they _own_
> those flags, and nothing else matters, and they don't do something "sane"
> any more.

Then later:

> It does become a problem when you have a system service developer who thinks
> the universe revolves around him, and nobody else matters, and people
> sending him bug-reports are annoyances that should be ignored rather than
> acknowledged and fixed. At that point, it's a problem.

Next paragraph indicates the rant is directed at Kay Sievers, udev and systemd
developer, and his "continued bad behavior".

It does ring true for me as a user, I have noticed systemd-based systems spam
a lot of things that used to be "for the kernel" and a bit more sacred, like
dmesg and command line.

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

~~~
atoponce
[https://pthree.org/2012/04/17/install-zfs-on-debian-
gnulinux...](https://pthree.org/2012/04/17/install-zfs-on-debian-gnulinux/)

~~~
VLM
But then you're stuck with systemd, which you could avoid with Freebsd.

Its kind of like upgrading an outdoor carpentry project, like a deck, from
nails to deck screws, then just in case you miss the feeling of hitting your
thumb with a hammer, someone helpfully finds a link to install deck screws
using a hammer. That's impressive in its own way, but ... I think I'll
continue moving everything to Freebsd instead.

------
jbk
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!

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

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

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

[https://lists.debian.org/20141213135648.GA14679@fishbowl.rw....](https://lists.debian.org/20141213135648.GA14679@fishbowl.rw.madduck.net)

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](https://bugs.debian.org/773267)

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

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

~~~
vertex-four
> 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.

Is this polite or helpful in solving the issue? It's being preachy about the
idea that nobody ever makes wrong choices, ever, and should definitely never
be given the opportunity to fix their mistakes.

~~~
retrogradeorbit
If only we could all be as perfect as Brian! I find it funny that he rants
about choice. The thing I dislike most about systemd is that it is removing
choice! I suppose I am just going to have to go and choose to use FreeBSD.

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

~~~
foxhill
these are debian developers, i believe.

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

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

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

~~~
fsniper
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?

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

~~~
fsniper
You make it clear that you are not backing Brian. I'm just trying to tell the
shortcomings of your trick. Also in this case it also involves back in time
travel or being prepared. If you want to be prepared tune2fs would be a better
choice.

~~~
mst
It was incredibly obvious that he already understands those are shortcomings.

You're just stating the obvious in a condescending fashion. Reddit is over
there.

------
dschiptsov
so, we need systemd-fsckd.

~~~
ultrafez
Some would already argue systemd is already fsckd.

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

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

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

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

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

The filesystem maintainers seem to disagree: since 2011 mke2fs(8) creates new
file systems without enforced fsck intervals.

[http://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/commit/?id=...](http://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/commit/?id=3daf592646b668133079e2200c1e776085f2ffaf)

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

~~~
boomlinde
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?

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

~~~
boomlinde
OK, so it's _pretty clear_ that he's _likely_ to have pressed ^C more than
once. That sure is a strong foundation for saying that it sounds like he
_takes every opportunity to stop filesystems checks_.

... Especially since he didn't go out of his way to explain the exceptional
circumstances that prompted him to try to skip fsck in the reported case... or
did he?

