PSA: 10 second delay before seeing GNOME login screen on boot

Framework Laptop 13 Linux
1

If you are wondering why there seems to be a long 10 second pause during boot, before you see the Gnome Login screen, it is very likely explained by this GDM Bug .

Other references:

When you run systemd-analyze critical-chain graphical.target, you might see that plymouth-quit-wait.service is taking longer than 10 seconds, but I believe this is a symptom of gdm3’s internal 10 second udev timeout.

$ systemd-analyze critical-chain graphical.target 
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

graphical.target @21.738s
└─power-profiles-daemon.service @21.701s +36ms
  └─multi-user.target @21.699s
    └─plymouth-quit-wait.service @9.026s +12.671s
      └─systemd-user-sessions.service @9.013s +8ms
        └─remote-fs.target @9.008s
          └─remote-fs-pre.target @9.008s
            └─rpcbind.service @4.135s +17ms
              └─systemd-tmpfiles-setup.service @4.116s +17ms
                └─local-fs.target @4.102s
                  └─run-docker-netns-09d96da0dff9.mount @10.575s
                    └─local-fs-pre.target @2.197s
                      └─lvm2-monitor.service @1.049s +104ms
                        └─systemd-journald.socket @1.041s +20us
                          └─system.slice @991ms
                            └─-.slice @991ms

Enabling Enable=true in /etc/gdm3/daemon.conf, rebooting and checking sudo journalctl -b -u gdm.service shows the following:

...
Gdm: GdmLocalDisplayFactory: Checking if udev has settled enough to support graphics.
Gdm: GdmLocalDisplayFactory: Found secondary PCI graphics adapter, not proceeding yet
...
Gdm: GdmLocalDisplayFactory: seat0 doesn't yet support graphics.  Waiting 10 seconds to try again.
...

I am running Debian forky (with upstream stable kernel) on my Framework 13 with the AMD Ryzen AI 9 HX 370 + Radeon 890M CPU, but I believe this applies to other distros and similar CPUs.

2

Can you try local-display-factory: look for 'boot_display' sysfs attr (!343) · Merge requests · GNOME / gdm · GitLab

I suspect that helps.

2 Likes
3

Yep, I believe that fixed it. I can comment later on exact results, but I pushed my AI sloppy cherry-pick to GitHub, for now:

$ systemd-analyze critical-chain graphical.target 
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

graphical.target @11.795s
└─power-profiles-daemon.service @11.744s +50ms
  └─multi-user.target @11.742s
    └─plymouth-quit-wait.service @9.398s +2.344s
      └─systemd-user-sessions.service @9.385s +9ms
        └─remote-fs.target @9.378s
          └─remote-fs-pre.target @9.378s

$ sudo journalctl -b -u gdm.service
Mar 25 12:51:13  systemd[1]: Starting gdm.service - GNOME Display Manager...
Mar 25 12:51:13  gdm3[1996]: Gdm: Enabling debugging
Mar 25 12:51:13  gdm3[1996]: Gdm: Changing user:group to Debian-gdm:Debian-gdm
Mar 25 12:51:13  systemd[1]: Started gdm.service - GNOME Display Manager.
Mar 25 12:51:13  gdm3[1996]: Gdm: Successfully connected to D-Bus
Mar 25 12:51:13  gdm3[1996]: Gdm: GdmManager: GDM starting to manage displays
Mar 25 12:51:13  gdm3[1996]: Gdm: GdmLocalDisplayFactory: enumerating seats from logind
Mar 25 12:51:13  gdm3[1996]: Gdm: GdmLocalDisplayFactory: display for seat seat0 requested
Mar 25 12:51:13  gdm3[1996]: Gdm: GdmLocalDisplayFactory: Checking if udev has settled enough to support graphics.
Mar 25 12:51:13  gdm3[1996]: Gdm: GdmLocalDisplayFactory: Found secondary PCI graphics adapter, not proceeding yet.
Mar 25 12:51:13  gdm3[1996]: Gdm: GdmLocalDisplayFactory: Found primary PCI graphics adapter, proceeding.
Mar 25 12:51:13  gdm3[1996]: Gdm: GdmLocalDisplayFactory: udev has settled enough for graphics.
Mar 25 12:51:13  gdm3[1996]: Gdm: GdmLocalDisplayFactory: System supports graphics
Mar 25 12:51:13  gdm3[1996]: Gdm: GdmLocalDisplayFactory: Getting session type (prefers wayland, falling back: no)
Mar 25 12:51:13  gdm3[1996]: Gdm: GdmLocalDisplayFactory: New displays on seat0 will use wayland
Mar 25 12:51:13  gdm3[1996]: Gdm: GdmLocalDisplayFactory: wayland login display for seat seat0 requested
Mar 25 12:51:13  gdm3[1996]: Gdm: GdmLocalDisplayFactory: Adding display on seat seat0
4

I uploaded the debian binaries to Release Debian GDM 49.2-4 with boot_display patch · linux4life798/gdm-debian-boot-display · GitHub if anyone else is in a similar position.

It looks like the upstream fix will be included in GNOME 50, otherwise.

5

Awesome, glad that fixed it.

2 Likes
6

Thanks Mario for the help and the original boot_display sysfs attr fixes!

For others following along, manually installing my custom deb binaries from here will resolve the issue and shouldn’t cause any lasting dpkg harm, since I believe any upstream Debian pkg version bumps should still trigger an upgrade over these packages.

1 Like
7

Looks like the boot_display fix has been included in Debian’s 50.1-2 version and this has successfully superseded my custom patched gdm3. The issue in this thread is no longer an issue for Debian forky.

1 Like