Investigated this on the affected machine directly (CID 202603-38529). This is
not a kernel bug. Root cause is a systemd ordering cycle in userspace, and the
kernel task should be marked Invalid.
== Root cause ==
power-profiles-daemon 0.21-1ubuntu2 added
"After=multi-user.target display-manager.target" (LP: #2160748). Together with
oem-fix-misc-cnl-oobe-powerprofile-setup 0.3 that closes a job loop:
gdm.service
After= oem-powerprofile-performance-pre-setup.service
(which is WantedBy=display-manager.service)
oem-powerprofile-performance-pre-setup.service
After= power-profiles-daemon.service
power-profiles-daemon.service
After= multi-user.target, display-manager.target <-- new in 0.21-1ubuntu2
display-manager.target
reached via gdm.service <-- back to the start
systemd's cycle-breaking heuristic does not always resolve this. When it does
not, the job queue parks forever, plymouth keeps the KMS device, gdm never
starts, and you get the Dell splash + spinner while SSH stays up because
multi-user services are already running. Removing "quiet splash" takes plymouth
out of the picture so the stall is never visible - which is exactly the
workaround reported here.
== Evidence, captured mid-hang on 6.17.0-1032-oem ==
$ systemctl is-system-running
starting
$ systemctl list-jobs
165 plymouth-quit-wait.service start running
1 graphical.target start waiting
217 oem-powerprofile-performance-pre-setup.service start waiting
206 power-profiles-daemon.service start waiting
215 gdm.service start waiting
2 multi-user.target start waiting
$ sudo fuser -v /dev/dri/card1
root 340 F...m plymouthd
gdm is "waiting", never "activating" - a job-queue deadlock, not a hung device.
systemd names the cycle itself on other boots of this machine:
power-profiles-daemon.service: Found ordering cycle on multi-user.target/stop
power-profiles-daemon.service: Found dependency on
power-profiles-daemon.service/stop
power-profiles-daemon.service: Job multi-user.target/stop deleted to break
ordering cycle starting with
power-profiles-daemon.service/stop
== The failure is NOT kernel-correlated ==
Per-boot survey of the journal on this machine (did the boot reach
graphical.target?):
boot 0 6.17.0-1032-oem NO (hung)
boot -1 6.17.0-1017-oem NO (hung)
boot -2 6.17.0-1017-oem yes
boot -3 6.17.0-1017-oem yes
boot -4 6.17.0-1017-oem NO (hung)
boot -5 6.17.0-1017-oem yes
6.17.0-1017-oem - the "good" GM kernel - hangs too, 2 out of 5 boots. The
reported "3/3 on 1033, fine on 1017" is the nondeterminism of systemd's
cycle-breaking, not a kernel regression. Note also that
linux-image-6.17.0-1032-oem was only installed on 2026-08-29 06:35, while the
1017 hang above was recorded on 2026-08-28 11:30 - the failure predates the new
kernel on this box.
== Proof by fix ==
Masked only the OEM unit, changed nothing else, and rebooted into the same
6.17.0-1032-oem kernel with "quiet splash vt.handoff=7":
$ sudo systemctl mask oem-powerprofile-performance-pre-setup.service
$ # reboot
$ uname -r
6.17.0-1032-oem
$ systemctl is-system-running
running
$ systemctl list-jobs
No jobs running.
$ systemctl is-active gdm
active
The kernel that hung boots to desktop once the loop is broken. The machine has
since been restored (unit unmasked, default boot entry back to 1017).
== Ruled out ==
The obvious kernel suspect in the 1017..1033 delta was ab21cab8c7201
("x86/video: Only fall back to vga_default_device() without screen info").
It is innocent - on 1032 the primary display is detected correctly:
$ ls /sys/class/drm/card*/boot_display
/sys/class/drm/card1/boot_display
$ cat /sys/bus/pci/devices/0000:03:00.0/boot_vga
1
kernel: fbcon: amdgpudrmfb (fb0) is primary device
and amdgpu never resizes BAR0 here (firmware BAR0 0x8100000000-0x810fffffff is
unchanged in /proc/iomem), so the screen_info/BAR match cannot fail. BIOS 1.4.2
is not implicated either; the fault is entirely in userspace unit ordering.
== Suggested fix ==
In power-profiles-daemon, drop "display-manager.target" from After=. Ordering
after multi-user.target alone should satisfy LP: #2160748, and it is the
display-manager.target edge that closes the loop through gdm.
Alternatively, in oem-fix-misc-cnl-oobe-powerprofile-setup, drop
"After=power-profiles-daemon.service" - the daemon is Type=dbus, so the helper
script can simply make its D-Bus call and let ppd be activated on demand,
without a static ordering edge.
Workaround for any affected unit, kernel-independent:
sudo systemctl mask oem-powerprofile-performance-pre-setup.service
Note this affects every image carrying power-profiles-daemon 0.21-1ubuntu2
together with oem-fix-misc-cnl-oobe-powerprofile-setup, on any kernel, so
similar "stuck on splash but SSH works" reports may be filed against the
kernel when they are not kernel issues.
** Changed in: linux-oem-6.17 (Ubuntu)
Status: New => Invalid
** Changed in: power-profiles-daemon (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2165101
Title:
Dell Pro 15 Fails to boot into OS on 6.17.0-1033-oem kernel
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-oem-6.17/+bug/2165101/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
