Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 581134

Summary: sys-boot/plymouth does not stop with x11-misc/sddm or kde-plasma/plasma-desktop
Product: Gentoo Linux Reporter: samurai.no.dojo
Component: Current packagesAssignee: Matthew Thode ( prometheanfire ) <prometheanfire>
Status: UNCONFIRMED ---    
Severity: normal CC: bertrand, deim, eva, iordanov, jauhien, lxqt, nrndda
Priority: Normal    
Version: unspecified   
Hardware: AMD64   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Deadline: 2017-09-02   
Attachments: emerge --info

Description samurai.no.dojo 2016-04-25 08:18:44 UTC
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
Comment 1 samurai.no.dojo 2016-04-25 08:22:31 UTC
It happens on 3 independent computers

emerge info in attachment
Comment 2 samurai.no.dojo 2016-04-25 08:23:05 UTC
Created attachment 431902 [details]
emerge --info
Comment 3 Sam Jorna (wraeth) gentoo-dev 2016-04-26 10:38:15 UTC
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.
Comment 4 Johannes Huber (RETIRED) gentoo-dev 2016-04-26 20:25:10 UTC
Which Qt version are you using?
Comment 5 samurai.no.dojo 2016-04-27 09:53:10 UTC
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
Comment 6 samurai.no.dojo 2016-04-27 09:53:54 UTC
(In reply to samurai.no.dojo from comment #5)
using lightdm
Comment 7 samurai.no.dojo 2016-11-13 13:46:55 UTC
I gave up on this and removed plymouth...
Comment 8 Andreas Sturmlechner gentoo-dev 2017-06-25 09:15:39 UTC
There is nothing we can do here, maybe this package should be treecleaned.
Comment 9 Manuel Rüger (RETIRED) gentoo-dev 2017-06-25 10:15:33 UTC
(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 )
Comment 10 Pacho Ramos gentoo-dev 2017-07-03 09:32:17 UTC
Yes, this needs a dedicated maintainer for sure
Comment 11 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2017-08-03 20:11:58 UTC
# 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
Comment 12 Gilles Dartiguelongue (RETIRED) gentoo-dev 2017-08-09 07:14:07 UTC
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
Comment 13 deim 2019-12-04 21:39:08 UTC
I managed to create script in /etc/local.d/ folder that kills plymouth process. Seem works quite well.
Comment 14 Dmitry Derevyanko 2020-04-25 15:16:19 UTC
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.
Comment 15 Dmitry Derevyanko 2020-04-27 19:39:10 UTC
"Conflicts=display-manager.service" is not working. Also saw that some time after "systemctl start plymouth-quit" plymouth starts again.
Comment 16 Dmitry Derevyanko 2020-04-29 01:03:19 UTC
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.
Comment 17 Steve Arnold archtester gentoo-dev 2020-12-23 18:31:53 UTC
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?
Comment 18 Steve Arnold archtester gentoo-dev 2020-12-23 18:35:58 UTC
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.