[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Skipping fsck during boot with systemd?


replying inline

On 10/12/2014 14:04, Andrei POPESCU wrote:
On Mi, 10 dec 14, 08:53:08, tv.debian@googlemail.com wrote:
All this just because you
won't admit that systemd took away a feature, and that it is systemd's
business to bring it back.

Mmm, I'll have to chime in here. The fact is, systemd never implemented
this feature, while your statement sounds like this did work at some
time but those evil systemd developers disabled it on purpose, which I'm
sure is not you intention :)

I understand your reasoning here, and no I am not implying that systemd had this feature working at some point, I which it had, but has a long time Debian user I see my system of choice releases has an evolution, with improvements and refinements, technical adaptations to the new gear, ...etc . When a working feature in versions "a","b","c","d" disappears in version "e", it is a regression to me unless their is a rational behind it, i.e. the feature was redundant, technically obsolete or such. When this is not the case I look into it more closely, and find that setup "a" with software "x" has the feature, and installation with software "y" has not, software "y" being the default, I consider it a regression, and blame software "y" for it (because it is the default, otherwise it would be fine). It seems to me that the default setup should be at least equal feature-wise to the preceding one, otherwise it is not worth being the default. Of course systemd bringing improvements in other areas can be seen as balancing whatever feature it takes away, but for some use case it may not always be the case. Some of my computers boot slower, if ever, with systemd, and shutdown much slower. Not that I care for speed in those areas, on laptops I have suspend/resume on SSD for that, and on workstation/servers I don't care. I can't interrupt any of systemd's business (not only fsck), even when it's obviously looping hopelessly. Just to name two use cases where systemd is showing clear regressions to me. I am not implying that the developers did plan for the endless looping of the services, but they sure didn't plan out of it.

Just for clarification I don't consider systemd anyone (developer, maintainer, strong supporter) "evil", I am not in the "howling to the full moon" crowd, I am just more and more skeptical of systemd adoption as default init for the next Debian stable.

Also, the systemd developers have no obligation whatsoever to implement
any particular feature, regardless if that particular feature was
implemented by sysvinit or not.

I understand that, they are already too busy adding features as it is, and personally I don't care what they add or not. The problem looks different from Debian as a system point of view, where systemd has to fit in. It seems to me that it is working the other way right now. Debian 8 is being rebuilt around the ignition, in a hurry.

To (try to) get back on topic, due to the freeze it's quite obvious that
even if a patch implementing this would be made available today it won't
make it into Jessie, so if you care about this and consider using Jessie
with systemd your best bet at the moment are workarounds.

I don't, I use sysvinit and test systemd regularly. It works on nearly all my laptops, where arguably there isn't much to do, but fails me on most of my workstation/servers. I am usually ok with workarounds, running Testing or Sid routinely, but for stable I am not a strong supporter of duck tape.

Speaking of which, did anyone here test the two proposed in the Fedora

1. Add "Conflicts=shutdown.target" to the [Unit] section of

This should at least make Ctrl-Alt-Del work, not sure what happens on
next reboot though (is the fsck counter reset?).


2. Add "StandardInput=tty" to fsck@.service.

In theory this should allow cancellation of the fsck, but might have
undesired effects if a fsck is started after boot is completed (with
'systemctl start fsck@<device>'?).

If somebody intends to test this it should probably be done on a spare
machine and with partitions that you can afford to loose.


Cool, that is why Debian planned to include systemd as an option for a full stable release, and then switch to it as default when the courageous testers have hammered out the most nasty integration bugs. Or am I missing something ? /gentle irony

Of course, there's also the option of completely disabling automatic
fsck (there are several ways to do this), as I understand is the default
for new enough filesystems. This would make more sense for me on systems
with bad power (you'd still get the "bad shutdown" check).

Yes, disabling and doing manual checks from time to time is a possibility, but you'd have to convince all users to hand their gears to an admin outside of business hours. The said admin (who might just bee a teacher in fact) might not be happy with the idea of a week-end spent at fsck'ing the world out of the compulab, just because of systemd. With the conditions I mentioned earlier running a fsck regularly is a good thing, just not being able to interrupt it in case of emergency isn't.

Kind regards,

Thank you Andrei for your time spent trying to help people out, seeing your name all around the mailing list and the bug tracker made me wonder if there were several of you ;-) .

Reply to: