[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#734093: debian-installer: install plymouth by default



On Tue, Jan 21, 2014 at 07:43:41PM +0100, Andreas Cadhalpun wrote:
> On 21.01.2014 03:35, Josh Triplett wrote:
> > If splash were a non-default boot option, and plymouth did nothing
> > unless the kernel command line had that option, that seems entirely
> > reasonable.  Very easily done; just add this to the plymouth service,
> > for instance:
> > ConditionKernelCommandLine=splash
> 
> I'm not sure what you are trying to say here, but you're actually
> quoting line 7 of plymouth-start.service. ;)

...good to know. :)

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.

(On the other hand, if apt-get install plymouth enabled the splash by
default, that's not hard to do either.)

> > 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.

> > When you're attempting to boot in a fraction of a second, 86ms is an
> > eternity.  If your boot process takes long enough that 86ms is lost in
> > the noise, it's taking *far* too long.
> 
> It looks as if I didn't make myself clear enough. Plymouth does
> *not* make the boot 86ms slower.
> Looking a bit closer at my startup:
> plymouth-start.service is executed in parallel to
> systemd-fsck-root.service and finishes a lot before that.
> plymouth-read-write.service is executed, while network.service
> blocks the boot.
> plymouth-quit.service and plymouth-quit-wait.service are executed in
> parallel, while network-manager.service blocks the boot.
> 
> 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.

> > Furthermore, I don't think that counts the delay incurred by any mode
> > switches caused by Plymouth, and to the best of my knowledge only the
> > most modern systems and hardware can avoid those mode switches, so
> > you're actually incurring disproportionately more of a delay on
> > lower-end systems.
> 
> For these reasons I wanted to compare the whole boot time
> with/without plymouth, but unfortunately for me any difference
> vanishes in the noise. If you don't have such varying boot times, it
> would help if you could carry out this measurement.

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. :)

> > On Mon, Jan 20, 2014 at 11:12:21PM +0100, Andreas Cadhalpun wrote:
> >> Of course, this would be the best solution. So as soon as Debian
> >> boots even on old grandma's computer in less then a second, plymouth
> >> will be unnecessary. ;)
> >> Unfortunately, this seems rather like utopia.
> >
> > It's spelled "systemd". ;)
> > But seriously, that's very much the goal.  And I think "less than a
> > second" is not required to make a splash screen unnecessary; less than
> > 5 seconds seems quite sufficient to make a splash screen superfluous.
> > Plymouth and other splash screens were created when the norm was for a
> > system running a desktop environment to take 30-60 seconds to boot; on
> > such systems, a splash screen and progress bar seems quite reasonable.
> 
> 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.

>  * ...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.  clamav-daemon
shouldn't be running on non-servers, in any case.

Ideally, systemd should launch X and gdm (socket-activated) in the very
first batch of services launched.

- Josh Triplett


Reply to: