Public bug reported: SUMMARY / IMPACT: GDM and gnome-shell fail to start completely on every single attempt (fresh boot, warm reboot, cold power-cycle, manual gdm restart, or a plain user-session `gnome-shell --wayland` run) on an Intel-only (no NVIDIA/hybrid graphics) laptop. GDM crash-loops the greeter 3-6 times in a few seconds and then gives up, leaving the screen at a frozen cursor with no login prompt at all. 100% reproducible since first occurrence.
SYSTEM: - Ubuntu 26.04 LTS (Resolute Raccoon) - Hardware: Lenovo ThinkPad X1 Yoga Gen 7, Intel Alder Lake-UP3 GT2 Iris Xe Graphics (PCI ID 8086:46a8), kernel 7.0.0-27-generic - Only one GPU: /dev/dri/card1 (i915, card0 is the transient simpledrm boot-splash device, normal) - Package versions at time of report: gnome-shell 50.1-0ubuntu1.1 libmutter-18-0 / mutter-common 50.1-0ubuntu2.2 libgbm1 / mesa-libgallium / libegl-mesa0 / libgl1-mesa-dri / libglx-mesa0 26.0.3-1ubuntu1 gdm3 50.0-0ubuntu1 - All of the above were freshly reinstalled from the current archive (apt-get install --reinstall) shortly before this report; identical crash reproduced immediately afterward, ruling out local package corruption. EXACT ERROR (journalctl -b): Running GNOME Shell using mutter 50.1 as a Wayland display server Thread 'KMS thread' will be using high priority scheduling libmutter-WARNING **: Failed to open gpu '/dev/dri/card1': Failed to initialize render device for /dev/dri/card1: Failed to create gbm device: Invalid argument, EGLStream render device requires an EGL display Failed to setup: No GPUs found [email protected]: Failed with result 'protocol' GdmLocalDisplayFactory: maximum number of display failures reached. Giving up. (Note: the trailing "EGLStream render device requires an EGL display" / "Missing required EGLDevice extension EGL_EXT_device_drm" text changes depending on env vars but is just generic per-backend hint text mutter appends — this is NOT an NVIDIA/EGLStream system, confirmed no NVIDIA hardware, no EGLStream backend files present under /usr/lib/x86_64-linux-gnu/gbm/.) ROOT-CAUSE INVESTIGATION ALREADY DONE (gdb + strace), so triagers don't have to repeat this: - The DRM fd mutter passes into gbm_create_device() is valid and correctly opened (confirmed via gdb breakpoint on gbm_create_device, inspecting $rdi and /proc/PID/fdinfo/N: drm-driver=i915, real engine accounting). Not stale, not O_PATH, not wrong. - Inside gbm_create_device() itself (gdb `catch syscall`, single-stepping through the call): the function performs the SAME open+sysfs-read cycle 4 times in a row — openat("/dev/dri", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) followed by reads of /sys/devices/pci0000:00/0000:00:02.0/{uevent,vendor,device,subsystem_vendor,subsystem_device} (the GPU's own PCI attributes). Every read succeeds. No error path is ever hit. Yet after the 4th identical cycle the function still returns failure (EINVAL surfaces to the caller). - At no point does gbm_create_device() ever openat() an actual DRI driver .so (e.g. iris_dri.so / the libdril_dri.so shim) and at no point does any ioctl occur anywhere in the whole traced sequence — confirmed with both gdb syscall-catch and plain strace -f -e trace=openat,ioctl. The failure happens entirely in PCI-ID/driver-selection bookkeeping, before any hardware driver is ever loaded or touched. - A raw ctypes call to gbm_create_device() on the exact same /dev/dri/card1 fd, done independently as the regular user (not via mutter), succeeds fine — so this is not a universally broken gbm_create_device(), it only fails in mutter's specific calling context/flags. - sway (a separate minimal Wayland compositor using the same kernel/DRM/GBM stack) starts and renders perfectly on this same machine — proves the kernel driver, /dev/dri/card1, and the GBM/Mesa libraries themselves are healthy; the bug is isolated to this one code path. - Environment variable overrides tested, no effect on the core failure: MESA_LOADER_DRIVER_OVERRIDE=iris, LIBGL_ALWAYS_SOFTWARE=1, G_MESSAGES_DEBUG=all (no extra diagnostic output emitted around the failure at all). - Ruled out with direct evidence (not just untested): DRM-master lock held by another process (client list empty), kernel-level i915/drm errors (zero relevant kernel log lines at the exact failure timestamp), systemd sandboxing directives (DeviceAllow/PrivateDevices — none present in [email protected]), AppArmor unprivileged-userns restriction (zero unshare/setns/clone3(CLONE_NEWUSER) calls in strace), logind fd handoff via TakeDevice (zero SCM_RIGHTS messages on the session bus; TakeDevice is never even called), udev seat/device tagging (correct seat/master-of-seat/uaccess tags via udevadm), package file corruption (dpkg -V clean on all involved packages), dynamic-linker/dlopen issues (both libgallium-26.0.3-1ubuntu1.so and the DRI shim load fine standalone via ctypes.CDLL), and known bug LP #2104006 (libglapi.so.0 dlopen issue — not applicable, that file doesn't exist on this system and isn't referenced by any involved library). - Mesa debug output (MESA_DEBUG=1 EGL_LOG_LEVEL=debug LIBGL_DEBUG=verbose) shows: "libEGL debug: EGL user error 0x3001 (EGL_NOT_INITIALIZED) in eglInitialize: DRI2: failed to load driver", repeated across the 4 cycles — consistent with the gdb findings above (one cycle per renderer-backend attempt mutter tries: GBM, EGLStream, EGLDevice, final). STEPS TO REPRODUCE: 1. Boot this machine (or any Alder-Lake-iGPU-only machine with the above package versions). 2. GDM attempts to start the greeter session ([email protected]). 3. Observe crash-loop in journalctl -b as shown above; screen shows only a frozen cursor, no login screen ever appears. (Also reproducible without GDM at all: log in on a plain text getty and run `dbus-run-session gnome-shell --wayland` as a normal user — identical crash.) EXPECTED BEHAVIOR: gnome-shell/mutter successfully opens /dev/dri/card1 via GBM and starts normally, as it did on this same machine/package-set combination as recently as 2026-07-06 (last confirmed-working boot log shows "Added device '/dev/dri/card1' (i915) using atomic mode setting." / "Created gbm renderer"). ADDITIONAL NOTE FOR TRIAGE: Given that the failure is reproducibly inside gbm_create_device() itself (Mesa/libgbm1, not mutter's own source), this may need reassigning from mutter to the mesa source package once someone with mutter/mesa debug symbols can pin down which internal check inside gbm_create_device()'s driver-matching logic is rejecting this device after 4 identical successful sysfs reads. Happy to run further gdb/strace captures on request — this machine is currently kept in text-mode boot (systemctl default multi-user.target) specifically to keep it reachable for further diagnosis while this bug is open. ** Affects: mutter (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2160652 Title: gnome-shell/mutter 50.1 fails to start on Intel Alder Lake iGPU: gbm_create_device() returns EINVAL ("Failed to open gpu ... No GPUs found" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/2160652/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
