Re: Bug#734093: debian-installer: install plymouth by default
Hi Josh,
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)?
Actually Antoine requested that plymouth should enable the splash boot
option upon installation, but we came to the conclusion that this would
be too difficult to implement, because plymouth would have to check,
which boot loader is installed, and add a trigger if no boot loader is
installed yet...
But the installer could add the 'splash' boot option, when installing
the boot loader.
> 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.
By the way, how can I make sure, that the kernel doesn't change the
video mode?
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?
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)?
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.
* ...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.
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.
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.
Best regards,
Andreas
Reply to: