Re: Skipping fsck during boot with systemd?
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.
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.
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).
> After all, it's *my* computer, and *I* want to be in control of it.
Yes, that's perfectly understandable.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: