Re: Bug#734093: debian-installer: install plymouth by default
On Wed, Jan 22, 2014 at 02:53:51AM +0100, Andreas Cadhalpun wrote:
> 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?
Because then the splash screen would show up. :)
See my previous mails in this thread; I would like to avoid having a
splash screen enabled by default, in favor of keeping boot silent on
success, and making it as quick as possible.
> And yes, the latter option would be easier for the user, but
> probably more difficult for the package maintainer.
Seems rather straightforward for both, really; why would it be more
difficult for the 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.
You probably need newer kernel bits than you have, if you're seeing
those messages.
> >>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.
That may have been fixed in more recent versions of systemd;
discrepancies like that, which only matter on systems that still keep /
and /usr separate, will be an ongoing issue.
I don't know why you aren't seeing the files in /run/log. Do you see
them in the journal?
> >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.
Encryption will really throw off your numbers. If you want to do
boot-time testing, you should use a test system or test partition
without encryption.
(Also, if you're using encryption, you're probably also using LVM, which
causes major boot-time slowdowns on all distributions, and is outright
broken on Debian systems. If udevadm settle is running at all in your
boot path, that 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.
> >>
> >>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. ;)
Thanks. I never seem to run out of windmills. :)
> >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.
That would be a problem, yeah.
- Josh Triplett
Reply to: