%post CDS dump (-Xshare:dump) crashes with SIGABRT under rpm-ostree — blocks updates on atomic Fedora (Bazzite/Silverblu

[Samus1]

Hi,

I encountered an error following a recent update.
The following description was written by claude.ai using information from my system.
Claude suggests that I change to the portable file 'FileBot_<version>-portable.tar.xz' and stop layering FileBot.
There should be fewer caveats than with the Flatpak, but the lack of auto-update is a pity.

Analysis generated by claude.ai
The FileBot RPM fails during install/update on rpm-ostree based (atomic / immutable) Fedora systems. The package's %post script crashes and aborts the entire rpm-ostree transaction, which blocks every system update until FileBot is removed from the layer.

Environment
- OS: Bazzite stable (uBlue, Fedora-based, atomic / rpm-ostree)
- Install method: official FileBot RPM repo, layered via rpm-ostree
- FileBot version: filebot-5.2.1-amd64.x86_64

What happens
During `rpm-ostree upgrade` the post-install script fails:

Code: Select all

error: Running %post for filebot: bwrap(/bin/sh): child process exited with status 134; run `journalctl -t 'rpm-ostree(filebot.post)'` for more information

Status 134 = 128 + 6, i.e. the process is killed by SIGABRT. journalctl shows the offending command:

Code: Select all

/proc/self/fd/5: line 1: 3 Aborted (core dumped) /usr/share/filebot/jre/bin/java -Xshare:dump -XX:SharedClassListFile="/usr/share/filebot/jsa/classes.jsa.lst" -XX:SharedArchiveFile="/usr/share/filebot/jsa/classes.jsa" -jar "/usr/share/filebot/jar/filebot.jar" > "/usr/share/filebot/jsa/classes.jsa.log" 2>&1

Cause
rpm-ostree runs %post scripts inside a bubblewrap (bwrap) sandbox with a read-only /usr and a restricted environment. The AppCDS archive generation (`java -Xshare:dump`) aborts in that sandbox, the %post exits non-zero, and rpm-ostree rolls back the whole deployment. Since the CDS archive is only a startup optimization, the failure is harmless for functionality but fatal for the transaction.

Impact
This breaks all updates on any atomic rpm-ostree distro (Silverblue, Kinoite, Bazzite, Bluefin, Aurora, …), not just Bazzite. The only current workaround is:

Code: Select all

rpm-ostree upgrade --uninstall filebot

Suggested fix
Make the CDS dump in %post non-fatal and/or skip it in restricted/sandboxed environments, e.g.
- append `|| :` so a failed dump can't fail the script, and/or
- generate the AppCDS archive lazily on first launch instead of in %post, and/or
- detect a read-only /usr (or sandbox) and skip the dump there.

Thanks!

[rednoah]

The RPM install and post process is typically running as root so writing to /usr/share/filebot is not usually a problem. At this point, the [RPM] Fedora package is used by dnf and zypper. We have never tested with rpm-ostree but could look into it that is what is commonly used nowadays.

[Samus1]

Thank you for the fast reply.

I tested the portable package but it didn't include a Java runtime (java: command not found), so the GUI wouldn't start.

I'm now using distrobox (Fedora 42) with the RPM from the downloads page. There I ran into a Java/Swing reparenting issue (blank grey window under Wayland), which was solved with:

Shell: Select all

export _JAVA_AWT_WM_NONREPARENTING=1

FileBot didn't pick up the desktop scaling under Wayland, so I forced 2x manually:

Shell: Select all

export _JAVA_OPTIONS='-Dsun.java2d.uiScale=2'

Since this is the only app I run through distrobox, I added an update check to every program start. The extra startup time is negligible and it gives me the peace of mind that it's always up to date:

Shell: Select all

sudo dnf upgrade -y --refresh filebot >/dev/null 2>&1 || true

Works great now.

[rednoah]

Cheers! In the meanwhile, we have added a || true to that %post line to ensure a positive exit code even if CDS archive generation fails. The next public release / RPM is many months away though.