boots too fast for Xorg to run???

# inxi -SGy
System:
  Host: ab250 Kernel: 5.12.9-1-default x86_64 bits: 64
  Desktop: Trinity R14.0.10 Distro: openSUSE **Tumbleweed 20210611**
Graphics:
  Device-1: Intel HD Graphics 630 driver: i915 v: kernel
  Display: x11 server: X.Org 1.20.11 driver: loaded: modesetting
  unloaded: fbdev,vesa resolution: 1920x1200~60Hz
  OpenGL: renderer: Mesa DRI Intel HD Graphics 630 (KBL GT2)
  v: 4.6 Mesa 21.1.2
# systemd-analyze critical-chain
...
multi-user.target @3.175s
└─kbdsettings.service @1.018s +2.155s
  └─basic.target @1.008s
    └─sockets.target @1.008s
      └─telnet.socket @1.007s
        └─sysinit.target @999ms
          └─systemd-timesyncd.service @936ms +62ms
            └─systemd-tmpfiles-setup.service @906ms +26ms
              └─systemd-journal-flush.service @374ms +531ms
                └─systemd-journald.service @324ms +47ms
                  └─systemd-journald.socket
                    └─-.mount
                      └─system.slice
                        └─-.slice
# systemd-analyze blame | head -n22
2.155s kbdsettings.service
 531ms systemd-journal-flush.service
 508ms initrd-switch-root.service
 492ms dracut-initqueue.service
 276ms systemd-networkd.service
 192ms initrd-parse-etc.service
 187ms systemd-udevd.service
 139ms systemd-fsck@dev-disk-by\x2dlabel-zm2p05home.service
 135ms systemd-fsck@dev-disk-by\x2dlabel-zm2p06pub.service
 135ms systemd-fsck@dev-disk-by\x2dlabel-zm2p04usrlcl.service
 112ms user@0.service
  95ms systemd-udev-trigger.service
  90ms issue-generator.service
  88ms smb.service
  87ms sshd.service
  81ms display-manager.service
  77ms systemd-logind.service
  74ms nmb.service
  73ms avahi-daemon.service
  62ms systemd-timesyncd.service
  58ms systemd-vconsole-setup.service
  58ms modprobe@drm.service
# lsmod | grep i915
i915                 2777088  4
drm_kms_helper        286720  1 i915
cec                    61440  2 drm_kms_helper,i915
i2c_algo_bit           16384  1 i915
drm                   573440  4 drm_kms_helper,i915
video                  53248  2 asus_wmi,i915

The following

(EE) open /dev/dri/card0: No such file or directory

happens only on first XDM/TDM start, resulting in black screen on tty7 if booting 5.11.16 kernel. With 5.12.9, the error is the same, but there’s no attempt to switch from tty1 to tty7. After logging in

systemctl restart xdm

starts Xorg up normally.

If I boot to multi-user instead of graphical, the output from lsmod is the same as shown above, and startx works on first try.

Another thing happening is tty1 clears, but only after a delay of a second or two or three displaying what it should as a result of:

/etc/systemd/system/getty.target.wants # grep Start getty@tty1.service
ExecStart=-/sbin/agetty -o '-p -- \\u' --noclear %I $TERM

This statement has been working for years to prevent screen clearing on tty1.

Where should I be looking for what prevents /dev/dri/card0 from existing before X tries to start?

Last 3 Xorg.0.logs in order of boot/creation:

  1. https://susepaste.org/view/raw/50696213
  2. https://susepaste.org/view/raw/3306118
    *]https://susepaste.org/view/raw/89126860
**3400G:~ #** **journalctl -b -u getty@tty1.service -o short-monotonic**  
-- Logs begin at Fri 2021-06-04 21:19:38 CEST, end at Sun 2021-06-13 11:13:04 CEST. -- 
    6.295314] 3400G systemd[1]: Started Getty on tty1. 
