Bugzilla – Bug 1148242
display manager fails to load when plymouth is uninstalled
Last modified: 2020-12-27 14:23:30 UTC
Created attachment 815770 [details] relevant journalctl info Since upgrading to 20190824, lightdm fails to load every other time. I'll reboot and it will work.
> display-manager.service: Failed to enqueue OnFailure= job, ignoring: Unit plymouth-quit.service not found. Just FYI, plymouth is uninstalled on this system.
The system seems to be failing to load any display manager at random. lightdm, xdm, or gdm. Apparently, I'm the only one suffering from this major regression. >_<
Created attachment 816484 [details] full boot log for lighdm
Created attachment 816485 [details] warning filter for lightdm
Created attachment 816486 [details] full boot log for gdm
Created attachment 816487 [details] warning filter for gdm
I can log in as root and then do telinit 3 -> telinit 5 and the display manager will load.
Possibly related https://bugzilla.suse.com/show_bug.cgi?id=1137433 although, this start much more recently for me.
I noticed that he also had "Failed to enqueue OnFailure= job, ignoring: Unit plymouth-quit.service not found." So I decided to reinstall plymouth, removed "plymouth.enable=0", and added back "splash=silent" and "quiet" to the kernel parameters. The first two boots have successfully loaded the display manager. I'll report back, if it fails, or in a few days otherwise.
No failures so far. I'm thinking maybe the problem was I forgot to run mkinitrd or dracut after uninstalling plymouth via zypper. I'm not sure why that causes random failures, but that's my best guess.
Booting with "quiet splash=silent" removed and "plymouth.enable=0" has also been working with no problem. What is the correct way to uninstall plymouth via zypper? "zypper rm plymouth" wants to uninstall 2 packages. "zypper rm -u plymouth*" wants to uninstall 14. Is "dracut --force" equivalent to "mkinitrd" and do I need to run one of these after uninstalling?
I did ``` zypper rm -u plymouth* dracut --force ``` and the problem reappeared on reboot. So some pseudo-dependency on plymouth has been created. I reinstalled and it booted fine.
I decided to try a less aggressive uninstall and used YaST2. It uninstalled plymouth and plymouth-dracut. The first two boots have loaded lightdm. I get the following from journald: Sep 03 20:51:28 systemd[1]: Starting Show Plymouth Boot Screen... Sep 03 20:51:28 systemd[1]: Received SIGRTMIN+20 from PID 341 (plymouthd). Sep 03 20:51:28 systemd[1]: Started Show Plymouth Boot Screen. Sep 03 20:51:28 systemd[1]: Started Forward Password Requests to Plymouth Directory Watch. Sep 03 20:51:29 systemd[1]: Starting Plymouth switch root service... Sep 03 20:51:29 systemd[1]: plymouth-switch-root.service: Succeeded. Sep 03 20:51:29 systemd[1]: Started Plymouth switch root service. The system sure does (or tries to do) a lot with something that is supposed to be uninstalled.
Created attachment 816735 [details] coredump I just looked at journald for the failure (from comment 12) and it actually didn't say "Starting service lightdm...failed", but it did produce a coredump (attached).
So following from my YaST uninstall of the two packages, I looked at the output of "lsinitrd" and found a lot of plymouth stuff still in there. I guess that's why the boot loaded lightdm without a problem. I then ran `dracut --force --omit "plymouth"`, which effectively cleaned the initramfs of all mention of plymouth. I rebooted and lightdm failed to load. So it seems like some aspect of plymouth needs to be in the initramfs -- otherwise this problem manifests. I've noticed "plymouth-quit.service" is mentioned in "display-manager.service" under "After=", "Conflicts=" and "OnFailure=" (hence the journal message). I reinstalled plymouth and lightdm loaded fine. No surprise at this point. I'm just going to leave plymouth installed and use "plymouth.enable=0", which worked fine for several days; although, I won't consider this resolved until we understand why plymouth as become a pseudo-dependecy.
I noticed that the coredump mentioned modesetting, nouveau and glamor, so I thought maybe reinstalling xf86-video-nouveau could help. No problems so far. I wonder if it's related to the update to xorg-x11-server 1.20.5 https://build.opensuse.org/request/show/706740
Ok, so I went further and did a "zypper rm -u plymouth*" and "dracut --force" to ensure no trace was left behind, and continued to have no problems. Just now I uninstalled xf86-video-nouveau (followed by "dracut --force") and had the coredump (already posted) on first reboot. So in summary, if plymouth is uninstalled, and xf86-video-modesetting is used with a NVIDIA GTX 750, then the display manager will usually fail to load.
For reference, this is everything removed by "zypper rm -u plymouth*" > gnu-unifont-bitmap-fonts libply-boot-client4 libply-splash-core4 > libply-splash-graphics4 libply4 plymouth plymouth-branding-openSUSE > plymouth-dracut plymouth-plugin-label plymouth-plugin-label-ft > plymouth-plugin-two-step plymouth-scripts plymouth-theme-bgrt > plymouth-theme-spinner
And now I just thought about > zypper rm -u xf86-video-nouveau > The following 3 packages are going to be REMOVED: > Mesa-dri-nouveau libvdpau_nouveau xf86-video-nouveau It looks like Mesa-dri-nouveau provides nouveau_dri.so, which is mentioned in the coredump.
I didn't get the coredump, but the display manager still failed to load (logs are the same as the original attachments). Oh well.
Sigh. I just had the coredump with xf86-video-nouveau installed! Now I'm thinking maybe I'm dealing with two different issues. One that's indicated with the coredump, and the other indicated by "Starting service lightdm..failed". I haven't had the latter while xf86-video-nouveau is installed (but to be clear, lightdm still fails to load with the coredump). Interestingly, with this latest problem the screen never showed anything -- not even the UEFI splash or grub2. I eventually woke it up with CTRL+ALT+F1, and found something new (after the coredump): > kernel: nouveau 0000:01:00.0: DRM: DDC responded, but no EDID for HDMI-A-1 I've enabled my intel graphics chip, and will try using it for a while, since Thomas Hänig is not having any problems with that. https://bugzilla.suse.com/show_bug.cgi?id=1137433
No problems so far using the Intel HD Graphics 4600 via the motherboard's VGA connector and xf86-video-modesetting.
Created attachment 817485 [details] using systemd.log_level=debug I switched back to the NVIDIA card using HDMI and xf86-video-modesetting, and instantly got the (non-coredump) problem. I used the kernel parameters > "systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M printk.devkmsg=on" but didn't get too much more in terms of helpful information. I guess it at least confirms that "/usr/lib/X11/display-manager start" is what fails. > systemd[1]: display-manager.service: About to execute: /usr/lib/X11/display-manager start > systemd[1]: display-manager.service: Forked /usr/lib/X11/display-manager as 1190 > ... > systemd[1]: Child 1190 (display-manager) died (code=exited, status=1/FAILURE) Since the problem is apparently related to the use of an NVIDIA card, I wonder if these two faults could be related. > kernel: nouveau 0000:01:00.0: bus: MMIO read of 00000000 FAULT at 3e6684 [ IBUS ] > kernel: nouveau 0000:01:00.0: bus: MMIO read of 00000000 FAULT at 10ac08 [ IBUS ] Some searching showed that other people have those faults, but I haven't learned much yet.