Warp fails to launch on Raspberry Pi (Ubuntu 26.04)

[ninbura]

Pre-submit Checks

• I have searched Warp bugs and there are no duplicates
• I have searched Warp known issues page and my issue is not there
• I have an issue with AI and have included the debugging ID (Optional, but helps expedite the AI quality fix). Debugging ID instructions
• I have technical issue and have included the logs (optional, but helps expedite the bug fix). Log instructions

Describe the bug

Warp fails to launch on my Raspberry Pi 5 16GB running Ubuntu 26.04.

To reproduce

Install Warp on a Raspberry Pi running Ubuntu 25.10+, and launch it.

Expected behavior

Warp launches as normal.

Screenshots, videos, and logs

No response

Operating system (OS)

Linux

Operating system and version

Ubuntu 26.04

Shell Version

GNU bash, version 5.3.9(1)-release (aarch64-unknown-linux-gnu)

Current Warp version

v0.2026.05.06.15.42.stable_03

Regression

Yes, this bug started recently or with an X Warp version

Recent working Warp date

March 2026

Additional context

I had the flickering issue when running Ubuntu 24.06, after upgrading the OS on my Pi to Ubuntu 25.10 that ceased to occur as reported here.

However at some point in March or April Warp started crashing as I would launch it, this was still on Ubuntu 25.10. Today I decided to upgrade to Ubuntu 26.04, in hopes that that may fix the issue, but it's still concurring.

The WGPU_BACKEND=gl warp-terminal workaround works on my Pi running Ubuntu 26.04, but a workaround on a popular PC with a popular operating system to launch Warp ideally shouldn't be required.

Does this block you from using Warp daily?

No

Is this an issue only in Warp?

Yes, I confirmed that this only happens in Warp, not other terminals.

Warp Internal (ignore): linear-label:b9d78064-c89e-4973-b153-5178a31ee54e

None

[oz-for-oss]

@ninbura

Here's what I found while triaging this issue:

The WGPU_BACKEND=gl workaround strongly suggests the crash is in Warp's default Linux GPU rendering/backend path rather than shell startup. This is being routed as a Linux GPU startup regression; diagnostics from the failing default launch will help confirm whether Vulkan/Mesa/V3DV is the failing path.

I have a few follow-up questions before I can narrow this down:

1. Could you run warp-terminal --dump-debug-info on the Pi and attach the output?
2. Could you run the failing launch without WGPU_BACKEND=gl using RUST_LOG=wgpu_core=info,wgpu_hal=info MESA_DEBUG=1 EGL_LOG_LEVEL=debug warp-terminal and attach the redacted terminal output or latest Warp log entries from that attempt?

Reply in-thread with those details and the triage workflow will automatically re-evaluate the issue and update the diagnosis, labels, and next steps.

Maintainer details

I concluded that warp launch crash on Raspberry Pi 5 appears to be a Linux GPU-backend regression where the default wgpu/Vulkan path fails but forcing OpenGL works..

Initial triage

• The report is a Linux startup/rendering regression on Raspberry Pi 5/aarch64: Warp stable v0.2026.05.06.15.42.stable_03 crashes on launch on Ubuntu 25.10/26.04, while WGPU_BACKEND=gl warp-terminal launches.
• This points to the default wgpu GPU-backend path rather than shell startup. In the current code, Warp enables wgpu's configured backends and, on non-Windows platforms, prioritizes Vulkan ahead of GL before validating adapters and configuring the surface.
• Existing adapter stability checks cover older lavapipe, Intel UHD, and NVIDIA cases, but I did not find a Raspberry Pi/Mesa V3DV-specific fallback or downrank. The GL workaround therefore makes a Vulkan/Mesa/V3DV startup or surface configuration failure the leading hypothesis, but confidence is low until logs identify the failing call.
• Duplicate scan checked all open non-PR issues plus recently closed issues from the last 7 days. Related issues include Window flickering with Vulkan V3DV Mesa driver #4879 and Reduce / Remove flicker on raspberry pi 5 with Ubuntu 24 LTS #7088 for Raspberry Pi/Vulkan flickering and Warp crashes at launch (BEX64 c0000409, offset 0x127125d) on AMD graphics; works when WGPU_BACKEND=gl #7409/Not open (Linux, Pop-OS, NVIDIA) #4275 for other GPU launch failures, but I did not find two existing issues with the same Raspberry Pi launch-crash symptom, so this should not be marked duplicate yet.

Likely owner area: Linux UI framework / GPU rendering. Relevant code paths include crates/warpui/src/rendering/wgpu/mod.rs, crates/warpui/src/rendering/wgpu/resources.rs, crates/warpui/src/windowing/winit/app.rs, crates/warpui/src/windowing/winit/window.rs, and the diagnostic path in app/src/debug_dump.rs.

Requested diagnostics below should be enough to distinguish a Vulkan adapter/device failure from surface/windowing or first-frame presentation failure.

Question reasoning

1. Could you run warp-terminal --dump-debug-info on the Pi and attach the output? — That diagnostic path reports the active windowing system, configured GPU backend preference, available wgpu adapters, and Linux GPU/EGL/Vulkan details that are needed to identify the selected Raspberry Pi driver/backend.
2. Could you run the failing launch without WGPU_BACKEND=gl using RUST_LOG=wgpu_core=info,wgpu_hal=info MESA_DEBUG=1 EGL_LOG_LEVEL=debug warp-terminal and attach the redacted terminal output or latest Warp log entries from that attempt? — The report confirms the GL workaround, but the default-path wgpu/Mesa logs are needed to locate whether the crash happens during adapter selection, device creation, surface configuration, or presentation.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[acarl005]

Hi @ninbura thanks for filing the issue. As the bot has requested, can you run warp-terminal --dump-debug-info on your pi and post the output here? Can you also try running Warp with WGPU_BACKEND=gl warp-terminal to see if it starts up without crashing?

[acarl005]

I believe this will be fixed in next week's release. If it isn't please re-open the issue.