Re: Bug#734093: debian-installer: install plymouth by default
On Mon, Jan 20, 2014 at 01:19:25PM -0400, Joey Hess wrote:
> Josh Triplett wrote:
> > Do you mean the options used within d-i itself, or on the installed
> > system?
>
> The latter; d-i does not run with systemd.
If Debian ends up adopting systemd as the default, that seems likely to
change.
> > If you mean the latter, that configuration is owned by the grub-common
> > package, not by d-i.
>
> grub-installer configures the grub menu file to include quiet and other
> kernel options.
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.
> > And in any case, grub-common should not be abusing
> > its configuration of the *kernel* command line to override the defaults
> > of packages other than the kernel.
>
> d-i is not setting quiet with the intention of making systemd quiet,
> but with the intention of suppressing ugly kernel messages.
> And I really only wanted to do that for desktop installs.
>
> The difference is that verbose kernel messages as it enumerates all
> hardware and so on are unlikely to be useful if you're sitting at a
> system that has somehow deadlocked on boot, while seeing which daemons
> systemd is starting is, IME, quite useful when it's gotten into such a
> situation..
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.
> > More generally, a quiet boot is a feature, not a bug. The bug you filed
> > is absolutely legitimate, but making bootup noisier by default isn't the
> > right way to fix it. To the best of my knowledge, with "quiet", systemd
> > is supposed to behave the same way the kernel does: shut up about
> > commands that succeed, but still shout about failures, making them
> > *easier* to notice. If that's not happening, that's a bug to be fixed.
>
> Well, I filed the bug I mentioned about just that. I have seen systemd
> boot to a black screen with no indication what it was waiting on. I've
> seen this more than once, in different installations.
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?
> > And in any case, step 1 in debugging a failure to boot should be "try
> > booting without quiet" (or boot in recovery mode, which also omits
> > quiet).
>
> No, step 1 in debugging should be "look at the screen and see what went
> wrong".
Which is exactly why systemd should be telling you what went wrong.
That doesn't mean it should be telling you what went right.
> systemd has a great web page with extensive documentation about
> how to coax information out of systemd when it fails, but this web
> page is entirely useless when you were booting the computer you use to
> read web pages. And it's nearly as useless when you're debugging someone
> else's system remotely and can't get them to read off the last things
> that went on without first walking them through a crazy kernel command
> line edit process in the boot loader.
Choosing the recovery option isn't overly difficult, and doesn't require
manually editing the kernel command line. If you don't need single-user
mode, just dismiss the prompt to enter the root password for a recovery
shell, and you'll get a normal boot without quiet.
But let's see if we can avoid even the need to do that.
- Josh Triplett
Reply to: