AppImage fails on Fedora 44

[alametti]

Description

$ Downloads/rustfava_1.31.0_amd64.appimage
# Blank window appears with toolbar only
Could not create default EGL display: EGL_BAD_PARAMETER. Aborting...

$ LD_PRELOAD=/usr/lib64/libwayland-client.so Downloads/rustfava_1.31.0_amd64.appimage
# Splashcreen loads but cannot open ledger
# No error is logged in terminal

Steps to Reproduce

1. Launch AppImage with LD_PRELOAD to prevent OpenGL error
2. Open ledger
3. Error: "Failed to open file: Error: Server failed to start"

Rustfava Version

(no output)

Python Version

Python 3.14.7

Operating System

Linux

Additional Context

OS: Fedora Linux 44 (KDE Plasma Desktop Edition) x86_64
Kernel: Linux 7.1.8-200.fc44.x86_64

[robcohen]

Two distinct failures here, and it's worth separating them:

1. Could not create default EGL display: EGL_BAD_PARAMETER with a toolbar-only window — WebKitGTK failing to initialise its GPU compositing path.
2. With the LD_PRELOAD workaround, the splash renders but the ledger won't open, with nothing logged.

The first is a known WebKitGTK/Tauri interaction on newer Mesa and Wayland stacks rather than anything rustfava does. Worth trying, to confirm which layer is at fault:

WEBKIT_DISABLE_DMABUF_RENDERER=1 Downloads/rustfava_1.31.0_amd64.appimage
# and, separately
WEBKIT_DISABLE_COMPOSITING_MODE=1 Downloads/rustfava_1.31.0_amd64.appimage

If either produces a working window, that confirms the EGL/dmabuf path and points at a desktop/ launcher fix rather than an application one.

