Bug 1148242 - display manager fails to load when plymouth is uninstalled
display manager fails to load when plymouth is uninstalled
Status: NEW
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Basesystem
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: Alexei Sorokin
E-mail List
Depends on:
  Show dependency treegraph
Reported: 2019-08-27 01:56 UTC by ravas mi
Modified: 2020-12-27 14:23 UTC (History)
1 user (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---

relevant journalctl info (1.04 KB, text/plain)
2019-08-27 01:56 UTC, ravas mi
full boot log for lighdm (112.18 KB, text/plain)
2019-08-30 22:09 UTC, ravas mi
warning filter for lightdm (3.99 KB, text/plain)
2019-08-30 22:09 UTC, ravas mi
full boot log for gdm (362.01 KB, text/plain)
2019-08-30 22:10 UTC, ravas mi
warning filter for gdm (203.68 KB, text/plain)
2019-08-30 22:10 UTC, ravas mi
coredump (7.76 KB, text/plain)
2019-09-04 04:15 UTC, ravas mi
using systemd.log_level=debug (6.47 KB, text/plain)
2019-09-10 06:14 UTC, ravas mi

Note You need to log in before you can comment on or make changes to this bug.
Description ravas mi 2019-08-27 01:56:56 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.
Comment 1 ravas mi 2019-08-27 02:30:26 UTC
> display-manager.service: Failed to enqueue OnFailure= job, ignoring: Unit plymouth-quit.service not found.

Just FYI, plymouth is uninstalled on this system.
Comment 2 ravas mi 2019-08-30 22:06:21 UTC
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. >_<
Comment 3 ravas mi 2019-08-30 22:09:19 UTC
Created attachment 816484 [details]
full boot log for lighdm
Comment 4 ravas mi 2019-08-30 22:09:58 UTC
Created attachment 816485 [details]
warning filter for lightdm
Comment 5 ravas mi 2019-08-30 22:10:29 UTC
Created attachment 816486 [details]
full boot log for gdm
Comment 6 ravas mi 2019-08-30 22:10:53 UTC
Created attachment 816487 [details]
warning filter for gdm
Comment 7 ravas mi 2019-08-30 22:18:04 UTC
I can log in as root and then do telinit 3 -> telinit 5 and the display manager will load.
Comment 8 ravas mi 2019-08-30 22:33:47 UTC
Possibly related https://bugzilla.suse.com/show_bug.cgi?id=1137433
although, this start much more recently for me.
Comment 9 ravas mi 2019-08-30 22:52:46 UTC
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.
Comment 10 ravas mi 2019-09-01 20:22:07 UTC
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.
Comment 11 ravas mi 2019-09-03 00:08:55 UTC
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?
Comment 12 ravas mi 2019-09-04 03:14:37 UTC
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.
Comment 13 ravas mi 2019-09-04 04:01:15 UTC
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.
Comment 14 ravas mi 2019-09-04 04:15:48 UTC
Created attachment 816735 [details]

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).
Comment 15 ravas mi 2019-09-04 05:37:44 UTC
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.
Comment 16 ravas mi 2019-09-04 18:21:32 UTC
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
Comment 17 ravas mi 2019-09-05 20:53:31 UTC
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.
Comment 18 ravas mi 2019-09-05 21:17:24 UTC
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
Comment 19 ravas mi 2019-09-05 21:29:50 UTC
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.
Comment 20 ravas mi 2019-09-05 21:40:19 UTC
I didn't get the coredump, but the display manager still failed to load (logs are the same as the original attachments). Oh well.
Comment 21 ravas mi 2019-09-06 20:06:42 UTC
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.
Comment 22 ravas mi 2019-09-09 05:03:02 UTC
No problems so far using the Intel HD Graphics 4600 via the motherboard's VGA connector and xf86-video-modesetting.
Comment 23 ravas mi 2019-09-10 06:14:01 UTC
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.