Re: Bug#734093: debian-installer: install plymouth by default
On Wed, Jan 22, 2014 at 12:53:05AM +0100, Andreas Cadhalpun wrote:
> On 21.01.2014 23:14, Josh Triplett wrote:
> >In that case, to clarify further: I don't have any objection to
> >installing plymouth as long as the "splash" option is *not* included by
> >default. It's a minor waste of disk space if unused, but it might be
> >worth the convenience of being able to quickly turn on the splash.
>
> As far as I know, this would be the outcome, if plymouth was just
> added to task-desktop without further action of the installer.
> But this is not what I (and Antoine) intended with this bug report,
> as this wouldn't really change much for 'novices' that don't know
> how to change boot options.
>
> >(On the other hand, if apt-get install plymouth enabled the splash by
> >default, that's not hard to do either.)
>
> So you agree that it is easy enough to manually remove the 'splash'
> boot option if you don't like it (assuming it was enabled by
> default)?
I don't see where you got that from what I said. No, I'm still arguing
against having a splash screen by default. I was saying that two
options potentially make sense: installing it and leaving it disabled,
or leaving it uninstalled but having it active on install. The latter
seems potentially easier for a novice user than the former: just install
plymouth and you have a splash.
> > On Tue, Jan 21, 2014 at 07:43:41PM +0100, Andreas Cadhalpun wrote:
> >> On 21.01.2014 03:35, Josh Triplett wrote:
> >>>On current systems, there's an even better way to do that: make sure
> >>>the kernel doesn't change the video mode set by the BIOS, and doesn't
> >>>draw on the screen at all until X takes over. Then, you go straight
> >>>from the BIOS or bootloader to your display manager login prompt.
> >>>The display manager can even crossfade from the former to the latter,
> >>>if you like.
> >>
> >>This sounds very nice, but what happens if the boot hangs and you
> >>want to look at the boot messages? And how would you enter a
> >>password for an encrypted partition?
> >
> >If you need to enter a passphrase, you can keep the same mode, switch to
> >either a text or graphical passphrase prompt.
>
> So the kernel would have to draw on the screen, before X takes over.
For the text variation, yes; or, long-term, you'd use something like
kmscon.
> By the way, how can I make sure, that the kernel doesn't change the
> video mode?
Take a look at the work on i915 and "fastboot".
> >>So it *seems* that plymouth makes the boot slower by 0ms!
> >
> >That would be worth measuring. A bootchart showing the disk and CPU
> >activity of plymouth would help greatly here.
>
> How can one create such a bootchart?
Boot with init=/usr/lib/systemd/systemd-bootchart .
> >I don't have a strong interest in splash screens, so it'd fall fairly low on
> >my list, but after I work on integrating all the services installed on
> >my system with systemd, I might be interested. :)
>
> That's great. :)
> The funny thing is, I'm also currently trying to write unit files
> for the services on my machine, that don't have one.
> I usually manage to get them working for me, but I'm new to systemd,
> so I'm not sure they are totally correct, as there are things in
> init scripts ... *argh* ...
> Perhaps you can help me (or tell me who to ask for help)?
Happy to chat by IRC, Jabber, or email; the #systemd IRC channel and the
upstream mailing list are also extremely helpful.
> >>Of course, systemd makes the boot much faster, but systemd cannot do
> >>magic, or can it...
> >> * ...boot in less than 5 seconds, if the kernel takes longer than
> >>10 seconds?
> >
> >No, of course not. But if the kernel takes more than a fraction of a
> >second to exec init, it needs fixing.
>
> I actually thought about the time that is called 'kernel' (in
> contrast to 'userspace') by systemd-analyze plot.
That's what I'm talking about; that should take almost no time.
> >> * ...boot in less than 5 seconds, if a particular service takes
> >>longer than 10 seconds (e.g. clamav-daemon)?
> >
> >Sure, as long as gdm and X don't need clamav-daemon.
>
> How can I achieve that?
> Currently it seems as if multi-user.target waits for exim4.service,
> which starts only after clamav-daemon.service is ready.
Ieally, by uninstalling exim4 and clamav-daemon; getting the MTA removed
from standard is another big goal of mine. :)
But more seriously, as far as I know you just need to make sure that gdm
doesn't depend indirectly on exim4 or clamav-daemon.
> >clamav-daemon shouldn't be running on non-servers, in any case.
>
> There might be reasonable use cases for this or other services that
> take long to start.
Sure, but almost none of them should be in the critical path to launch
gdm.
> >Ideally, systemd should launch X and gdm (socket-activated) in the very
> >first batch of services launched.
>
> I'm afraid I don't see how this would help, as they need at least
> local-fs.target.
Sure, like almost everything else, but just about everything else they
need should be able to run in parallel. (Remember one of the huge
benefits of socket/bus/etc activation: you can launch a service and its
dependencies in parallel.)
- Josh Triplett
Reply to: