Plymouth doesn't work consistently.

[leyvi]

plymouth doesn't always work. I tried running it with the debugging arguments but it still didn't log anything. It never works on boot. I am using ugRD (I have the ugrd.base.plymouth module enabled) and have a custom kernel, maybe the problem is in my kernel?

[zen_desu]

plymouth doesn't always work. I tried running it with the debugging arguments but it still didn't log anything. It never works on boot. I am using ugRD (I have the ugrd.base.plymouth module enabled) and have a custom kernel, maybe the problem is in my kernel?

tell me about it, I spent about 20 hours last weekend trying to get it to work.

gentoo uses plymouth from 2022 as the stable package and regardless of the version I've tried, or USE flags, I can't get it to consistently work with or without GPU drivers. I can't do a whole lot about it because the plymouth debug logging seems entirely broken.

I think plymouth may be hardcoded to look for "/dev/fb0" which is not enabled on dist-kernel (requires CONFIG_FB_DEVICE), but even with this present it seems to make plymouth break more? I mean enabling that started making it consistetly show keystrokes for the password entries where it should mask that. I'm not sure what it's doing with dracut but I think even without the udev USE flag, plymouth will still stall waiting for devices to become "present" even if they are already there.

Someone off the forums has been looking into this a lot and it seems that using "simpledrm" may be more reliable than efifb/DRM (the drm backend for plymouth doesn't seem to work without udev)

this is the update branch I'm working on. Plymouth doesn't seem to work correctly with/without GPU drivers, if GPU drivers are fully loaded/initialized before or after plymouth is started, and so on: https://github.com/desultory/ugrd/compa ... ..plymouth

I'm mostly testing on a laptop with an AMD GPU, not sure how much this is tied to a specific GPU. If you disable GPU drivers entirely and set the plymouth device timeout to 0.1, it should at least give you the grey screen immediately, but testing this I noticed that about half of the time it would still show key presses when this happens? sometimes it just works. I can't figure it out, it seems non-deterministic (and plymouth refuses to make any logs)

[leyvi]

There's gotta be a race condition somewhere.
It could be in Plymouth, but I'm guessing it has to do with the kernel somehow. Obviously I don't think there's a race condition in the kernel itself, but I think there might be a race condition in some of the driver initialization or something like that.

[zen_desu]

There's gotta be a race condition somewhere.
It could be in Plymouth, but I'm guessing it has to do with the kernel somehow. Obviously I don't think there's a race condition in the kernel itself, but I think there might be a race condition in some of the driver initialization or something like that.

I think it may just be that plymouth isn't "aware" of any gpu backend unless udev tells it where it is. You can kinda force this using udev stuff, but I'm afraid doing this partially could setup the GPU in a way where if udev is used later by the system, it may not do additional setup/enumeration for other things.

I'm really making guesses here because even with the --debug-log option and --debug option, plymouthd seems to refuse to write logs anywhere.

[rab0171610]

In my personal experience, modern systems boot so quickly that there is no longer a need for plymouth . . .

I keep a debian system on a second drive as a backup OS, just in case of emergencies. I uninstall plymouth there as I find it unnecessary. My system takes seconds to boot so it seems silly to work so hard on getting something to work and running an extra service (plymouth) just to display an image for a second or two. I use grub and Nvidia drivers and SDDM. There is always going to be a flash of a blackscreen once or twice at some point in the transition between those three elements loading and unloading regardless of what distro I am booting, including live OS disks. So in that case, plymouth does not really work as intended if there are going to be a few flashes of blank screen during the boot process.

I may be going out on a limb here in suggesting that you consider that maybe you don't really need plymouth since in modern systems it is generally unnecessary and doesn't always perform that well. Plymouth grew in a time when systems were slower to boot and distros were looking for a way to hide boot messages and continue the distro's theming between grub and the login screen. That time has been reduced from over a minute in some cases to a mere second or two in some scenarios since that time. The need just is not there anymore.

[leyvi]

In my personal experience, modern systems boot so quickly that there is no longer a need for plymouth . . .

I keep a debian system on a second drive as a backup OS, just in case of emergencies. I uninstall plymouth there as I find it unnecessary. My system takes seconds to boot so it seems silly to work so hard on getting something to work and running an extra service (plymouth) just to display an image for a second or two. I use grub and Nvidia drivers and SDDM. There is always going to be a flash of a blackscreen once or twice at some point in the transition between those three elements loading and unloading regardless of what distro I am booting, including live OS disks. So in that case, plymouth does not really work as intended if there are going to be a few flashes of blank screen during the boot process.

I may be going out on a limb here in suggesting that you consider that maybe you don't really need plymouth since in modern systems it is generally unnecessary and doesn't always perform that well. Plymouth grew in a time when systems were slower to boot and distros were looking for a way to hide boot messages and continue the distro's theming between grub and the login screen. That time has been reduced from over a minute in some cases to a mere second or two in some scenarios since that time. The need just is not there anymore.

I agree that it is no longer needed. However, many people like the look and feel of having a boot splash. Some people don't like looking at terminals until they're ready to open one.

[zen_desu]

In my personal experience, modern systems boot so quickly that there is no longer a need for plymouth . . .

I keep a debian system on a second drive as a backup OS, just in case of emergencies. I uninstall plymouth there as I find it unnecessary. My system takes seconds to boot so it seems silly to work so hard on getting something to work and running an extra service (plymouth) just to display an image for a second or two. I use grub and Nvidia drivers and SDDM. There is always going to be a flash of a blackscreen once or twice at some point in the transition between those three elements loading and unloading regardless of what distro I am booting, including live OS disks. So in that case, plymouth does not really work as intended if there are going to be a few flashes of blank screen during the boot process.

I may be going out on a limb here in suggesting that you consider that maybe you don't really need plymouth since in modern systems it is generally unnecessary and doesn't always perform that well. Plymouth grew in a time when systems were slower to boot and distros were looking for a way to hide boot messages and continue the distro's theming between grub and the login screen. That time has been reduced from over a minute in some cases to a mere second or two in some scenarios since that time. The need just is not there anymore.

I agree that it is no longer needed. However, many people like the look and feel of having a boot splash. Some people don't like looking at terminals until they're ready to open one.

Yeah, personally I don't find plymouth to be worth the effort. It can look kinda nice, but if you simply set the "quiet" kernel command line parameter, things are clean enough for me.

The bit I really don't like about using plymouth is that it can make any sort of boot debugging much harder because it only shows one log item at a time (and is limited to 255 chars per message).
It also slows down the boot process measurably. Takes about 2-3 extra seconds on my 7840u system which more or less doubles the time spent in the initramfs.
GPU drivers in the initramfs (which seem required for full plymouth theme support) also double or triple the size of the initramfs which means it takes even longer for the kernel to open/decompress.

The real painful bit is that I've spent well over 50 hours in total trying to debug it, and didn't really get anywhere. A lot of the plymouth tooling seems _specifically_ designed for use with dracut. The scripts it includes in /usr/libexec/plymouth seem to mostly be ripped from dracut and compatible with it. I'm not sure if using plymouth without udev is a real option, especially given I can't build the 9999 version without udev.

[rab0171610]

I agree that it is no longer needed. However, many people like the look and feel of having a boot splash. Some people don't like looking at terminals until they're ready to open one.

For those using grub, there is a way to hide the boot messages and display the motherboard logo until login screen appears. I edit /etc/default/grub :

Code: Select all

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX="console=tty12"

That works in the Debian system. I have to redirect the console output there as quiet and splash do not work as expected. Boot messages are always shown regardless.
In Gentoo:

Code: Select all

 GRUB_CMDLINE_LINUX_DEFAULT="quiet loglevel=0"

Is enough to hide boot console messages and display the motherboard logo for the 1 or 2 seconds it takes until the SDDM login screen appears. The results might vary depending on the motherboard of course. In some cases, depending on the grub configuration, the grub background splash image may continue to appear for several seconds until the login screen.
In some distros and depending on the graphics driver configuration, there may still be a quick flash of a blank screen during the transition to the login screen.
https://askubuntu.com/questions/248/how ... ntu-starts