> 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.
I wonder if Mr/Mrs [email protected] 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.
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.
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.
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.
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.
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.
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.
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".
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!
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.
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?
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.
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.
I love trolling from Brian <[email protected]>
Every single answer is "you are holding it wrong". And people wonder what is wrong with systemd and its proponents ....
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.
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.
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?
[+] [-] foxhill|11 years ago|reply
..
> 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|11 years ago|reply
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.
[+] [-] alaaibrahim|11 years ago|reply
[+] [-] mackwic|11 years ago|reply
[+] [-] seba_dos1|11 years ago|reply
[+] [-] userbinator|11 years ago|reply
[+] [-] asveikau|11 years ago|reply
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.
[+] [-] darklajid|11 years ago|reply
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.
[+] [-] lclarkmichalek|11 years ago|reply
[+] [-] db48x|11 years ago|reply
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|11 years ago|reply
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.
[+] [-] foxhill|11 years ago|reply
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.
[+] [-] cmurf|11 years ago|reply
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.
[+] [-] fsniper|11 years ago|reply
Systemd people are not helping the community.
[+] [-] mbq|11 years ago|reply
[+] [-] jbk|11 years ago|reply
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|11 years ago|reply
[+] [-] raverbashing|11 years ago|reply
There are enough ironic/rude answers, failure to solve the problem or give a good workaround, etc
Now imagine this with paying customers.
[+] [-] uaygsfdbzf|11 years ago|reply
https://lists.debian.org/[email protected]....
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
[+] [-] ash|11 years ago|reply
[+] [-] getsat|11 years ago|reply
[+] [-] Thetawaves|11 years ago|reply
[+] [-] foxhill|11 years ago|reply
[+] [-] Aardwolf|11 years ago|reply
Thanks.
[+] [-] chimeracoder|11 years ago|reply
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|11 years ago|reply
[+] [-] dschiptsov|11 years ago|reply
[+] [-] ultrafez|11 years ago|reply
[+] [-] retrogradeorbit|11 years ago|reply
[+] [-] the_why_of_y|11 years ago|reply
[+] [-] rasz_pl|11 years ago|reply
[+] [-] olgeni|11 years ago|reply
[+] [-] mackwic|11 years ago|reply
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.
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] atoponce|11 years ago|reply
# tune2fs -c 0 /dev/sda1
Or whatever his filesystems are. Then again, this is risky, and the OP should understand why.
[+] [-] boomlinde|11 years ago|reply
[+] [-] foxhill|11 years ago|reply