Plymouth boot screen stays up even after finished boot up. This prevents sddm from starting on VT1. It started after upgrade to plasma (kde5). I had lightdm before -> no problems with that. Reproducible: Always Steps to Reproduce: 1. switch from kde4 to plasma 2. reboot -> failure that screen on VT1 does not have right properties (in Xorg.log) 3.change /etc/sddm.conf to start on vt7 -> success (login screen and all that stuff works) 4. but on VT1 is still plymouth boot screen and it eats up to on CPU core 5. only way to stop it is either to disable plmouth or to stop it by hand (systemctl start plmouth-quit) Actual Results: all is in Steps to reproduce Expected Results: login screen in VT1 and plymouth off. dmesg output showing taht plymouth-quit is being deleted: [ 77.544595] systemd[1]: multi-user.target: Found ordering cycle on multi-user.target/start [ 77.544598] systemd[1]: multi-user.target: Found dependency on plymouth-quit.service/start [ 77.544601] systemd[1]: multi-user.target: Found dependency on rc-local.service/start [ 77.544604] systemd[1]: multi-user.target: Found dependency on multi-user.target/start [ 77.544607] systemd[1]: multi-user.target: Breaking ordering cycle by deleting job plymouth-quit.service/start [ 77.544610] systemd[1]: plymouth-quit.service: Job plymouth-quit.service/start deleted to break ordering cycle starting with multi-user.target/start [ 77.544655] systemd[1]: multi-user.target: Found ordering cycle on multi-user.target/start [ 77.544658] systemd[1]: multi-user.target: Found dependency on plymouth-quit-wait.service/start [ 77.544661] systemd[1]: multi-user.target: Found dependency on rc-local.service/start [ 77.544664] systemd[1]: multi-user.target: Found dependency on multi-user.target/start [ 77.544666] systemd[1]: multi-user.target: Breaking ordering cycle by deleting job plymouth-quit-wait.service/start [ 77.544670] systemd[1]: plymouth-quit-wait.service: Job plymouth-quit-wait.service/start deleted to break ordering cycle starting with multi-user.target/start
It happens on 3 independent computers emerge info in attachment
Created attachment 431902 [details] emerge --info
commit 7f805bae938b58b86f697da02258e2ebe0372981 Author: Sam Jorna <wraeth@gentoo.org> Date: Tue Apr 26 20:21:36 2016 +1000 sys-boot/plymouth: remove proxy maintainer Proxy maintainer has requested to drop the package per mail to the project. Removing both maintainer and project from metadata.xml.
Which Qt version are you using?
dev-qt/qtgui (4) 4.8.6-r4 (5) 5.5.1-r1 dev-qt/qtcore (4) 4.8.6-r2 (5) 5.5.1-r1 And I have seen same behaviour even on system running KDE4
(In reply to samurai.no.dojo from comment #5) using lightdm
I gave up on this and removed plymouth...
There is nothing we can do here, maybe this package should be treecleaned.
(In reply to Andreas Sturmlechner from comment #8) > There is nothing we can do here, maybe this package should be treecleaned. Dependencies in tree: gnome-base/gdm-3.22.3-r1: plymouth? ( sys-boot/plymouth ) kde-plasma/breeze-plymouth-5.8.6:RDEPEND="sys-boot/plymouth" kde-plasma/breeze-plymouth-5.8.7:RDEPEND="sys-boot/plymouth" kde-plasma/breeze-plymouth-5.9.5:RDEPEND="sys-boot/plymouth" sys-boot/plymouth-openrc-plugin-0.1.2: >=sys-boot/plymouth-0.8.3-r5 sys-kernel/dracut-044-r1: optfeature "Plymouth boot splash" '>=sys-boot/plymouth-0.8.5-r5' sys-kernel/dracut-044-r3: optfeature "Plymouth boot splash" '>=sys-boot/plymouth-0.8.5-r5' sys-kernel/genkernel-next-64: plymouth? ( sys-boot/plymouth ) sys-kernel/genkernel-next-65: plymouth? ( sys-boot/plymouth ) sys-kernel/genkernel-next-66: plymouth? ( sys-boot/plymouth )
Yes, this needs a dedicated maintainer for sure
# Michał Górny <mgorny@gentoo.org> (04 Aug 2017) # sys-boot/plymouth is unmaintained since Apr 2016. The current version # has multiple bugs, including not supporting OpenRC. It really needs # an active maintainer. Removal in 30 days. Bug #621470. # # The remaining packages are sys-boot/plymouth reverse dependencies. # They have no use without it, so they are being removed as well. kde-plasma/breeze-plymouth kde-plasma/plymouth-kcm sys-boot/plymouth sys-boot/plymouth-openrc-plugin
If using systemd, make sure to copy service dependencies from gdm unit: # replaces the getty Conflicts=getty@tty1.service After=getty@tty1.service # replaces plymouth-quit since it quits plymouth on its own Conflicts=plymouth-quit.service After=plymouth-quit.service # Needs all the dependencies of the services it's replacing # pulled from getty@.service and plymouth-quit.service # (except for plymouth-quit-wait.service since it waits until # plymouth is quit, which we do) After=rc-local.service plymouth-start.service systemd-user-sessions.service # GDM takes responsibility for stopping plymouth, so if it fails # for any reason, make sure plymouth still stops OnFailure=plymouth-quit.service
I managed to create script in /etc/local.d/ folder that kills plymouth process. Seem works quite well.
Installed plymouth and also saw same behaviour. Plymouth stops but then something triggers its restart: Apr 25 15:36:45 systemd[1]: Received SIGRTMIN+21 from PID 362 (plymouthd). Apr 25 15:36:45 systemd[1]: Received SIGRTMIN+21 from PID 362 (plymouthd). Apr 25 15:36:45 systemd[1]: plymouth-quit.service: Succeeded. Apr 25 15:36:45 systemd[1]: Finished Terminate Plymouth Boot Screen. Apr 25 15:36:45 systemd[1]: plymouth-quit-wait.service: Succeeded. Apr 25 15:36:45 systemd[1]: Finished Hold until boot process finishes up. Apr 25 15:36:45 systemd[1]: plymouth-read-write.service: Succeeded. Apr 25 15:36:45 systemd[1]: Finished Tell Plymouth To Write Out Runtime Data. Apr 25 15:36:45 systemd[1]: Started Simple Desktop Display Manager. Apr 25 15:36:45 systemd[1]: plymouth-start.service: Succeeded. Apr 25 15:36:45 systemd[1]: plymouth-start.service: Consumed 9.642s CPU time. Apr 25 15:36:45 sddm[993]: Initializing... Apr 25 15:36:45 sddm[993]: Starting... Apr 25 15:36:45 sddm[993]: Logind interface found Apr 25 15:36:45 sddm[993]: Adding new display on vt 1 ... Apr 25 15:36:45 sddm[993]: Loading theme configuration from "" Apr 25 15:36:45 sddm[993]: Display server starting... Apr 25 15:36:45 sddm[993]: Running: /usr/bin/X -nolisten tcp -auth /var/run/sddm/{cc296ac8-f3b1-45ca-a2b5-30a1616c74ae} -background none -noreset -displayfd 17 -seat seat0 vt1 Apr 25 15:36:46 systemd[1]: plymouth-read-write.service: Start request repeated too quickly. Apr 25 15:36:46 systemd[1]: plymouth-read-write.service: Failed with result 'start-limit-hit'. Apr 25 15:36:46 systemd[1]: Failed to start Tell Plymouth To Write Out Runtime Data. Apr 25 15:36:46 systemd[1]: Starting Show Plymouth Boot Screen... Apr 25 15:36:46 systemd[1]: Received SIGRTMIN+20 from PID 1009 (plymouthd). Apr 25 15:36:46 systemd[1]: Started Show Plymouth Boot Screen. Possible warkaround plymouth-start.service with Conflicts=display-manager.service. Not tested yet. Better would be to find out what triggers start of plymouth.
"Conflicts=display-manager.service" is not working. Also saw that some time after "systemctl start plymouth-quit" plymouth starts again.
Found this: https://github.com/systemd/systemd/issues/15091 Also here: https://bugzilla.redhat.com/show_bug.cgi?id=1807771 Upstream fix in plymouth-start.service: https://gitlab.freedesktop.org/plymouth/plymouth/-/merge_requests/99 cat /etc/systemd/system/plymouth-start.service.d/override.conf > [Service] > RemainAfterExit=yes Works.
Seeing the same issue with encrypted rootfs and openrc, ie, plymouthd comes back after login and starts spiking the cpu (if left alone it just gets worse). After reading the comments here I noticed that sys-boot/plymouth-openrc-plugin was *not* installed. So I installed it and killed plymouthd so I guess I'll see what happens on the next reboot. Seems like a working bootsplash with support for encrypted rootfs passphrase is still kinda important?
Note that in my case this was originally a gnome/gdm/wayland desktop but gdm has some weird behavior after bootup (login freeze and back to login again) so currently using sddm/xfce desktop.