**3400G:~ #**
**3400G:~ #** **journalctl -b -u display-manager.service -o short-monotonic -p6** 
-- Logs begin at Fri 2021-06-04 21:19:38 CEST, end at Sun 2021-06-13 11:13:04 CEST. -- 
    6.150058] 3400G systemd[1]: Starting X Display Manager... 
    6.159453] 3400G display-manager[971]: /etc/vconsole.conf available 
    6.159752] 3400G display-manager[971]: KEYMAP: de-latin1-nodeadkeys 
    6.159752] 3400G display-manager[971]: Command: localectl set-keymap de-latin1-nodeadkeys 
    6.163003] 3400G display-manager[971]: I: Using systemd /usr/share/systemd/kbd-model-map mapping 
    6.804447] 3400G systemd[1]: Started X Display Manager. 
    7.463964] 3400G sddm-helper[1027]: pam_unix(sddm-greeter:session): session opened for user sddm(uid=477) by (uid=0) 
   14.257911] 3400G sddm-helper[1147]: pam_unix(sddm:session): session opened for user karl(uid=1000) by (uid=0) 
   14.258249] 3400G sddm-helper[1147]: Starting: "/usr/etc/X11/xdm/Xsession \"/usr/bin/startplasma-x11\"" 
 6941.948625] 3400G sddm-helper[2248]: pam_unix(sddm-greeter:session): session opened for user sddm(uid=477) by (uid=0) 
 6949.157952] 3400G sddm-helper[2311]: pam_unix(sddm:session): session opened for user karl(uid=1000) by (uid=0) 
 6949.158694] 3400G sddm-helper[2311]: Starting: "/usr/etc/X11/xdm/Xsession \"/usr/bin/startplasma-x11\"" 
**3400G:~ #**

Because this is repeatable on at least three different TW installations here, I created a bug about this 12 days ago. As yet, it has produced no fruit.

# inxi -S
System:    Host: ab250 Kernel: 5.13.8-1-default x86_64 bits: 64 Console: tty pts/0 Distro: openSUSE Tumbleweed 20210810
# journalctl -b -u getty@tty1.service -o short-monotonic
-- Journal begins at Fri 2021-04-09 20:59:51 EDT, ends at Thu 2021-08-12 22:21:59 EDT. --
    3.723341] ab250 systemd[1]: Started Getty on tty1.
# journalctl -b -u display-manager.service -o short-monotonic -p6
-- Journal begins at Fri 2021-04-09 20:59:51 EDT, ends at Thu 2021-08-12 22:21:59 EDT. --
    3.721573] ab250 systemd[1]: Starting X Display Manager...
    3.781373] ab250 display-manager[622]: /etc/vconsole.conf available
    3.782194] ab250 display-manager[622]: KEYMAP: us
    3.782624] ab250 display-manager[622]: Command: localectl set-keymap us
    3.880659] ab250 display-manager[622]: I: Using systemd /usr/share/systemd/kbd-model-map mapping
    4.074144] ab250 display-manager[613]: Starting service tdm
    4.075872] ab250 systemd[1]: Started X Display Manager.
# systemd-analyze
Startup finished in 16.459s (firmware) + 2.013s (loader) + 1.217s (kernel) + 1.341s (initrd) + 3.143s (userspace) = 24.174s
graphical.target reached after 3.126s in userspace
# grep \(EE /var/log/Xorg.0.log
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
     4.139] (EE) Failed to load module "intel" (module does not exist, 0)
     4.141] (EE) open /dev/dri/card0: No such file or directory
     4.141] (EE) open /dev/dri/card0: No such file or directory
     4.141] (EE) Unable to find a valid framebuffer device
     4.142] (EE) open /dev/fb0: No such file or directory
     4.142] (EE) Screen 0 deleted because of no matching config section.
     4.142] (EE) Screen 0 deleted because of no matching config section.
     4.142] (EE) Device(s) detected, but none match those in the config file.
...

As noted in the bug, it seems xdm most times wants to start before the relevant KMS module gets loaded.

Because it is repeatable doesn’t mean it’s a bug. Does it happen to with pristine systems such as rescue or unmodifed Tumbleweed install? No such problems with current Tumbleweed 20210810 here:

**3400G:~ #** grep \(EE /var/log/Xorg.0.log 
        (WW) warning, **(EE**) error, (NI) not implemented, (??) unknown. 
     7.054] **(EE**) AMDGPU(0): Failed to make import prime FD as pixmap: 22 
**3400G:~ #**

Post #1 shows ‘kbdsettings.service @1.018s +2.155s’. Quite different here:

**3400G:~ #** systemd-analyze blame|grep kbd                           
  115ms **kbd**settings.service 
**3400G:~ #**
**3400G:~ #** systemd-analyze critical-chain display-manager.service 
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. 

**display-manager.service +664ms**
└─**apache2.service @1.169s +270ms**
  └─time-sync.target @1.160s 
    └─**chronyd.service @1.096s +63ms**
      └─nss-lookup.target @1.095s 
        └─**systemd-resolved.service @880ms +214ms**
          └─**systemd-networkd.service @810ms +68ms**
            └─**systemd-udevd.service @754ms +54ms**
              └─**systemd-hwdb-update.service @290ms +462ms**
                └─**systemd-remount-fs.service @244ms +42ms**
                  └─**systemd-fsck-root.service @584542y 2w 2d 20h 1min 48.750s +13ms**
                    └─systemd-journald.socket 
                      └─system.slice 
                        └─-.slice 
**3400G:~ #**

Something is fundamentally broken, in my opinion of course.

You never even told what display manager you are using …

Standard display managers (gdm, sddm, lightdm) are waiting for systemd-logind to announce “CanGraphical” and systemd-logind waits for DRM capable device to appear. So it sounds like you are using display manager which does not support logind integration, in which case it is up to you to add necessary dependencies to service that starts it.

Can you tell a difference?

Presumably the broken system does what it is supposed to do based on it’s configuration. The display-manager on my working system has a dependency on systemd-modules-load.service:

**3400G:~ #** systemctl list-dependencies  display-manager.service |grep mod                
●   ├─k**mod**-static-nodes.service 
●   ├─systemd-**mod**ules-load.service 
**3400G:~ #**

Hence display-manager.service waits until systemd-modules-load.service finished properly.

**3400G:~ #** journalctl -b -q -o short-monotonic -u systemd-modules-load.service 
    4.185514] 3400G systemd[1]: systemd-modules-load.service: Deactivated successfully. 
    4.185601] 3400G systemd[1]: Stopped Load Kernel Modules. 
    4.653106] 3400G systemd[1]: Finished Load Kernel Modules. 
**3400G:~ #**

Until now we have not seen any details on the broken machine.

How many of the broken machines would you like the details from? Besides those which which you already have by clicking the link to the bug, which details would you like?

Both my two newest PCs are similarly configured as all the old ones WRT keyboard configuration:

# diff -c1 .keyboard01 keyboard
*** .keyboard01 Thu Jun 21 08:43:03 2018
--- keyboard    Fri Aug 13 03:05:28 2021
***************
*** 9,11 ****
  # Keyboard delay time in ms (250, 500, 750, 1000)
! KBD_DELAY=""

--- 9,11 ----
  # Keyboard delay time in ms (250, 500, 750, 1000)
! KBD_DELAY="250"

***************
*** 15,17 ****
  # Keyboard repeat rate (2.0 - 30.0)
! KBD_RATE=""

--- 15,17 ----
  # Keyboard repeat rate (2.0 - 30.0)
! KBD_RATE="20.0"

***************
*** 22,24 ****
  # This setting may interfere with GNOME /org/gnome/settings-daemon/peripherals/keyboard/remember-numlock-state DConf key.
! KBD_NUMLOCK="bios"

--- 22,24 ----
  # This setting may interfere with GNOME /org/gnome/settings-daemon/peripherals/keyboard/remember-numlock-state DConf key.
! KBD_NUMLOCK="yes"
# systemd-analyze blame | grep kbd
2.088s kbdsettings.service

Above is from the Kaby Lake/i3-7100T host gb250, which sometimes works as expected, sometimes not. The last 4 or more it’s been good. The Kaby Lake/Pentium G4600 host ab250 is configured the same for everything I’ve remembered to check, but it religiously resists behaving as expected. In my K10, my 3rd newest PC, the comment #0 A10-7850K/R7 PC in the bug, kbd is even slower:

# systemd-analyze blame | grep kbd
2.582s kbdsettings.service

The 3 newest (and fastest, ~3s to graphical.target) machines found to have the problem are using TDM. My A8-8650B/R7 using amdgpu module and DDX doesn’t exactly do this. TDM fully paints, but there is no response to mouse clicks or typing username or password until I switch to a vtty and back. My test Haswell/Pentium G3220 ab85m works normally. All of these are IGPs, not discrete GPU add-in cards.

This only started happening less than 4 months ago, so if this is because something about systemd-logind in TW changed, it needs to be accounted for by TDM. If I knew when and what was changed in systemd-logind, if that’s the root of the change, I could forward that info to the TDM devs to fix. Then again, TDM isn’t called directly in openSUSE. I don’t think I’ve found a slower machine that does this, and it’s only on TW, while every problem PC also has 15.2 and 15.3 not doing this, which to be clear, is X is trying to start before the relevant KMS module and udev have produced /dev/dri/card0 and /dev/fb0.

Up until this started, TDM was a bulletproof replacement for KDM, including features absent from all other DMs.

I did a fresh minimal/Plasma install of TW20210810 on host asa88 with xdm only, no sddm or lightdm. The problem occurs randomly on it. Total startup time according to systemd-analyze varies between about 15s and 23s.

# systemd-analyze
Startup finished in 7.435s (firmware) + 8.117s (loader) + 1.839s (kernel) + 2.062s (initrd) + 3.364s (userspace) = 22.819s
graphical.target reached after 3.356s in userspace

Above was from a success.

# systemd-analyze
Startup finished in 5.970s (firmware) + 3.116s (loader) + 1.850s (kernel) + 2.062s (initrd) + 3.368s (userspace) = 16.368s
graphical.target reached after 3.360s in userspace

Above was from a successive success.

# systemd-analyze
Startup finished in 5.768s (firmware) + 7.100s (loader) + 1.846s (kernel) + 2.102s (initrd) + 3.486s (userspace) = 20.304s
graphical.target reached after 3.477s in userspace
# systemd-analyze critical-chain
...
graphical.target @3.477s
└─multi-user.target @3.477s
  └─kbdsettings.service @1.007s +2.469s
    └─basic.target @996ms
      └─sockets.target @996ms
        └─telnet.socket @995ms
          └─sysinit.target @987ms
            └─systemd-update-utmp.service @958ms +28ms
              └─systemd-tmpfiles-setup.service @927ms +28ms
                └─local-fs.target @924ms
                  └─usr-local.mount @876ms +48ms
                    └─systemd-fsck@dev-disk-by\x2dlabel-tvgp04usrlcl.service @663ms +204ms
                      └─local-fs-pre.target @650ms
                        └─systemd-tmpfiles-setup-dev.service @630ms +17ms
                          └─kmod-static-nodes.service @556ms +55ms
                            └─systemd-journald.socket
                              └─system.slice
                                └─-.slice

Next, above, was a failure.

# systemd-analyze
Startup finished in 5.933s (firmware) + 4.674s (loader) + 1.850s (kernel) + 2.104s (initrd) + 3.270s (userspace) = 17.832s
graphical.target reached after 3.261s in userspace
asa88:~ # systemd-analyze critical-chain
...
graphical.target @3.261s
└─display-manager.service @3.162s +98ms
  └─systemd-user-sessions.service @3.156s +5ms
    └─basic.target @980ms
      └─sockets.target @979ms
        └─telnet.socket @978ms
          └─sysinit.target @967ms
            └─systemd-update-utmp.service @950ms +16ms
              └─systemd-tmpfiles-setup.service @907ms +41ms
                └─local-fs.target @903ms
                  └─pub.mount @869ms +33ms
                    └─systemd-fsck@dev-disk-by\x2dlabel-tvgp06pub.service @671ms +193ms
                      └─local-fs-pre.target @639ms
                        └─systemd-tmpfiles-setup-dev.service @620ms +17ms
                          └─kmod-static-nodes.service @560ms +45ms
                            └─systemd-journald.socket
                              └─system.slice
                                └─-.slice

Again, above, a success. Next were 2 more successes, followed by 5 successive failures.

One of each kind: a working one and a broken one. I rarely rely on unfiltered journal when troubleshooting.

Both my two newest PCs are similarly configured as all the old ones WRT keyboard configuration:

# diff -c1 .keyboard01 keyboard
*** .keyboard01 Thu Jun 21 08:43:03 2018
--- keyboard    Fri Aug 13 03:05:28 2021
***************
*** 9,11 ****
  # Keyboard delay time in ms (250, 500, 750, 1000)
! KBD_DELAY=""

— 9,11 ----

Keyboard delay time in ms (250, 500, 750, 1000)

! KBD_DELAY=“250”


*** 15,17 ****

Keyboard repeat rate (2.0 - 30.0)

! KBD_RATE=“”

— 15,17 ----

Keyboard repeat rate (2.0 - 30.0)

! KBD_RATE=“20.0”


*** 22,24 ****

This setting may interfere with GNOME /org/gnome/settings-daemon/peripherals/keyboard/remember-numlock-state DConf key.

! KBD_NUMLOCK=“bios”

— 22,24 ----

This setting may interfere with GNOME /org/gnome/settings-daemon/peripherals/keyboard/remember-numlock-state DConf key.

! KBD_NUMLOCK=“yes”

systemd-analyze blame | grep kbd

2.088s kbdsettings.service

Above is from the Kaby Lake/i3-7100T host gb250, which sometimes works as expected, sometimes not. The last 4 or more it's been good. The Kaby Lake/Pentium G4600 host ab250 is configured the same for everything I've remembered to check, but it religiously resists behaving as expected. In my K10, my 3rd newest PC, the comment #0 A10-7850K/R7 PC in the bug, kbd is even slower:

systemd-analyze blame | grep kbd

2.582s kbdsettings.service

You are comparing contents of files. What matters too during initialization is relation between units. More detailed output from units pertaining to kbd may be helpful.

The 3 newest (and fastest, ~3s to graphical.target) machines found to have the problem are using TDM. My A8-8650B/R7 using amdgpu module and DDX doesn’t exactly do this. TDM fully paints, but there is no response to mouse clicks or typing username or password until I switch to a vtty and back. My test Haswell/Pentium G3220 ab85m works normally. All of these are IGPs, not discrete GPU add-in cards.

Speed is a often a symptom, not a cause. Again, what matters most is relations between units. Hypothesizing without relying on ordering and dependencies of units can be inefficient.

This only started happening less than 4 months ago, so if this is because something about systemd-logind in TW changed, it needs to be accounted for by TDM. If I knew when and what was changed in systemd-logind, if that’s the root of the change, I could forward that info to the TDM devs to fix. Then again, TDM isn’t called directly in openSUSE. I don’t think I’ve found a slower machine that does this, and it’s only on TW, while every problem PC also has 15.2 and 15.3 not doing this, which to be clear, is X is trying to start before the relevant KMS module and udev have produced /dev/dri/card0 and /dev/fb0.

I am happy with sddm. Out of curiosity I tried lighttdm as well as xdm. They both work the same as sddm. display-manager.service only starts after systemd-modules-load.service has completed successfully.

In case of failure is xdm started from outside of unit display-manager.service?

I’m not sure what this means. It always starts if after failure I login and do:

systemctl restart xdm

I just sent more info to the bug a little bit ago.

I still don’t know which details you’d like.

WRT kbd load time, I don’t recall ever noticing under 2s here on any openSUSE installation. Current on the Haswell running 15.2 I’m typing from it was 2.035s kbdsettings.service. On the last TW boot of Kaby Lake host gb250 it was 2.097s kbdsettings.service, and of 15.3 2.061s kbdsettings.service. On the current boot of TW20210810 host asa88 it was 2.378s kbdsettings.service. On host asa88:

# systemd-analyze blame | grep key
 636ms keyboard-setup.service

results booted to Debian 11. From Fedora 34 boot, grep of neither key nor kbd produce any response.

I tried replacing the current /etc/sysconfig/keyboard on asa88 with the original. The result:

# systemd-analyze blame | grep kbd
 161ms kbdsettings.service

Obviously something to do with changing repeat and delay and turning NUM on takes time. However, xdm still failed to start for same reason. :frowning:

I’m not across all the details of this thread, but I note in comment#14 of your bug report, you speculate…

Without radeon.cik_support=0 amdgpu.cik_support=1 on cmdline I managed success on 11 straight boots, so it seems amdgpu.ko.xz simply doesn’t get loaded as fast/soon as radeon.ko.xz.

Is the module included in initrd (early KMS)?

lsinitrd |grep amdgpu.ko

If necessary, the amdgpu module could be loaded early by creating a file eg /etc/dracut.conf.d/amdgpu.conf with the following entry…

add_drivers+=" amdgpu "

then do

mkinitrd

Apologies if I’m on the wrong track here.

Thanks for your attention. :slight_smile:

It’s not in any of them on either installation. Early on after learning of the absences in /dev/ I thought about doing that. I did not, because:

  1. This is a test box. I need to be able to run either radeon or amdgpu according to whether radeon.cik_support=0 amdgpu.cik_support=1 is on cmdline or not. Stefan Dirsch is of the opinion I should be using the radeon module and radeon DDX driver. Needing 2 initrds per kernel I expect would be more trouble than just restarting xdm when necessary.
  2. I don’t expect X should try to start before switchroot completes, in which case graphics module can and should still load before X tries to start.

Is there some early KMS method that doesn’t require the module be in the initrd?

In other words: What is your output of:

**3400G:~ #** journalctl -b -o short-monotonic -u display-manager.service -u systemd-modules-load.service -g St 
-- Journal begins at Wed 2021-06-30 12:45:56 CEST, ends at Sat 2021-08-14 10:39:04 CEST. -- 
    4.166114] 3400G systemd[1]: Stopped Load Kernel Modules. 
    5.288606] 3400G systemd[1]: Starting X Display Manager... 
    5.538684] 3400G sddm[977]: **St**arting... 
    5.974152] 3400G systemd[1]: Started X Display Manager. 
    6.444315] 3400G sddm-helper[1082]: [PAM] **St**arting... 
   13.542718] 3400G sddm-helper[1192]: [PAM] **St**arting... 
   13.795228] 3400G sddm-helper[1192]: Starting: "/usr/etc/X11/xdm/Xsession \"/usr/bin/startplasma-x11\"" 
**3400G:~ #** 

Show both a working boot and and a failing boot.

No, the pertinent graphics driver modules for the GPU(s) are added to the initrd to facilitate early KMS. If not done there it would happen later ie Late KMS start.

Reference:
https://wiki.archlinux.org/title/Kernel_mode_setting

I guess you could delay starting the X-server on your test box? Perhaps boot to multi-user.target mode instead, and then switch to graphical mode manually?

On the fresh TW20210810 installation (xdm only)

# ls -ld /root/inst-sys
drwxr-xr-x 5 root root 2048 Aug 13 22:42 /root/inst-sys

Failure:

# journalctl -b -o short-monotonic -u display-manager.service -u systemd-modules-load.service -g St
-- Journal begins at Fri 2021-08-13 23:33:06 EDT, ends at Sat 2021-08-14 16:38:53 EDT. --
    4.123347] localhost systemd[1]: Stopped Load Kernel Modules.
    7.093855] asa88 systemd[1]: Starting X Display Manager...
    7.273405] asa88 display-manager[745]: Starting service xdm
    7.273822] asa88 systemd[1]: Started X Display Manager.

Success (on very next attempt):

# journalctl -b -o short-monotonic -u display-manager.service -u systemd-modules-load.service -g St
-- Journal begins at Fri 2021-08-13 23:33:06 EDT, ends at Sat 2021-08-14 16:40:20 EDT. --
    3.855376] localhost systemd[1]: Stopped Load Kernel Modules.
    7.641315] asa88 systemd[1]: Starting X Display Manager...
    7.747472] asa88 display-manager[750]: Starting service xdm
    7.747956] asa88 systemd[1]: Started X Display Manager.

On the original TW installation now 20210810 (with tdm)

# ls -ld /root/inst-sys
drwxr-xr-x 5 root root 4096 Jun 21  2018 /root/inst-sys

Failure:

# journalctl -b -o short-monotonic -u display-manager.service -u systemd-modules-load.service -g St
-- Journal begins at Sat 2021-01-16 18:26:29 EST, ends at Sat 2021-08-14 16:50:47 EDT. --
    3.849113] asa88 systemd[1]: Stopped Load Kernel Modules.
    6.231843] asa88 systemd[1]: Starting X Display Manager...
    7.383982] asa88 display-manager[651]: Starting service tdm
    7.384359] asa88 systemd[1]: Started X Display Manager.

Success (failure repeated on 6 attempts prior):

# journalctl -b -o short-monotonic -u display-manager.service -u systemd-modules-load.service -g St
-- Journal begins at Sat 2021-01-16 18:26:29 EST, ends at Sat 2021-08-14 17:03:19 EDT. --
   10.494045] asa88 systemd[1]: Stopped Load Kernel Modules.
   16.084692] asa88 systemd[1]: Starting X Display Manager...
   17.440100] asa88 display-manager[655]: Starting service tdm
   17.448132] asa88 systemd[1]: Started X Display Manager.

If multi-user.target wasn’t the default on most of my installations I probably would have discovered this months ago, likely right after some change in some standard configuration that might easily have been noticed. Xorg always works after booting to multi-user before running startx or isolating graphical.target.

Is anyone else comparing here using only systemd-networkd, neither NetworkManager nor Wicked, and static IP, with ipv6.disable=1 on kernel command lines? I think the time I first noticed this probably was after the time[1] I started switching from Wicked to the simpler (to me) systemd-networkd, with default startup multi-user.target, normally appending 5 to cmdline whenever I wanted to go directly to greeter.

[1] 23 March 2021: bug 1183886.

Right. It might be interesting to delay the start of the display manager (eg custom service with delay built-in), and observe if that helps in any way.

Quite a difference in display-manager.service timing, around 6s later start, when I switch back to wicked:

# journalctl -b -o short-monotonic -u display-manager.service -u systemd-modules-load.service -g St
-- Journal begins at Fri 2021-08-13 23:33:06 EDT, ends at Sat 2021-08-14 17:38:24 EDT. --
    3.731005] localhost systemd[1]: Stopped Load Kernel Modules.
   13.312481] asa88 systemd[1]: Starting X Display Manager...
   13.411758] asa88 display-manager[1013]: Starting service xdm
   13.412175] asa88 systemd[1]: Started X Display Manager.

This reversion to Wicked has resulted in xdm success 7 straight times, no failures.

# journalctl -b -o short-monotonic -u display-manager.service -u systemd-modules-load.service -g St
-- Journal begins at Fri 2021-08-13 23:33:06 EDT, ends at Sat 2021-08-14 17:45:30 EDT. --
    3.770809] localhost systemd[1]: Stopped Load Kernel Modules.
   13.441063] asa88 systemd[1]: Starting X Display Manager...
   13.538675] asa88 display-manager[1015]: Starting service xdm
   13.539001] asa88 systemd[1]: Started X Display Manager.
# systemd-analyze
Startup finished in 5.929s (firmware) + 4.666s (loader) + 1.842s (kernel) + 2.106s (initrd) + 9.602s (userspace) = 24.146s
graphical.target reached after 9.591s in userspace
# systemd-analyze critical-chain
...
graphical.target @9.591s
└─display-manager.service @9.492s +97ms
  └─systemd-user-sessions.service @9.484s +5ms
    └─network.target @9.368s
      └─wicked.service @3.718s +5.649s
        └─wickedd-nanny.service @3.695s +20ms
          └─wickedd.service @3.661s +31ms
            └─wickedd-dhcp6.service @3.609s +50ms
              └─dbus.service @3.588s
                └─basic.target @3.585s
                  └─sockets.target @3.585s
                    └─telnet.socket @3.585s
                      └─sysinit.target @3.579s
                        └─systemd-udev-settle.service @684ms +2.893s
                          └─systemd-udev-trigger.service @599ms +83ms
                            └─systemd-udevd-kernel.socket @563ms
                              └─system.slice
                                └─-.slice
# systemd-analyze blame | head -n22
5.649s wicked.service
2.893s systemd-udev-settle.service
2.259s systemd-random-seed.service
1.188s dracut-initqueue.service
 671ms initrd-switch-root.service
 304ms initrd-parse-etc.service
 293ms systemd-journal-flush.service
 287ms user@0.service
 210ms systemd-fsck@dev-disk-by\x2dlabel-tvgp05home.service
 209ms systemd-fsck@dev-disk-by\x2dlabel-tvgp04usrlcl.service
 207ms systemd-fsck@dev-disk-by\x2dlabel-tvgp06pub.service
 206ms systemd-udevd.service
 112ms smartd.service
  97ms display-manager.service
  88ms chronyd.service
  85ms kbdsettings.service
  83ms systemd-udev-trigger.service
  72ms apparmor.service
  65ms modprobe@drm.service
  59ms sshd.service
  57ms dev-hugepages.mount
  56ms dev-mqueue.mount