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. > 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. > 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. > 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. 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. -- see shy jo
signature.asc
Description: Digital signature
