[bug]: Changes in HWE Ubuntu kernel makes AppImage installer to fail

[darksylinc]

Is there an existing issue for this problem?

• I have searched the existing issues

Install method

Invoke's Launcher

Operating system

Linux

GPU vendor

AMD (ROCm)

GPU model

Radeon R9700 AI Pro

GPU VRAM

32GB

Version number

6.16.6

Browser

No response

System Information

Kernel

6.17.0-40-generic

What happened

In Ubuntu 24.04 LTS, running the following:

sudo apt install --install-recommends linux-generic-hwe-24.04

Will update to Kernel 6.17.0-40-generic.

There is a security change in Kernel Policy:

sysctl kernel.apparmor_restrict_unprivileged_userns

# Prints:
kernel.apparmor_restrict_unprivileged_userns = 1

Where unprivileged user namespaces are intercepted by AppArmor. This will result in the error:

./"Invoke Community Edition.AppImage"
[4821:0717/181826.676343:FATAL:sandbox/linux/suid/client/setuid_sandbox_host.cc:169] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /tmp/.mount_InvokeY5aWbo/chrome-sandbox is owned by root and has mode 4755.
Trace/breakpoint trap
[0717/181826.697140:ERROR:base/i18n/icu_util.cc:224] Invalid file descriptor to ICU data received.

Running this command shows the security intercept:

sudo dmesg | grep DENIED

# Prints:
[  105.851953] audit: type=1400 audit(1784323097.624:182): apparmor="DENIED" operation="capable" class="cap" profile="unprivileged_userns" pid=4783 comm="invoke-communit" capability=21  capname="sys_admin"
[  114.894100] audit: type=1400 audit(1784323106.667:184): apparmor="DENIED" operation="capable" class="cap" profile="unprivileged_userns" pid=4828 comm="invoke-communit" capability=21  capname="sys_admin"

Workaround 1: Launch unsanboxed:

"./Invoke Community Edition.AppImage" --no-sandbox

Workaround 2: Disable the restriction globally

sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

Workaround 3: Create an apparmor profile

This is convoluted. Ask an LLM how to do it (you have to create a file in /etc/apparmor.d/home.username.AI.invokeai)

Proposed Solution

According to ChatGPT, the AppImage needs to be repackaged again with a newer version of Electron for a permanent fix. It seems like ChatGPT is very knowledgeable about this error.

What you expected to happen

The launcher to run successfully.

How to reproduce the problem

See "What happened" section.

Additional context

This bug seems to have been reported in #8269 but was closed due to inactivity.

However it seems the reporter didn't know why it failed. I just happened to upgrade from an ancient kernel to a new one from upstream, and the installer suddenly stopped working.

Discord username

No response

[Pfannkuchensack]

Thanks for the detailed write-up — the root-cause analysis here is spot on.

One clarification on the suggested fix: updating Electron will not resolve this. This isn't a bug in a specific Electron version — it's architectural. AppImages mount read-only, so the chrome-sandbox helper can't be installed SUID-root, which forces Chromium to fall back to the unprivileged user-namespace sandbox. Ubuntu 23.10+/24.04 then block that fallback via AppArmor (apparmor_restrict_unprivileged_userns=1). Every Electron version behaves identically here, including the latest releases, so repackaging with a newer Electron would leave the error unchanged.

There are two real fixes, both independent of the Electron version:

1. Disable the sandbox on Linux (--no-sandbox) — keeps the AppImage format and fixes it immediately, at the cost of the Chromium sandbox. Acceptable for the launcher, which only renders our own UI and the local InvokeAI web UI.

2. Ship a .deb/.rpm target — electron-builder installs a proper AppArmor profile automatically for these targets (since v26.0.0), preserving the full sandbox. AppImage has no install step, so it can't do this.

I will discuss with the team which path we will take.