Re: Bug#734093: debian-installer: install plymouth by default
Hi Josh,
On 22.01.2014 01:30, josh@joshtriplett.org wrote:
On Wed, Jan 22, 2014 at 12:53:05AM +0100, Andreas Cadhalpun wrote:
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.
Sorry that I misunderstood you.
Why do you think it would be bad to enable 'splash' by default?
And yes, the latter option would be easier for the user, but probably
more difficult for the package maintainer.
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".
Thanks for the info. I tried to use 'i915.fastboot=1', but unfortunately
this just produced:
[drm:hsw_unclaimed_reg_check] *ERROR* Unclaimed write to 68080
[drm:hsw_unclaimed_reg_check] *ERROR* Unclaimed write to 68070
[drm:intel_uncore_check_errors] *ERROR* Unclaimed register before interrupt
[drm:hsw_unclaimed_reg_check] *ERROR* Unclaimed write to 68074
[drm:hsw_unclaimed_reg_check] *ERROR* Unclaimed write to 68080
[drm:hsw_unclaimed_reg_check] *ERROR* Unclaimed write to 68070
[drm:hsw_unclaimed_reg_check] *ERROR* Unclaimed write to 68074
I guess this is still in development.
How can one create such a bootchart?
Boot with init=/usr/lib/systemd/systemd-bootchart .
This seems not to work for me, as I can't find any .svg's in /run/log.
I also tried 'init=/lib/systemd/systemd-bootchart' (the actual location,
this seems to be documented wrong) and this also didn't work.
Happy to chat by IRC, Jabber, or email; the #systemd IRC channel and the
upstream mailing list are also extremely helpful.
Thanks, I'm going to send you a mail.
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.
OK, the 10 seconds it takes for me include the time I need to type the
password for the encrypted partition, but subtracting that, I think it
still takes something like 5 seconds.
* ...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. :)
You're funny. ;)
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.
Unfortunately, exim4 has still no unit file and I haven't (yet) been
able to create one. So analyzing/changing the (implicit) dependencies
is not that easy.
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.
That's true, but currently it seems that every service has to be
finished before graphical.target (except
systemd-update-utmp-runlevel.service).
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.)
I see. Thanks for the explanation.
Best regards,
Andreas
Reply to: