Boot animations start too late to be useful

[Daniel van Vugt]

Boot animations start too late to be useful

Modern systems spend all their boot time (a couple of seconds) decompressing the kernel. During that time the user only sees the static BIOS logo (ACPI BGRT). Then when Plymouth can finally start animating, the startup process is already finished and there's virtually no time left to show any useful animations.

This could be fixed in:

  grub: By adding a splash under the BIOS logo to show some progress _before_ a Linux kernel is even started

and/or

  plymouth: By preferencing legacy framebuffer devices (like EFI) over DRM, if we find those are available a few seconds sooner. That would also fix bug 1868240 completely, and bug 1836858 mostly as the flicker moves to when the login screen starts.

[Daniel van Vugt (vanvugt)]

https://discourse.ubuntu.com/t/testing-flickerfree-boot/11854/19

[Dimitri John Ledkov (xnox)]

Not committing to do this before focal GA

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Daniel van Vugt (vanvugt)]

It seems the reason why SimpleDRM hasn't solved this in Noble is because Plymouth intentionally ignores it:

  "ignoring since we only handle SimpleDRM devices after timeout"

and waits for a better DRM driver, which takes another few seconds.

[Daniel van Vugt (vanvugt)]

This will get the same initramfs-tools fix as bug 1970069. After that, the only way to make Plymouth start sooner will be to use kernel parameter 'plymouth.use-simpledrm', but we probably don't want that by default so as to avoid regressing on bug 2054769.

[Daniel van Vugt (vanvugt)]

The patch proposed in https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1970069/comments/91 will help here, but since it might not be the last plymouth change required for this issue, it doesn't mention bug 1869655.

[Launchpad Janitor (janitor)]

This bug was fixed in the package initramfs-tools - 0.142ubuntu23

---------------
initramfs-tools (0.142ubuntu23) noble; urgency=medium

  [ Daniel van Vugt ]
  * hooks/framebuffer: Only add simple/tiny framebuffer drivers. This is to
    limit the size of initrd when FRAMEBUFFER=y is soon enabled for desktop
    installations (LP: #1970069, #1869655).

  [ Benjamin Drung ]
  * autopkgtest: Increase QEMU timeouts on arm64/armhf
  * hooks/framebuffer:
    - Move adding framebuffer drivers into auto_add_modules
    - Drop looking in $MODULESDIR/initrd/ for kernel modules
    - Support MODULES=dep in framebuffer hook

initramfs-tools (0.142ubuntu22) noble; urgency=medium

  * autopkgtest: update systemd-udevd path from /lib to /usr/lib

initramfs-tools (0.142ubuntu21) noble; urgency=medium

  [ Benjamin Drung ]
  * configure_networking:
    - Increase minimum timeout to 30 seconds
    - Fix configuring BOOTIF when using iSCSI (LP: #2056187)
    - Set interface MTU if provided by the DHCP server (LP: #2056194)
    - log sleep durations before retries
  * Copy /etc/passwd into the initramfs to allow dhcpcd running as dhcpcd user
  * Replace obsolete pkg-config build-dependency by pkgconf

  [ Dan Bungert ]
  * Restore nvdimm and dax pmem-related modules (LP: #1981385)

 -- Benjamin Drung <email address hidden> Thu, 21 Mar 2024 10:57:54 +0100

[Daniel van Vugt (vanvugt)]

No longer in progress. You can get to 100% fixed by adding kernel parameter 'plymouth.use-simpledrm' but I'm not totally sure that's something everyone will want.

[Mario Limonciello (superm1)]

> No longer in progress. You can get to 100% fixed by adding kernel parameter 'plymouth.use-simpledrm' but I'm not totally sure that's something everyone will want.

The main reasons that can be problematic are rotation right? I wonder if the right way to go about it is a heuristic within plymouth to decide whether it can/should output. For example if there are no rotation sensors on the machine, or by looking at the orientation on them?

[Daniel van Vugt (vanvugt)]

More than rotated framebuffers, defaulting to simpledrm means Plymouth doesn't know the physical monitor dimensions. So it uses heuristics and that leads to the logo scale not matching the login screen which would be a regression of bug 2054769. Actually it already happens on some slow booting machines occasionally. But that too can be worked around with:

  plymouth.force-scale={1,2}

And no, checking for rotation sensors is not a good idea because it would give the wrong result for laptop/tablet convertibles that don't have rotated framebuffers.