Plymouth uses the text-based boot screen on some machines, sometimes

[Simon Quigley]

On several flavors (I have confirmed Ubuntu Unity and Lubuntu thus far), if the machine does not have much resources, it falls back to the text-based Plymouth boot screen.

Steps to reproduce:
 - Find a machine with 1 core and 2 GB of RAM, a virtual machine will do.
 - Boot up a live ISO of Lubuntu or Ubuntu Unity.

Expected result: the appropriate graphical splash screen is shown.
Actual result: Only the text-based splash screen for Plymouth is shown.

[Tim Andersson (andersson123)]

With a libvirt vm (using virt-manager) and a VM with:
- 2GB ram
- 1 core
- 50G of disk space

I do *not* encounter this bug when booting with the following ubuntu-unity iso:
3b3894883d9c02edccb7f007a9d7501f8fe23e171dda2638696250fcf3559295 *noble-desktop-amd64.iso

dated:
2024-04-21 13:28

[Daniel van Vugt (vanvugt)]

Confirmed, on some machines sometimes. I've been thinking bug 2060086 (the graphical renderer crashing) is possibly the cause.

[Launchpad Janitor (janitor)]

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

[Simon Quigley (tsimonq2)]

Could this one be a duplicate of this older bug? https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1838725

Daniel, what are your thoughts on whether it could be the timeout?

[Daniel van Vugt (vanvugt)]

That's been fixed for 4 years already. The timeouts that caused bug 1838725 were due to the kernel graphics driver (i915) taking more than 5 seconds to start. But in Noble we load simpledrm immediately in the first second or two so that *should* never happen.

Of course Plymouth is fussy and will refuse to use simpledrm until the timeout has expired. It should always be able to use simpledrm after that 8 seconds in the worst case.

[Daniel van Vugt (vanvugt)]

> It should always be able to use simpledrm after that 8 seconds in the worst case.

Actually that's not necessarily true. There could be a race if i915 (or whatever) takes close to 8 seconds to load. If Plymouth gives up waiting because that's at the timeout then it will usually try to use simpledrm. But if i915 is also loading at the same time then it may have deleted simpledrm (/dev/dri/card0) and prevent Plymouth from using the graphics device it had chosen.

If we can prove such a race exists then Plymouth could be modified to try /dev/dri/card1 in the case that /dev/dri/card0 has been deleted by the driver of card1.