GNOME Bugzilla – Bug 795477
Plymouth/gdm hangs without connected monitor
Last modified: 2018-05-24 11:49:51 UTC
This issue is caught by SUSE automation QA framework. When no monitor is attached, booting up graphic.target is stalled forever waiting plymouth to quit. Listing systemd jobs from ssh showing the following statuses: linux-w63p:~ # systemctl list-jobs JOB UNIT TYPE STATE 217 getty.target start waiting 113 multi-user.target start waiting 218 serial-getty@ttyS0.service start waiting 213 systemd-update-utmp-runlevel.service start waiting 262 after-local.service start waiting 223 getty@tty1.service start waiting 248 plymouth-quit-wait.service start running 112 graphical.target start waiting 8 jobs listed. The same issue can also be reproduced in a QEMU vm by simulating the virtual monitor detached by adding following option to the kernel command line in bootloader: video=Virtual-1:d
Debugging in this scenario shows gdm marks the display as "managed". Plymouth won't quit until the session client is connected, which unfortunately never happens. It looks we should either let gdm_local_display_prepare() mark the display as failed / unmanaged to trigger plymouth to quit, or just alway quit plymouth when a display is manage, which means reverting commit 2cbd7ad (preferredly after a timeout to get around bug 746498). I'd opt to the latter approach as by keeping the managed status, we somehow regains a working greeter screen when a monitor is re-connected.
Created attachment 371257 [details] [review] A proposed patch.
Sorry, the patch is found causing logins within the timeout to fail. Looks we'll need a different fix.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gdm/issues/375.