For the second: the "cannot open ledger" symptom on 1.31.0 could be a separate, already-fixed bug. v1.31.0 shipped on 2 July and is still the latest release, while several packaging fixes landed on main shortly after — including a missing dependency in the frozen sidecar that made the server fail on startup (#255 / #258). If the sidecar dies, the UI renders but no ledger loads, with nothing in the terminal.

Could you check whether anything appears in the sidecar's own output? If you can run the AppImage with --appimage-extract and start the bundled rustfava-server binary directly against your ledger, any traceback there would tell us quickly whether this is the same packaging gap or something new.

[robcohen]

Researched this properly. The AppImage forces X11 unconditionally, and at the tauri-cli version we ship you cannot override it from outside. That's very likely the first failure.

What's happening

Tauri builds AppImages with linuxdeploy plus a bundled GTK plugin. Line 187 of that script, at tauri-cli 2.11.2 (the version pinned in desktop/bun.lock):

export GDK_BACKEND=x11 # Crash with Wayland backend on Wayland - ... tauri-apps/tauri#8541

Unconditional. So on Fedora 44 under Wayland, the app is pushed through XWayland whether or not that works, and WebKit's EGL initialisation fails there — which is your Could not create default EGL display: EGL_BAD_PARAMETER and the toolbar-only window.

It also explains why your LD_PRELOAD of the host libwayland-client.so changed the behaviour: it perturbs which Wayland/EGL client code gets used inside that forced-X11 environment.

I checked whether upgrading fixes it. On Tauri's dev branch the line is now:

export GDK_BACKEND="${GDK_BACKEND:-x11}"

which at least respects a user-set value — but that is unreleased. I checked 2.11.2, 2.11.3 and 2.11.4 (the latest) and all three are still unconditional. So bumping the CLI does not currently help, and GDK_BACKEND=wayland ./rustfava.appimage will not work either, because AppRun overwrites it after your shell sets it.

Things worth trying, in order

1. Use the .rpm instead. This is the one I'd try first. The .deb/.rpm packages install a plain binary with a .desktop entry and have no AppRun wrapper, so nothing forces GDK_BACKEND. On Fedora that's the better-supported path anyway. If it works, that isolates the fault to the AppImage wrapper rather than the app.

2. If you want to stay on the AppImage, extract it and edit the forced line:

./rustfava_1.31.0_amd64.appimage --appimage-extract
sed -i 's/^export GDK_BACKEND=x11/export GDK_BACKEND="${GDK_BACKEND:-x11}"/' squashfs-root/AppRun
GDK_BACKEND=wayland ./squashfs-root/AppRun

3. Or keep X11 and disable WebKit's dmabuf path:

WEBKIT_DISABLE_DMABUF_RENDERER=1 ./rustfava_1.31.0_amd64.appimage

Your second symptom is probably a different, already-fixed bug

"Splash loads but cannot open ledger, nothing logged" reads like the sidecar dying at startup rather than a rendering problem. v1.31.0 shipped 2 July and remains the latest release, while a packaging fix landed 3 July — one day later — for a missing simplejson in the frozen sidecar that makes it die during import (#255, #258). A dead sidecar gives exactly this: UI renders, no ledger, nothing on the terminal.

From the extracted directory you can test that directly:

./squashfs-root/usr/bin/rustfava-server /path/to/your.beancount

If that prints ModuleNotFoundError: No module named 'simplejson', it's #255 and it's already fixed on main — it just needs a release.

Would you mind reporting back on (1) whether the .rpm works, and (2) what that server command prints? Those two answers separate the three candidate causes cleanly.

[robcohen]

v1.32.0 is out, which changes the picture for the second half of your report.

The "splash loads but cannot open ledger, nothing logged" symptom is very likely the sidecar dying at startup — v1.31.0 shipped a frozen sidecar missing simplejson, so it died during import and the UI rendered with no ledger and nothing on the terminal (#255, #258, both now closed). That fix is in 1.32.0, verified by running the released binary.

So worth retrying with 1.32.0 before we dig further. If the ledger opens, that half is solved and only the EGL issue remains.

The first half — EGL_BAD_PARAMETER and a toolbar-only window — I would not expect to change, because it is not rustfava's code. Tauri's AppImage wrapper hard-forces export GDK_BACKEND=x11 in its AppRun (unconditional at tauri-cli 2.11.2 through 2.11.4; only unreleased dev makes it overridable), so on Fedora 44 under Wayland the app is pushed through XWayland regardless and WebKit's EGL init fails there.

Still the same suggestions, in order:

1. Try the .rpm — .deb and .rpm install a plain binary with no AppRun wrapper, so nothing forces the backend. On Fedora that is the better-supported path anyway, and it isolates the fault to the AppImage wrapper.
2. Or extract the AppImage and relax the forced line, then run with GDK_BACKEND=wayland.
3. Or keep X11 and try WEBKIT_DISABLE_DMABUF_RENDERER=1.

Two answers would settle this quickly: does the 1.32.0 .rpm work, and if you still use the AppImage, does the ledger now open?

(Edited: the first version of this comment lost two package extensions to shell backtick expansion — the same bug I'd just fixed in the release bot's PR body. Restored above.)

[robcohen]

Reproduced both halves in a real Fedora 44 container, so this is now measured rather than inferred.

Your second symptom is solved by v1.32.0

Running the v1.31.0 AppImage's own bundled server on Fedora 44:

File "rustfava/core/charts.py", line 16, in <module>
ModuleNotFoundError: No module named 'simplejson'
[PYI-4:ERROR] Failed to execute script 'cli' due to unhandled exception!

That is exactly the bug from #255 — the frozen sidecar shipped without a dependency imported during startup. It explains "splash loads but cannot open ledger, nothing logged" precisely: the UI is a separate process and renders fine, the server dies before binding, and nothing reaches your terminal because the failure is inside the sidecar.

The v1.32.0 AppImage on the same container:

HTTP: 302
simplejson errors: 0

So upgrading fixes that half.

Your first symptom does NOT change in v1.32.0

I checked the shipped artifacts rather than the upstream source this time. Both AppImages carry, at apprun-hooks/linuxdeploy-plugin-gtk.sh line 9:

export GDK_BACKEND=x11 # Crash with Wayland backend on Wayland - ... tauri-apps/tauri#8541

Unconditional in both. Correcting my earlier comment: I said to patch AppRun, which was wrong — the line lives in apprun-hooks/, and a sed against AppRun would have silently done nothing.

I verified the override really is impossible, and that patching really does fix it:

	GDK_BACKEND ends as
unpatched, you set wayland	x11 — clobbered
patched, you set wayland	wayland
patched, you set nothing	x11 — default unchanged

So the corrected workaround is:

./rustfava_1.32.0_amd64.AppImage --appimage-extract
sed -i 's|^export GDK_BACKEND=x11|export GDK_BACKEND="${GDK_BACKEND:-x11}"|' \
  squashfs-root/apprun-hooks/linuxdeploy-plugin-gtk.sh
GDK_BACKEND=wayland ./squashfs-root/AppRun

The .rpm is the cleaner path, and I tested it

On Fedora 44:

• dnf install ./rustfava-1.32.0-1.x86_64.rpm — exit 0
• /usr/bin/rustfava-server serves HTTP 302, no simplejson error
• it forces no GDK_BACKEND at all — there is no AppRun wrapper, so nothing overrides your session

That last point is the reason to prefer it: the EGL failure comes from being pushed onto XWayland by the AppImage wrapper, and the rpm simply does not do that.

What I could not test

The EGL initialisation itself needs a real GPU and compositor, which a headless container does not have. So I have proven the mechanism (the backend is forced, you cannot override it, the rpm does not force it) but not that your specific window renders. If the rpm works for you, that confirms the whole chain.

Could you try the 1.32.0 .rpm? If it works, this is really two separate issues — one fixed, one an upstream Tauri constraint — and I would like to know which of the two remains before deciding whether to patch the AppImage in our build.

[robcohen]

Correcting myself: the GDK_BACKEND=x11 forcing is not your bug. Your LD_PRELOAD detail was the actual clue and I read past it twice.

This is a known upstream issue — tauri-apps/tauri#15665, open since July. linuxdeploy's dependency follower sweeps libwayland-client and the glib/gstreamer family into the AppImage, and its excludelist doesn't cover them (the pkg2appimage community excludelist does, with a comment that bundling libwayland breaks newer Mesa).

On Fedora 44 your Mesa 25 is newer than our Ubuntu build machine's, so the system EGL driver gets loaded against the bundled libwayland-client 1.22 — eglGetDisplay() returns EGL_BAD_PARAMETER and WebKitWebProcess aborts before any window appears.

Which is exactly why your LD_PRELOAD=/usr/lib64/libwayland-client.so changed the behaviour: you were displacing the bundled library with the host's. That was the diagnosis sitting in your first message.

I confirmed every library that issue names is in our AppImage — libwayland-client, libwayland-egl, the glib family, ten libgst*, libmount/libblkid/libselinux/libpcre2-8, libzstd/libelf/libffi, 29 files in all. (The issue's second mechanism, a stale GST_PLUGIN_SYSTEM_PATH, does not apply to us.)

#309 strips them at build time. Tested on a real Fedora 44 container: the repacked AppImage extracts and runs, and ldd reports zero missing libraries for both rustfava-desktop and the bundled libwebkit2gtk-4.1 — the system versions are drop-in, which is what makes removing them safe rather than reckless.

What I could not test is the EGL initialisation itself; that needs a real GPU and compositor, which a headless container hasn't got. So the mechanism is proven and the removal is proven safe, but you have the only machine that can confirm the actual fix.

Two things that would help, whenever convenient:

1. Does the 1.32.0 .rpm work? It bundles nothing, so it should sidestep this entirely — and it also carries the sidecar fix below.
2. When fix(desktop): strip over-bundled libraries from the AppImage #309 ships, does the new AppImage render?

And to close out the other half: I reproduced your "splash loads but cannot open ledger" symptom in the same container. The 1.31.0 AppImage's bundled server dies with ModuleNotFoundError: No module named 'simplejson' at charts.py:16; the 1.32.0 one serves HTTP 302. So that half is already fixed in the current release — it was a separate bug (#255), which is why the two symptoms behaved so differently.

[alametti]

Yes, the RPM works. There are other errors parsing the ledger but they seem unrelated to this issue.

[robcohen]

Ok thanks. Feel free to share the parsing errors you are seeing.