Skip to content

Pipali not launching on Linux #14

@FroogalTheDragon

Description

@FroogalTheDragon

I'm having an issue with Pipali when I go to launch the AppImage it gets stuck at the loading screen. I have tried diving deep into this issue and here is what I have found:

First what's the expected behavior?
Pipali is supposed to open a loading animation while it loads and after a few seconds a screen that says "Loading" may appear and then the Pipali AI chat window should open, allowing the user to prompt Pipali.

What happens instead?
Pipali hangs on the loading screen and never fully loads.

What's the catch?
The server can be ran manually and it makes the app load to the prompt screen.

What have I tried?
I have tried using Claude to help me debug this application as I have never worked with bun before. I ran two different attempt with Claude and both of them pointed in the same direation.

Here is Claude's theory:

Bun runtime is downloaded and copied to src-tauri/binaries/bun-x86_64-unknown-linux-gnu
Tauri compiles the Rust app and assembles an AppDir
Tauri calls linuxdeploy to bundle GTK and system libraries into the AppDir
linuxdeploy calls the GTK plugin (linuxdeploy-plugin-gtk.sh) as part of this process
The GTK plugin does two things that corrupt Bun:

linuxdeploy itself scans all ELF binaries in usr/bin, patches their rpath to $ORIGIN, and bundles their library dependencies — this breaks Bun because Bun only needs basic system libs (libc, libpthread, etc.) and having its rpath patched causes it to load wrong/bundled versions
The webkit sed at the bottom of the plugin runs find "$APPDIR"/usr/lib* -name 'libwebkit*' -exec sed -i -e "s|/usr|././|g" — this was matching Bun and replacing every /usr string inside the binary with ././, completely corrupting it


The corrupted Bun is packaged into the AppImage
At runtime, Tauri spawns Bun as the sidecar → immediate segfault

The output of running the AppImage is:

[2026-03-04T01:17:45Z INFO  pipali] [App] Splash window should be visible
[2026-03-04T01:17:45Z INFO  pipali] [Sidecar] Server directory: "/tmp/.mount_PipaliEoaJHG/usr/lib/Pipali/resources/server"
[2026-03-04T01:17:45Z INFO  pipali] [Sidecar] Starting on 127.0.0.1:6464...
[2026-03-04T01:17:45Z INFO  pipali] [Sidecar] Data directory: "/home/awesomepilot/.local/share/ai.pipali"
[2026-03-04T01:17:45Z INFO  pipali] [Sidecar] Process spawned, waiting for server to be ready...
[2026-03-04T01:17:45Z INFO  pipali] [App] Global shortcut Alt+Space registered
[2026-03-04T01:17:45Z INFO  pipali] [Sidecar] Terminated with code: None, signal: Some(11)
[2026-03-04T01:17:45Z INFO  pipali] [Updater] No updates available
[2026-03-04T01:17:54Z ERROR pipali] Sidecar not ready: Sidecar failed to become ready within timeout
[2026-03-04T01:17:54Z INFO  pipali] [App] Emitting sidecar-ready event
[2026-03-04T01:17:54Z INFO  pipali] [App] Server ready, triggering splash animation
[2026-03-04T01:17:56Z INFO  pipali] [App] Splash window closed
[2026-03-04T01:17:56Z INFO  pipali] [App] Main window shown

The Sidecar does exit with Some(11)

I have used ./Pipali*.AppImage --appimage-extract to get a squashfs-root directory and I go to squashfs-root/usr/bin/ where there is the bun executable and I run ./bun --version and I do get a seg fault core dumped error.

I can run the on in ./src-tauri/binaries/bun-x86_64-unknown-linux-gnu --version works fine. So good binary go in, bad binary come out?

Claude points to the script in scripts/linux/linuxdeploy-plugin-gtk.sh at the patch here:

# PATCH: Move statically-linked binaries out of AppDir before linuxdeploy scans
# usr/bin/. linuxdeploy runs `ldd` on every binary and crashes (std::runtime_error)
# when ldd returns exit code 1 on static binaries. We move them out, let linuxdeploy
# run on only dynamic binaries, then restore them.
STATIC_BACKUP="/tmp/linuxdeploy-static-backup-$$"
mkdir -p "$STATIC_BACKUP"
while IFS= read -r -d '' file; do
    if ! ldd "$file" > /dev/null 2>&1; then
        echo "Temporarily moving static binary out of AppDir: $(basename "$file")"
        mv "$file" "$STATIC_BACKUP/"
    fi
done < <(find "$APPDIR/usr/bin" -executable -type f -print0)

env LINUXDEPLOY_PLUGIN_MODE=1 "$LINUXDEPLOY" --appdir="$APPDIR" "${LIBRARIES[@]}"

# PATCH: Restore statically-linked binaries
if [ -d "$STATIC_BACKUP" ] && [ "$(ls -A "$STATIC_BACKUP")" ]; then
    echo "Restoring statically-linked binaries to AppDir"
    cp -a "$STATIC_BACKUP"/* "$APPDIR/usr/bin/"
    rm -rf "$STATIC_BACKUP"
fi

which looks like it moves these binaries out before linuxdeploy mangles them, but it doesn't seem to be working. I have gone through several iteration of this function with Claude but I need to learn more about what is going on in this script. I'm not familiar with a bun + tauri configuration.

Let me know if this seems like the right direction!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions