Bug 2513853

On first boot of the Fedora 45 Xfce spin on a Raspberry Pi 4, initial-setup launches Weston 15.0.1 as the Wayland compositor for the first-boot GUI wizard. Weston fails to open any input devices, attempts to shut down, and crashes with SIGSEGV during Mesa/Gallium context teardown.

After the crash, initial-setup disables itself and falls through to LightDM, so the system does eventually reach a usable login screen, but the first-boot setup wizard is skipped entirely.

Since initial-setup is skipped there is no user created and there is no way to login. The only workaround is to create boot device with arm_image installer `--norootpass` CLI option which would create root user with empty password.

Reproducible: Always

Steps to Reproduce:
1. Write Fedora 45 Xfce aarch64 image to an SD card
2. Boot on a Raspberry Pi 4 Model B
3. The initial-setup service starts and launches Weston
4. Weston crashes, no initial user is created and login screen is displayed
Actual Results:
Attaching complete boot log.

Weston logs:
[00:02:01.233] warning: no input devices on entering Weston. Possible causes:
        - no permissions to read /dev/input/event*
        - seats misconfigured (Weston backend option 'seat', udev device property ID_SEAT)
[00:02:01.233] failed to create input devices
[00:02:01.237] fatal: failed to create compositor backend

Weston then terminates with signal 11/SEGV. Core dump stack trace:

Stack trace of thread 989:
#0  0x0000000000000070 n/a (n/a + 0x0)
#1  0x0000ffffa9383e40 u_transfer_helper_transfer_unmap (libgallium-26.2.0.so + 0xeb3e40)
#2  0x0000aaaafcd867d0 n/a (n/a + 0x0)
#3  0x0000aaaafcd867d0 n/a (n/a + 0x0)
#4  0x0000ffffa86003b8 st_destroy_context_priv (libgallium-26.2.0.so + 0x1303b8)

Expected Results:
Either:
- Weston should have permission to access input devices when launched by initial-setup, or
- Weston should shut down gracefully without crashing when input devices are unavailable

Additional Information:
Analysis
There are two bugs here:

1. Permission/seat configuration issue: Weston is launched by initial-setup as root (UID 0, session 4) on /dev/tty7 via libseat/logind, but none of the 9 input devices are accepted. Weston logs not using input device for every /dev/input/event*. This suggests a seat assignment or udev rule mismatch -- the devices may not be assigned to the seat Weston is using.

2. Mesa crash on teardown: When Weston fails and attempts to tear down its GL context, Mesa's Gallium state tracker dereferences a null pointer in u_transfer_helper_transfer_unmap() called from st_destroy_context_priv(). This is a Mesa bug -- context destruction should not crash even if initialization was incomplete.

System Information
- Hardware: Raspberry Pi 4 Model B Rev 1.5 (BCM2711, 4GB)
- Kernel: 7.2.0-0.rc6.260806g0d8395707651.51.fc45.aarch64
- systemd: 261.2-1.fc45
- Weston: 15.0.1-3.fc45
- Mesa: 26.2.0-1.fc45 (libgallium, V3D 4.2.14.0 via vc4-drm)
- libseat: seatd-0.9.3-2.fc45 (using logind backend)
- LightDM: display manager (works fine after Weston crash)
- EGL: Mesa 1.5, GL ES 3.1, GL renderer V3D 4.2.14.0
- U-Boot BIOS: 2026.10-rc1
- RPi firmware: 2026-07-23

Additional Notes
- Weston successfully opens /dev/dri/card2 (vc4), initializes the GL renderer with Mesa 26.2.0, and sets up the DRM backend with atomic modesetting before the input device failure occurs.
- The crash happens during teardown, not during initialization. The null deref in Mesa st_destroy_context_priv suggests the Gallium context was partially initialized when Weston called the cleanup path.