Re: Bug#734093: debian-installer: install plymouth by default
On Wed, Jan 22, 2014 at 04:28:27AM +0100, Andreas Cadhalpun wrote:
> On 22.01.2014 03:05, Josh Triplett wrote:
> >On Wed, Jan 22, 2014 at 02:53:51AM +0100, Andreas Cadhalpun wrote:
> >>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?
>
> How to make sure the 'splash' option is added to the boot command
> line (and stays there, even if you purge grub and install lilo or
> similar things)?
I meant, you could just stop checking for "splash", and just
unconditionally provide a splash if installed; users who don't want a
splash could then just not install plymouth. It's a lot like
/etc/default files: why support having a service installed-but-disabled?
But that's an issue for another day, and not really that relevant here.
And in any case, that introduces the need for a transition, as well.
> >>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.
>
> I just installed linux-image-3.13-trunk from experimental and still
> see these errors.
Odd. Please report a bug in the fd.o bugzilla on the i915 driver.
> >>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?
>
> I tried:
> sudo journalctl -F BOOTCHART
> This gave no output.
I don't know what isn't working there; you might try the systemd IRC
channel or mailing list, to see if they know what's going on.
> >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.
>
> Why? I'm more interested in the boot time of the machine I use than
> in the boot time of some test system.
Because you'll never be consistent enough typing in your passphrase to
allow accurate comparisons of boot time. You mentioned wanting to
compare the whole boot time with and without plymouth; there's really no
hope of doing that when the boot process depends on user interaction.
> >(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.)
>
> Luckily I have no problems with LVM and systemd. (lvm2.service takes 548ms)
> At least the systemd-udev-settle.service is not called during boot.
See the ongoing discussions about LVM and systemd in the bug on LVM
(which has gotten wrapped up into the whole init system debacle). LVM
currently isn't coping with dynamic hardware correctly. And 548ms is
ridiculous.
- Josh Triplett
Reply to: