github-starred/firejail

Fork 0

mirror of https://github.com/netblue30/firejail.git synced 2026-05-15 14:16:14 -06:00

[GH-ISSUE #6833] Support AppImages using zstd compression #3388

New issue

Open

opened 2026-05-05 09:57:39 -06:00 by gitea-mirror · 3 comments

gitea-mirror commented

2026-05-05 09:57:39 -06:00

Owner

Originally created by @Eckoa on GitHub (Jul 21, 2025).
Original GitHub issue: https://github.com/netblue30/firejail/issues/6833

Description

Trying to run the latest RPCS3 appimage in firejail it fails to run with a mount failure. I looked at line 188 that the output said was the issue in appimage.c and realized that it was thinking its iso9660 and not squashfs. I double checked by extracting the appimage and it does in fact produce an squashfs-root

I havent found a way in the documentation/appimage.c to tell it the appimage type so i figured it would be best to report this here.

bash-5.2$ firejail --appimage rpcs3-v0.0.37-18022-9c93ec0b_linux64.AppImage
Reading profile /etc/firejail/rpcs3.profile
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-devel.inc
Reading profile /etc/firejail/disable-exec.inc
Reading profile /etc/firejail/disable-interpreters.inc
Reading profile /etc/firejail/disable-programs.inc
Reading profile /etc/firejail/disable-xdg.inc
Reading profile /etc/firejail/whitelist-common.inc
Reading profile /etc/firejail/whitelist-run-common.inc
Reading profile /etc/firejail/whitelist-runuser-common.inc
Reading profile /etc/firejail/whitelist-usr-share-common.inc
Reading profile /etc/firejail/whitelist-var-common.inc
firejail version 0.9.74

Parent pid 6630, child pid 6634

** Warning: dropping all Linux capabilities and setting NO_NEW_PRIVS prctl **

Mounting appimage type 1
Error ../../src/firejail/appimage.c:188: appimage_mount: mounting appimage: Invalid argument
Error: proc 6630 cannot sync with peer: unexpected EOF
Peer 6634 unexpectedly exited with status 1

Steps to Reproduce

run the latest RPCS3 appimage with the latest firejail

Expected behavior

application mounts and run

Actual behavior

fails to mount the appimage with invalid arguements

Behavior without a profile

produces the same output as above but without the profile loaded

Environment

Kernel: Linux 6.15.7-cachyos1.fc42.x86_64 x86_64
Linux distribution : Fedora 42
Name/version of the relevant program(s)/package(s) : rpcs3-v0.0.37-18022-9c93ec0b_linux64.AppImage
Version of Firejail: firejail version 0.9.74

Originally created by @Eckoa on GitHub (Jul 21, 2025). Original GitHub issue: https://github.com/netblue30/firejail/issues/6833 ### Description Trying to run the latest RPCS3 appimage in firejail it fails to run with a mount failure. I looked at line 188 that the output said was the issue in appimage.c and realized that it was thinking its iso9660 and not squashfs. I double checked by extracting the appimage and it does in fact produce an squashfs-root I havent found a way in the documentation/appimage.c to tell it the appimage type so i figured it would be best to report this here. ``` bash-5.2$ firejail --appimage rpcs3-v0.0.37-18022-9c93ec0b_linux64.AppImage Reading profile /etc/firejail/rpcs3.profile Reading profile /etc/firejail/disable-common.inc Reading profile /etc/firejail/disable-devel.inc Reading profile /etc/firejail/disable-exec.inc Reading profile /etc/firejail/disable-interpreters.inc Reading profile /etc/firejail/disable-programs.inc Reading profile /etc/firejail/disable-xdg.inc Reading profile /etc/firejail/whitelist-common.inc Reading profile /etc/firejail/whitelist-run-common.inc Reading profile /etc/firejail/whitelist-runuser-common.inc Reading profile /etc/firejail/whitelist-usr-share-common.inc Reading profile /etc/firejail/whitelist-var-common.inc firejail version 0.9.74 Parent pid 6630, child pid 6634 ** Warning: dropping all Linux capabilities and setting NO_NEW_PRIVS prctl ** Mounting appimage type 1 Error ../../src/firejail/appimage.c:188: appimage_mount: mounting appimage: Invalid argument Error: proc 6630 cannot sync with peer: unexpected EOF Peer 6634 unexpectedly exited with status 1 ``` ### Steps to Reproduce run the latest RPCS3 appimage with the latest firejail ### Expected behavior application mounts and run ### Actual behavior fails to mount the appimage with invalid arguements ### Behavior without a profile produces the same output as above but without the profile loaded ### Environment - Kernel: Linux 6.15.7-cachyos1.fc42.x86_64 x86_64 - Linux distribution : Fedora 42 - Name/version of the relevant program(s)/package(s) : rpcs3-v0.0.37-18022-9c93ec0b_linux64.AppImage - Version of Firejail: firejail version 0.9.74

gitea-mirror added the

enhancement

label 2026-05-05 09:57:39 -06:00

gitea-mirror commented

2026-05-05 09:57:41 -06:00

Author

Owner

@Eckoa commented on GitHub (Jul 21, 2025):

I had an idea of trying to repack RPCS3 and I figured out how to repackage the appimage

I think this isnt so much a firejail issue as an RPCS3 packaging issue. Repacking the appimage it runs just fine so if you would like ill close

EDIT: fouund the offending commit for RPCS3 235707278f

They changed how its built and use zstd compression. Im not sure what might be causing the issue with firejail here

@Eckoa commented on GitHub (Jul 21, 2025): I had an idea of trying to repack RPCS3 and I figured out how to repackage the appimage I think this isnt so much a firejail issue as an RPCS3 packaging issue. Repacking the appimage it runs just fine so if you would like ill close EDIT: fouund the offending commit for RPCS3 https://github.com/RPCS3/rpcs3/commit/235707278fb0126b32cb8892c98a9534c4e6dd1b They changed how its built and use zstd compression. Im not sure what might be causing the issue with firejail here

gitea-mirror commented

2026-05-05 09:57:41 -06:00

Author

Owner

@kmk3 commented on GitHub (Jul 22, 2025):

Thanks for reporting this.

I had an idea of trying to repack RPCS3 and I figured out how to repackage
the appimage

I think this isnt so much a firejail issue as an RPCS3 packaging issue.
Repacking the appimage it runs just fine so if you would like ill close

EDIT: fouund the offending commit for RPCS3
RPCS3/rpcs3@2357072

They changed how its built and use zstd compression. Im not sure what might
be causing the issue with firejail here

bash-5.2$ firejail --appimage rpcs3-v0.0.37-18022-9c93ec0b_linux64.AppImage
[...]
Mounting appimage type 1
Error ../../src/firejail/appimage.c:188: appimage_mount: mounting appimage: Invalid argument
Error: proc 6630 cannot sync with peer: unexpected EOF
Peer 6634 unexpectedly exited with status 1

The error is from L188 (type 1, iso9660):

https://github.com/netblue30/firejail/blob/3f2f2018364a05320cf551e8178cd929f3cadbb6/src/firejail/appimage.c#L173-L196

From a quick glance, the code seems to look for an LZMA header to determine the
size / offset to then determine the appimage type:

So yes, the issue might be to be due to it using zstd compression.

Is this only done for RPSC3 or are there more appimages using zstd compresion?

There is likely a better way to determine the appimage type, but I'm not
familiar with this code.

For now, I agree that repackaging it to use a more commonly-supported
compression format would be a good idea for the sake of backwards
compatibility/wider tooling support, especially if the file size difference is
not that significant from the user's perspective.

For the long-term, it might be good support appimages with different types of
compression, so leaving this as an enhancement.

These seem to be related:

@kmk3 commented on GitHub (Jul 22, 2025): Thanks for reporting this. > I had an idea of trying to repack RPCS3 and I figured out how to repackage > the appimage > > I think this isnt so much a firejail issue as an RPCS3 packaging issue. > Repacking the appimage it runs just fine so if you would like ill close > > EDIT: fouund the offending commit for RPCS3 > [RPCS3/rpcs3@2357072](https://github.com/RPCS3/rpcs3/commit/235707278fb0126b32cb8892c98a9534c4e6dd1b) > > They changed how its built and use zstd compression. Im not sure what might > be causing the issue with firejail here > ``` > bash-5.2$ firejail --appimage rpcs3-v0.0.37-18022-9c93ec0b_linux64.AppImage > [...] > Mounting appimage type 1 > Error ../../src/firejail/appimage.c:188: appimage_mount: mounting appimage: Invalid argument > Error: proc 6630 cannot sync with peer: unexpected EOF > Peer 6634 unexpectedly exited with status 1 > ``` The error is from L188 (type 1, iso9660): * <https://github.com/netblue30/firejail/blob/3f2f2018364a05320cf551e8178cd929f3cadbb6/src/firejail/appimage.c#L173-L196> From a quick glance, the code seems to look for an LZMA header to determine the `size` / offset to then determine the appimage type: * <https://github.com/netblue30/firejail/blob/3f2f2018364a05320cf551e8178cd929f3cadbb6/src/firejail/appimage.c#L102-L106> * <https://github.com/netblue30/firejail/blob/3f2f2018364a05320cf551e8178cd929f3cadbb6/src/firejail/appimage_size.c#L164-L172> So yes, the issue might be to be due to it using zstd compression. Is this only done for RPSC3 or are there more appimages using zstd compresion? There is likely a better way to determine the appimage type, but I'm not familiar with this code. For now, I agree that repackaging it to use a more commonly-supported compression format would be a good idea for the sake of backwards compatibility/wider tooling support, especially if the file size difference is not that significant from the user's perspective. For the long-term, it might be good support appimages with different types of compression, so leaving this as an enhancement. These seem to be related: * <https://github.com/AppImage/AppImageKit/issues/478> * <https://github.com/AppImageCommunity/libappimage/pull/158>

gitea-mirror commented

2026-05-05 09:57:42 -06:00

Author

Owner

@Eckoa commented on GitHub (Jul 22, 2025):

So yes, the issue might be to be due to it using zstd compression.

Is this only done for RPSC3 or are there more appimages using zstd compresion?

I havent encountered any other appimages using it yet but I generally don't use many so I can't say how many do. I'm sure more may adopt it in the future for the space savings like RPCS3

@Eckoa commented on GitHub (Jul 22, 2025): > So yes, the issue might be to be due to it using zstd compression. > > Is this only done for RPSC3 or are there more appimages using zstd compresion? I havent encountered any other appimages using it yet but I generally don't use many so I can't say how many do. I'm sure more may adopt it in the future for the space savings like RPCS3

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#3388

No description provided.

Rows
Columns