Re: Skipping fsck during boot with systemd?
On 12/8/2014 9:42 AM, Henrique de Moraes Holschuh wrote:
> On Mon, 08 Dec 2014, Christian Groessler wrote:
>> Why don't the systemd proponents understand that someone might want to
>> interrupt a running fsck? Don't scrutinize the reasons, just accept
>> the fact.
> Handwaving issues away is intolerable behavior in a professional capacity,
> but in this particular case you can just ignore the handwaving entirely, as
> it is not being done professionaly, nor is it being done by either the
> debian maintainers or upstream.
> This thread should have died off the moment it became clear that handling
> the interrupt signal in fsck _is_ in systemd's upstream todo file and also
> reported as a bug that is still open and _not_ tagged wontfix in Debian.
I disagree. The original bug was filed on 2011-07-08 - almost 3.5 years
ago, and nothing has been done on it. And on 2012-05-06, there was an
acknowledgement that it is on the upstream's TODO list. That's over 2.5
It obviously is causing a lot of people problems, and is not being fixed
in a timely manner. And if people don't talk about the problems it is
causing, chances are it's not going to be fixed in the near future.
> The useful thing to do now is to come up with tested patches, file them on
> the bug report, and start the process to get them reviewed and accepted.
That would be great if I had the time to learn systemd, figure out how
(and why) the ability to interrupt fsck was disabled, how to re-enable
it and ensure there are no side effects. Note that while I develop
custom device drivers and applications, I've never dug into the init
system, so it would be a large learning curve. That's days, if not
weeks that I don't have.
Or, the developer of systemd, who should be intimately familiar with his
code, could probably do it in a few minutes, or at most, a couple of
hours. But it's obviously not a high priority.
> We broke the signal delivery in sysvinit as well for a while, when we added
> parallel execution (startpar). People would ^C and the signal would hit
> some unintended process because there were several running at the same time,
> all with the console open. This could break the boot horribly, of course.
> The initial "fix" blocked all handlign of the interrupt signal, with pretty
> much the same consequences as the current issue in systemd-fsck. I am not
> sure how well it got fixed in the end on the sysvinit+startpar+fsck side, it
> was some time ago.
> The truth is that keyboard-raised signal delivery can be hard to get right
> when you have both "parallel execution" and "console". And it can get
> either much more difficult or much easier to do right when you have a
> initsystem IO multiplexer front-end on top (i.e. stuff like plymouth).
Hence the side effects I spoke of above.
>> After all, it's *my* computer, and *I* want to be in control of it.
> Yes, that's perfectly understandable.
I haven't been bitten by this bug yet, because I'm not running Jessie.
But it's just another reason why it's not good for servers, and even
causes major problems for users.