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 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140120175125.GA5607@jtriplet-mobl1
