Re: Bug#734093: debian-installer: install plymouth by default
On Mon, Jan 20, 2014 at 06:05:23PM -0400, Joey Hess wrote:
> Josh Triplett wrote:
> > > The latter; d-i does not run with systemd.
> >
> > If Debian ends up adopting systemd as the default, that seems likely to
> > change.
>
> Seems unlikely; I doubt that the Linux kernel will ever require systemd
> to boot an embedded system such as d-i.
I wasn't suggesting a requirement; I was suggesting that if systemd
becomes the default, there will likely be advantages to switching d-i to
use the same init that installed Debian systems do.
> > Given that the resulting installed system regenerates the grub menu file
> > using the scripts in grub-common, I would hope that d-i matches whatever
> > configuration file grub-common would generate; if it doesn't, that seems
> > like a bug, since that configuration will vanish the next time
> > update-grub runs.
>
> This is all done via preseeding the grub package's debconf settings,
> in a way that will persist unless the user changes it.
Ah, I see; it ends up in /etc/default/grub.
In any case, still not something that d-i ought to override
unilaterally.
> > Yes, it's quite useful *when it has gotten into such a situation*.
> > Otherwise, it's noise. Thus, the right fix would be to have systemd
> > become chattier about *problems* where it isn't already, rather than
> > chattier in general.
>
> I don't know if systemd's design lets it detect such a problem. IIRC there
> is some sort of 5 minute timeout when things have gotten unavoidably
> deadlocked, after which it tries to break the deadlock.
That very long timeout exists because systemd should not lightly take
drastic steps to break a deadlock. (And ideally, systemd should detect
and scream about that deadlock when first created.)
Showing messages, on the other hand, is not something that needs a long
timeout before doing; a short one will suffice, to cover the common case.
> > So let's fix *that* bug. systemd records all of the bootup messages,
> > whether it shows them or not; it should be easy enough to emit them when
> > something goes wrong, or even just if bootup takes more than a defined
> > amount of time. (That much would be useful in general to detect slow
> > services: "Still launching $servicename: $time_elapsed", with the time
> > ticking upward and the messages not showing up until after several
> > seconds spent launching the same service.)
> >
> > Would that address your concern?
>
> I suppose it would, if the timeout was not of the 5 minute variety.
> Or Systemd could just display the buffered messages during boot if the
> user presses a key before getty.
What about a 10 second timeout (configurable) before it starts showing
messages, if the target has not yet been reached? That's several times
what a normal desktop environment should require before reaching at
least X. So, normal system boots should never show up, but excessively
slow or broken boots will, with no interaction required and no noise in
the common case.
Watching for a key seems like a good idea as well.
> But it seems a lot more complicated than just flashing all messages up on
> the screen in the < 2 seconds that it takes my laptop to boot to X once
> systemd has started.
Quietness on success has some significant advantages to justify not
disabling it: it makes errors stand out (by not drowning them in
successes), it helps avoid spurious support questions from users
confused by the startup messages (sadly far too common), and it makes
the boot process more aesthetically pleasing in much the same way as a
splash screen.
- Josh Triplett
Reply to: