Re: Skipping fsck during boot with systemd?
Hello,
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
bugs?
1. Add "Conflicts=shutdown.target" to the [Unit] section of
fsck@.service
This should at least make Ctrl-Alt-Del work, not sure what happens on
next reboot though (is the fsck counter reset?).
https://bugzilla.redhat.com/show_bug.cgi?id=719952
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.
https://bugzilla.redhat.com/show_bug.cgi?id=799574
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,
Andrei
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: