You are not logged in.
- Topics: Active | Unanswered
#1 2025-09-29 16:58:12
- Cbhihe
- Member
- Registered: 2017-04-09
- Posts: 242
[SOLVED] Black screen at boot (failed to start GDM)
On an up-to-date system running on kernel 6.16.18 arch3-1 #1 SMP PREEMPT_DYNAMIC with GDM on Xorg, I get a black screen and the following at boot:
Unable to resume from device '/dev/disk/by-uuid/..[swap uuid] ..' (259:6) offset 0, continuing boot process.
/root: clean, 525056/20052000 files 5948491/8192000 blocks
[ TIMED ] Timed out waiting for device /dev/tmp0.
[FAILED] Failed to start GNOME Display Manager.
Beside the fact that the swap volume seems not to be recognized (in /etc/fstab ?) or correctly indexed by its UUID (but it is!) and I don't resume from hibernation or anything like that when booting, Grub seems to be completely functional and restarting the laptop I can drop to console by picking the Grub menu to continue booting in recovery/rescue mode:
Is this a GDM on X11 issue here ? (I initially preferred X11 to Wayland for that host due to issues using Wayland and GDM with the laptop's NVIDIA discrete GPU.)
/etc/fstab
File looks untouched (did not register a change) and UUIDs are all correct, including the SWAP volume's UUID.
/etc/gdm/custom.conf
...
WaylandEnable=false
...Wayland is disabled as expected.
> stat /usr/lib/gdm-disable-wayland
stat: cannot statx '/usr/lib/gdm-disable-wayland': No such file or dirrectory.and this is the corresponding (last) boot log. Any help would be great.
Last edited by Cbhihe (2025-10-01 05:09:27)
I like strawberries, therefore I'm not a bot.
Offline
#2 2025-09-29 17:06:47
- Scimmia
- Fellow
- Registered: 2012-09-01
- Posts: 13,084
Re: [SOLVED] Black screen at boot (failed to start GDM)
/etc/gdm/custom.conf:WaylandEnable=false Wayland is disabled as expected.
Which is a serious problem when GDM/GNOME no longer supports X11. If not Wayland, then what?
Offline
#3 2025-09-29 17:36:35
- Cbhihe
- Member
- Registered: 2017-04-09
- Posts: 242
Re: [SOLVED] Black screen at boot (failed to start GDM)
Tx Scimmia:
If so, I was not aware about the fact that GDM's support for X11 had been finally dropped, although I heard of Wayland as the new kid in town years ago.
I can probably perform surgery on the host system. But how involved is the migration path from X11 to Wayland ? A simple "read this and that" response would be fine.
Meanwhile I saw elsewhere that the host wouId need to have NVIDIA kernel modesetting enabled (add the kernel parameter nvidia-drm.modeset=1), etc ...
The problem if there is any is I also follow this, and based on that thread I am not clear at all on whether Wayland is now the mature piece of software capable of replacing X11.
A further nudge and advice any one ?
I like strawberries, therefore I'm not a bot.
Offline
#4 2025-09-29 19:09:19
- seth
- Member
- From: Don't DM me only for attention
- Registered: 2012-09-03
- Posts: 69,138
Re: [SOLVED] Black screen at boot (failed to start GDM)
You'll have to try - fwwi, the nvidia chip is currently not in use at all (according to your journal) but the pascal chip should™ not give you too many headaches wrt wayland (kms is enabled by default)
Whether other wayland related issues affect *you* is something *you* will have to figure and then in doubt ask back about specific problems.
For now just set "WaylandEnable=true"
Offline
#5 2025-09-30 10:48:22
- Cbhihe
- Member
- Registered: 2017-04-09
- Posts: 242
Re: [SOLVED] Black screen at boot (failed to start GDM)
OK, kms is default-enabled for the Intel on-board grahics.
Will report here for any issue and solution(s) found for the host, first with its NVIDIA discrte GPU disabled, then when I convince myself than all is fine, I will enable the NVIDIA discrete GPU again. All with Gnome v49.0 of course.
I changed settings in /etc/gdm/custom.conf to:
[daemon]
#WaylandEnable=false
...
[debug]
Enable=trueso Wayland becomes the go-to (default) backend and logging is enabled.
After reboot I do get to the Gnome login window window.
After GDM session user login, there is a long wait to get to the actual desktop and its usual GUI objects. A second reboot does exhibit more or less the same lag.
As expected I lost a few useful, xorg-dependent keyboard shortcuts, key-combinations previously available within GDM sessions. I depend on at least one of them to toggle laptop mouse pad on/off, so I'll get to that later.
But first, timings:
> systemd-analyze
Startup finished in 6min 26.71s (firmware) + 3.673s (loader) + 3.972s (kernel) + 1min 33.337s (userspace) = 8min 7.714s
`graphical.target` reached after 1min 33.058s in userspace.
> systemd-analyze --fuzz=1s critical-chain
...
graphical.target @1min 33.058s
└─multi-user.target @1min 33.058s
├─docker.service @1min 31.535s +1.522s
│ ├─network-online.target @1min 31.533s
│ │ ├─netctl-wait-online.service @1min 31.127s +405ms
│ │ │ ├─network.target @1min 31.119s
│ │ │ │ ├─netctl-auto@wifi0.service @1min 30.646s +472ms
│ │ │ │ │ ├─basic.target @1min 30.641s
│ │ │ │ │ │ ├─dbus-broker.service @1min 30.579s +42ms
│ │ │ │ │ │ │ └─dbus.socket @1min 30.561s +89us
│ │ │ │ │ │ │ └─sysinit.target @1min 30.554s
│ │ │ │ │ │ │ └─tpm2.target @1min 30.547s
│ │ │ │ │ │ ├─sockets.target @1min 30.584s
│ │ │ │ │ │ │ ├─docker.socket @1min 30.562s +22ms
│ │ │ │ │ │ │ │ └─sysinit.target @1min 30.554s
│ │ │ │ │ │ │ │ └─...
│ │ │ │ │ │ │ ├─systemd-machined.socket @1min 30.568s +137us
│ │ │ │ │ │ │ │ └─sysinit.target @1min 30.554s
│ │ │ │ │ │ │ │ └─...
│ │ │ │ │ │ │ ├─systemd-logind-varlink.socket @1min 30.568s +60us
│ │ │ │ │ │ │ │ └─sysinit.target @1min 30.554s
│ │ │ │ │ │ │ │ └─...
│ │ │ │ │ │ │ ├─systemd-hostnamed.socket @1min 30.568s +64us
│ │ │ │ │ │ │ │ └─sysinit.target @1min 30.554s
│ │ │ │ │ │ │ │ └─...
│ │ │ │ │ │ │ ├─sshd-unix-local.socket @1min 30.565s +2ms
│ │ │ │ │ │ │ │ └─sysinit.target @1min 30.554s
│ │ │ │ │ │ │ │ └─...
│ │ │ │ │ │ │ ├─pcscd.socket @1min 30.565s +88us
│ │ │ │ │ │ │ │ └─sysinit.target @1min 30.554s
│ │ │ │ │ │ │ │ └─...
│ │ │ │ │ │ │ ├─keyboxd@etc-pacman.d-gnupg.socket @1min 30.565s +109us
│ │ │ │ │ │ │ │ └─sysinit.target @1min 30.554s
│ │ │ │ │ │ │ │ └─...
│ │ │ │ │ │ │ ├─gpg-agent@etc-pacman.d-gnupg.socket @1min 30.564s +117us
│ │ │ │ │ │ │ │ └─sysinit.target @1min 30.554s
│ │ │ │ │ │ │ │ └─...
│ │ │ │ │ │ │ ├─gpg-agent-ssh@etc-pacman.d-gnupg.socket @1min 30.564s +101us
│ │ │ │ │ │ │ │ └─sysinit.target @1min 30.554s
│ │ │ │ │ │ │ │ └─...
│ │ │ │ │ │ │ ├─gpg-agent-extra@etc-pacman.d-gnupg.socket @1min 30.564s +110us
│ │ │ │ │ │ │ │ └─sysinit.target @1min 30.554s
│ │ │ │ │ │ │ │ └─...
│ │ │ │ │ │ │ ├─gpg-agent-browser@etc-pacman.d-gnupg.socket @1min 30.564s +140us
│ │ │ │ │ │ │ │ └─sysinit.target @1min 30.554s
│ │ │ │ │ │ │ │ └─...
│ │ │ │ │ │ │ ├─dirmngr@etc-pacman.d-gnupg.socket @1min 30.561s +357us
│ │ │ │ │ │ │ │ └─sysinit.target @1min 30.554s
│ │ │ │ │ │ │ │ └─...
│ │ │ │ │ │ ├─paths.target @1min 30.560s
│ │ │ │ │ │ │ └─cups.path @1min 30.558s
│ │ │ │ │ │ │ └─sysinit.target @1min 30.554s
│ │ │ │ │ │ │ └─...
│ │ │ │ │ │ └─sysinit.target @1min 30.554s
│ │ │ │ │ │ └─...
│ │ │ │ │ └─sysinit.target @1min 30.554s
│ │ │ │ │ └─...
│ │ │ │ └─netctl.service @1min 30.662s +15ms
│ │ │ │ ├─basic.target @1min 30.641s
│ │ │ │ │ └─...
│ │ │ │ └─sysinit.target @1min 30.554s
│ │ │ │ └─...
│ │ │ ├─basic.target @1min 30.641s
│ │ │ │ └─...
│ │ │ └─sysinit.target @1min 30.554s
│ │ │ └─...
│ │ └─network.target @1min 31.119s
│ │ └─...
│ ├─containerd.service @1min 31.122s +189ms
│ │ ├─network.target @1min 31.119s
│ │ │ └─...
│ │ ├─basic.target @1min 30.641s
│ │ │ └─...
│ │ ├─dbus-broker.service @1min 30.579s +42ms
│ │ │ └─...
│ │ └─sysinit.target @1min 30.554s
│ │ └─...
│ ├─basic.target @1min 30.641s
│ │ └─...
│ ├─docker.socket @1min 30.562s +22ms
│ │ └─...
│ └─sysinit.target @1min 30.554s
│ └─...
├─tor.service @1min 31.152s +1.271s
│ ├─network.target @1min 31.119s
│ │ └─...
│ ├─basic.target @1min 30.641s
│ │ └─...
│ └─sysinit.target @1min 30.554s
│ └─...
└─nmb.service @1min 31.536s +844ms
├─network-online.target @1min 31.533s
│ └─...
├─network.target @1min 31.119s
│ └─...
├─basic.target @1min 30.641s
│ └─...
└─sysinit.target @1min 30.554s
└─...
> systemd-analyze blame
18.709s plocate-updatedb.service
1.522s docker.service
1.271s tor.service
844ms nmb.service
823ms systemd-binfmt.service
579ms dev-nvme0n1p8.device
472ms netctl-auto@wifi0.service
421ms postfix.service
405ms netctl-wait-online.service
353ms systemd-udev-trigger.service
307ms user@1000.service
295ms cups.service
272ms tlp.service
229ms upower.service
189ms containerd.service
172ms accounts-daemon.service
168ms ufw.service
165ms udisks2.service
161ms boot-efi.mount
160ms systemd-journal-flush.service
156ms systemd-fsck@dev-disk-by\x2duuid-cd9f3fc4\x2df67f\x2d42c4\x2d8190\x2d21d2766d2b65.service
155ms systemd-timesyncd.service
147ms systemd-tmpfiles-setup.service
143ms paccache.service
123ms logrotate.service
109ms lvm2-monitor.service
101ms systemd-journald.service
101ms systemd-tmpfiles-clean.service
100ms systemd-udevd.service
94ms systemd-hostnamed.service
92ms systemd-tmpfiles-setup-dev-early.service
89ms lm_sensors.service
82ms polkit.service
79ms systemd-resolved.service
78ms mnt-BU_HD2.mount
66ms systemd-logind.service
64ms systemd-fsck@dev-disk-by\x2duuid-4EFA\x2d2D6E.service
60ms bluetooth.service
53ms systemd-backlight@backlight:intel_backlight.service
52ms systemd-backlight@leds:dell::kbd_backlight.service
52ms systemd-fsck@dev-disk-by\x2duuid-2dd5a6b7\x2d7dc2\x2d4f34\x2d9c74\x2dd04f0e951a6a.service
49ms colord.service
45ms user-runtime-dir@1000.service
44ms systemd-vconsole-setup.service
44ms systemd-homed.service
43ms systemd-random-seed.service
43ms systemd-fsck@dev-disk-by\x2duuid-061f3fa7\x2d773a\x2d453e\x2dbbf4\x2d3f61ed3c6058.service
43ms systemd-tmpfiles-setup-dev.service
42ms dbus-broker.service
40ms systemd-fsck@dev-disk-by\x2duuid-c96f3541\x2d0ea5\x2d4686\x2daa63\x2d795e833b9ac9.service
38ms dev-disk-by\x2duuid-c1e198e1\x2ddb13\x2d4834\x2d9b86\x2dff6dd6b2d415.swap
35ms alsa-restore.service
34ms boot.mount
33ms systemd-modules-load.service
28ms systemd-userdbd.service
26ms systemd-userdb-load-credentials.service
26ms sshd.service
25ms proc-sys-fs-binfmt_misc.mount
25ms rtkit-daemon.service
23ms modprobe@dm_mod.service
23ms dev-hugepages.mount
22ms docker.socket
22ms dev-mqueue.mount
22ms sys-kernel-tracing.mount
22ms sys-kernel-debug.mount
21ms systemd-remount-fs.service
20ms kmod-static-nodes.service
20ms gdm.service
20ms systemd-update-utmp.service
19ms home.mount
18ms sys-kernel-config.mount
18ms var.mount
17ms wpa_supplicant.service
17ms systemd-user-sessions.service
16ms systemd-sysctl.service
16ms sys-fs-fuse-connections.mount
15ms netctl.service
15ms modprobe@loop.service
12ms systemd-udev-load-credentials.service
9ms tmp.mount
2ms sshd-unix-local.socket
2ms systemd-sysext.socket
1ms systemd-bootctl.socket
1ms systemd-ask-password.socket
1ms systemd-coredump.socket
949us systemd-factory-reset.socket
603us systemd-creds.socket
357us dirmngr@etc-pacman.d-gnupg.socket
354us systemd-importd.socket
140us cups.socket
140us gpg-agent-browser@etc-pacman.d-gnupg.socket
137us systemd-machined.socket
123us systemd-homed-activate.service
117us gpg-agent@etc-pacman.d-gnupg.socket
110us gpg-agent-extra@etc-pacman.d-gnupg.socket
109us keyboxd@etc-pacman.d-gnupg.socket
101us gpg-agent-ssh@etc-pacman.d-gnupg.socket
89us dbus.socket
88us pcscd.socket
64us systemd-hostnamed.socket
60us systemd-logind-varlink.socket
52us systemd-journald-dev-log.socket
44us systemd-journald.socket
39us lvm2-lvmpolld.socket
34us systemd-resolved-monitor.socket
30us dm-event.socket
29us systemd-udevd-control.socket
29us systemd-userdbd.socket
27us systemd-udevd-varlink.socket
19us systemd-resolved-varlink.socket
14us systemd-udevd-kernel.socketSo to me nothing special there.
`gdm.service` took only 20ms,
`user@1000.service` comes in later and perhaps slower than with X11 I think, at 307ms,
`
Lags I notice are:
- 1.271s when the tor service hits the road; nothing to do there and by that time tor.service is up, userspace GUI has been on for a long time anyway),
- 0.579s when nvme0n1p8 is mounted (that's the root partition).-
A few surprises (at least for the noob in me);
(i) there should be nothing to the very small nvme0n1p8 partition, unless the output tag for `systemd-analyze blame`is just that, a "tag", and it just point out to sequential mount processes of each and everyone of the partitioned SSD volume.
(ii) I expected a `gnome-session` entry, and I have none.
(iii) the system seems to be waiting for network and the graphical target depends on the network.target. I am not 100% sure any longer but it was not the case for GDM on X11. In fact I had a fully functional GUI user space long before (maybe a 1~3s lag back then) I could get network connectivity.
However the user session login screen comes in early, the lag I register is after entering username and passwd. So I am kinda stuck here, I see:
graphical.target @1min 33.058s
└─multi-user.target @1min 33.058s
├─docker.service @1min 31.535s +1.522s
│ ├─network-online.target @1min 31.533s
│ │ ├─netctl-wait-online.service @1min 31.127s +405ms
│ │ │ ├─network.target @1min 31.119s
│ │ │ │ ├─netctl-auto@wifi0.service @1min 30.646s +472msbut, yet again, the user session login screen comes on BEFORE 1min 31.533s. I am not seeing something, i think.
Last edited by Cbhihe (2025-10-01 05:24:42)
I like strawberries, therefore I'm not a bot.
Offline
#6 2025-09-30 12:23:34
- seth
- Member
- From: Don't DM me only for attention
- Registered: 2012-09-03
- Posts: 69,138
Re: [SOLVED] Black screen at boot (failed to start GDM)
└─sysinit.target @1min 30.554s
└─...You're starting out w/ a 90s delay what smells like 1 systemd service timeout.
=> journal?
Offline
#7 2025-09-30 12:25:30
- Cbhihe
- Member
- Registered: 2017-04-09
- Posts: 242
Re: [SOLVED] Black screen at boot (failed to start GDM)
In addition:
> systemctl cat gdm.service
# /usr/lib/systemd/system/gdm.service
[Unit]
Description=GNOME Display Manager
# replaces the getty
Conflicts=getty@tty1.service
After=getty@tty1.service
# replaces plymouth-quit since it quits plymouth on its own
Conflicts=plymouth-quit.service
After=plymouth-quit.service
# Needs all the dependencies of the services it's replacing
# pulled from getty@.service and plymouth-quit.service
# (except for plymouth-quit-wait.service since it waits until
# plymouth is quit, which we do)
After=rc-local.service plymouth-start.service systemd-user-sessions.service
# GDM takes responsibility for stopping plymouth, so if it fails
# for any reason, make sure plymouth still stops
OnFailure=plymouth-quit.service
[Service]
ExecStart=/usr/bin/gdm
KillMode=mixed
Restart=always
IgnoreSIGPIPE=no
BusName=org.gnome.DisplayManager
EnvironmentFile=-/etc/locale.conf
ExecReload=/bin/kill -SIGHUP $MAINPID
KeyringMode=shared
[Install]
Alias=display-manager.serviceSo I guess `gdm.service` has no dependency on `network-online.target`, it starts independently of network services, and that seems to fit the fact I see the GDM user login screen early on (with a lag fully comparable to that of the previous X11 "windower".
What I will try is to disable `netctl-wait-online.service` and shave a whole minute off the graphical target's availability time.
Report after reboot.
Last edited by Cbhihe (2025-10-01 05:00:11)
I like strawberries, therefore I'm not a bot.
Offline
#8 2025-09-30 14:36:47
- Cbhihe
- Member
- Registered: 2017-04-09
- Posts: 242
Re: [SOLVED] Black screen at boot (failed to start GDM)
The new boot journal is here.
By disabling `netctl-wait-online.service`, I effectively added to the lag time for the graphical target, by 700 ms... What gives ?
> systemd-analyze --fuzz=1s critical-chain
...
graphical.target @1min 33.735s
└─multi-user.target @1min 33.735s
└─docker.service @1min 31.177s +2.556s
├─containerd.service @1min 30.988s +185ms
│ ├─network.target @1min 30.986s
│ │ ├─netctl-auto@wifi0.service @1min 30.522s +462ms
│ │ │ ├─basic.target @1min 30.506s
│ │ │ │ ├─dbus-broker.service @1min 30.449s +39ms
│ │ │ │ │ └─dbus.socket @1min 30.428s +152us
│ │ │ │ │ └─sysinit.target @1min 30.420s
│ │ │ │ │ └─tpm2.target @1min 30.413s
│ │ │ │ ├─sockets.target @1min 30.453s
│ │ │ │ │ ├─docker.socket @1min 30.429s +23ms
│ │ │ │ │ │ └─sysinit.target @1min 30.420s
│ │ │ │ │ │ └─...
│ │ │ │ │ ├─systemd-machined.socket @1min 30.438s +155us
│ │ │ │ │ │ └─sysinit.target @1min 30.420s
│ │ │ │ │ │ └─...
│ │ │ │ │ ├─systemd-logind-varlink.socket @1min 30.437s +71us
│ │ │ │ │ │ └─sysinit.target @1min 30.420s
│ │ │ │ │ │ └─...
│ │ │ │ │ ├─systemd-hostnamed.socket @1min 30.437s +74us
│ │ │ │ │ │ └─sysinit.target @1min 30.420s
│ │ │ │ │ │ └─...
│ │ │ │ │ ├─sshd-unix-local.socket @1min 30.433s +3ms
│ │ │ │ │ │ └─sysinit.target @1min 30.420s
│ │ │ │ │ │ └─...
│ │ │ │ │ ├─pcscd.socket @1min 30.433s +132us
│ │ │ │ │ │ └─sysinit.target @1min 30.420s
│ │ │ │ │ │ └─...
│ │ │ │ │ ├─keyboxd@etc-pacman.d-gnupg.socket @1min 30.433s +117us
│ │ │ │ │ │ └─sysinit.target @1min 30.420s
│ │ │ │ │ │ └─...
│ │ │ │ │ ├─gpg-agent@etc-pacman.d-gnupg.socket @1min 30.433s +129us
│ │ │ │ │ │ └─sysinit.target @1min 30.420s
│ │ │ │ │ │ └─...
│ │ │ │ │ ├─gpg-agent-ssh@etc-pacman.d-gnupg.socket @1min 30.432s +127us
│ │ │ │ │ │ └─sysinit.target @1min 30.420s
│ │ │ │ │ │ └─...
│ │ │ │ │ ├─gpg-agent-extra@etc-pacman.d-gnupg.socket @1min 30.432s +121us
│ │ │ │ │ │ └─sysinit.target @1min 30.420s
│ │ │ │ │ │ └─...
│ │ │ │ │ ├─gpg-agent-browser@etc-pacman.d-gnupg.socket @1min 30.432s +157us
│ │ │ │ │ │ └─sysinit.target @1min 30.420s
│ │ │ │ │ │ └─...
│ │ │ │ │ ├─dirmngr@etc-pacman.d-gnupg.socket @1min 30.428s +534us
│ │ │ │ │ │ └─sysinit.target @1min 30.420s
│ │ │ │ │ │ └─...
│ │ │ │ │ ├─dbus.socket @1min 30.428s +152us
│ │ │ │ │ │ └─...
│ │ │ │ │ └─cups.socket @1min 30.427s +180us
│ │ │ │ │ └─sysinit.target @1min 30.420s
│ │ │ │ │ └─...
│ │ │ │ ├─paths.target @1min 30.427s
│ │ │ │ │ └─cups.path @1min 30.425s
│ │ │ │ │ └─sysinit.target @1min 30.420s
│ │ │ │ │ └─...
│ │ │ │ └─sysinit.target @1min 30.420s
│ │ │ │ └─...
│ │ │ └─sysinit.target @1min 30.420s
│ │ │ └─...
│ │ └─netctl.service @1min 30.525s +11ms
│ │ ├─basic.target @1min 30.506s
│ │ │ └─...
│ │ └─sysinit.target @1min 30.420s
│ │ └─...
│ ├─basic.target @1min 30.506s
│ │ └─...
│ ├─dbus-broker.service @1min 30.449s +39ms
│ │ └─...
│ └─sysinit.target @1min 30.420s
│ └─...
├─basic.target @1min 30.506s
│ └─...
├─docker.socket @1min 30.429s +23ms
│ └─...
└─sysinit.target @1min 30.420s
└─...I like strawberries, therefore I'm not a bot.
Offline
#9 2025-09-30 15:16:20
- Cbhihe
- Member
- Registered: 2017-04-09
- Posts: 242
Re: [SOLVED] Black screen at boot (failed to start GDM)
Thank you @Seth for putting me on that track. I actually did not know that the Systemd's default timeout value was 90s.
So the 90-second lag seems to be caused by a non-existent or non-reachable `dev-tpm0.device` timeout, not a compositor lag as I thought.
I masked the device.
> sudo systemctl mask dev-tpm0.device
>followed by reboot. There is no unexplained lag at this point. This was not a Wayland (and previously never a X11) issue, rather a TPM-related systemd unit(s) thing.
Last edited by Cbhihe (2025-10-01 04:58:16)
I like strawberries, therefore I'm not a bot.
Offline
#10 2025-09-30 17:31:05
- seth
- Member
- From: Don't DM me only for attention
- Registered: 2012-09-03
- Posts: 69,138
Re: [SOLVED] Black screen at boot (failed to start GDM)
https://bbs.archlinux.org/viewtopic.php … 9#p2263999 ?
(caused by the systemd 258 update)
Offline
#11 2025-09-30 18:40:07
- Cbhihe
- Member
- Registered: 2017-04-09
- Posts: 242
Re: [SOLVED] Black screen at boot (failed to start GDM)
Just read that, @seth.
Tx for the pointers. The two hosts (conflated in one), for which I opened this forum query are indeed older machines as well (bought two weeks apart ca 2017, I think).
CLOSED.
Last edited by Cbhihe (2025-10-01 04:55:20)
I like strawberries, therefore I'm not a bot.
Offline