Tiny Core Linux
General TC => General TC Talk => Topic started by: GNUser on December 11, 2025, 02:21:00 PM
-
Every now and then there is an interesting application that I would like to try which is available for linux only as source code or flatpak. I don't have a specific application in mind at the moment but it happens often enough.
Would a flatpak extension add value to TCL x86_64? I'm not sure--maybe it is philosophically incompatible with TCL principles (too complex, with too many hooks into dbus +/- gnome-things)?
I'd be interested in knowing what the TCL developers and other users think about this. I don't want to put in the work of creating a flatpak.tcz (or requesting it if my efforts lead to a dead end) if it's not a good fit for our favorite OS.
-
It seems a TCL extension and a flatpak are antithetical in every possible way. I think I've answered my own question. Sorry for the noise.
-
i for one would like your answer to be more concrete. is it just the dbus things? or what exactly? i have never looked deeply what dependencies there are for flatpak.
-
is it just the dbus things? or what exactly?
Hi hiro. I'm not sure but I will investigate and will get back to you.
-
Hi hiro. It seems flatpak is heavily dependent on dbus but not on systemd or other "gnome things".
I almost have it working in TCL with a binary-only extension (built from borrowed binaries and libraries from Devuan), but I don't know enough about dbus to get it quite right:
$ tce-load -i flatpak
$ sudo /usr/local/etc/init.d/dbus start
starting dbus daemon...
$ flatpak remote-add flathub https://flathub.org/repo/flathub.flatpakrepo
Note that the directories
'/var/lib/flatpak/exports/share'
'/home/bruno/.local/share/flatpak/exports/share'
are not in the search path set by the XDG_DATA_DIRS environment variable, so applications installed by Flatpak may not appear on your desktop until the session is restarted.
error: Rejected send message, 1 matched rules; type="method_call", sender=":1.2" (uid=1000 pid=12259 comm="flatpak remote-add flathub https://flathub.org/rep")
interface="org.freedesktop.Flatpak.SystemHelper" member="EnsureRepo" error name="(unset)" requested_reply="0" destination="org.freedesktop.Flatpak.SystemHelper" (bus)
It seems flatpak-system-helper is important, so let's try to run it:
$ sudo /usr/libexec/flatpak-system-helper
(/usr/libexec/flatpak-system-helper:11896): GLib-GIO-WARNING **: 08:36:06.570: Unexpected reply 2 when releasing name org.freedesktop.Flatpak.SystemHelper
If someone knowledgeable about dbus can give me a hand, I would be happy to proceed--the goal being to submit a binary-only flatpak extension for the x86_64 repo. Otherwise, dbus and flatpak-system-helper have stopped me dead in my tracks.
-
I got it to work, hiro. In Devuan, flatpak works as regular user with window popup asking for root password to elevate privileges when adding a channel or installing an app. In TCL, no such window appears, so I need to use sudo at the command line:
This works:
$ tce-load -i flatpak
$ sudo /usr/local/etc/init.d/dbus start
starting dbus daemon...
$ sudo flatpak remote-add flathub https://flathub.org/repo/flathub.flatpakrepo
$ sudo flatpak install foo
I'm going to add some polish to this then submit it for the x86_64 repo.
P.S. I don't particularly like portable package formats but I can imagine situations in which they may have some utility (e.g., trying an application's flatpak to see if I like the application, prior to creating a proper TCL extension of that application).
-
I got it to work, hiro.
Scratch that. Everything works until I try to run an installed application:
$ flatpak run org.gnome.Recipes
Note that the directories
'/var/lib/flatpak/exports/share'
'/home/bruno/.local/share/flatpak/exports/share'
are not in the search path set by the XDG_DATA_DIRS environment variable, so
applications installed by Flatpak may not appear on your desktop until the
session is restarted.
bwrap: pivot_root: Invalid argument
error: ldconfig failed, exit status 256
It seems Juanito bumped into this same error 8 years ago: https://github.com/containers/bubblewrap/issues/214
Juanito, did you ever find a solution for this "pivot_root: Invalid argument" error?
-
Juanito, did you ever find a solution for this "pivot_root: Invalid argument" error?
It seems this error may have something to do with the fact that TCL's root filesystem is an initramfs:
https://unix.stackexchange.com/questions/455223/pivot-root-from-initramfs-to-new-root-error-invalid-argument
If this is the case, it may be tough to get flatpak to work on TCL. Either we'd need to bypass bwrap's pivot_root or else create a wrapper script for bwrap that does some kind of hack.
-
Now I'm motivated to solve this, even if I never use flatpak on TCL ::)
hiro, here is a simple way to reproduce the problem on TCL16 x86_64:
$ tce-load -wi bwrap
$ bwrap --bind / / true
bwrap: pivot_root: Invalid argumentIf someone can help me find a fix or workaround for this error, I should be able to package flatpak for TCL.
-
Juanito, did you ever find a solution for this "pivot_root: Invalid argument" error?
Sorry, no :(
-
Thanks, Juanito. Good to know.
I've learned the hard way that flatpak and other sandboxed applications (e.g., nix package manager with default configuration) were designed under the assumption that they are running inside a "real" root filesystem.
TCL, on the other hand, is (beautifully and cleverly) designed to stay at the initramfs stage of the boot process, where it runs from RAM without ever pivoting to a mounted filesystem.
It seems to bridge this gap we'd need either a complex userland hack or a kernel patch:
https://lore.kernel.org/all/20210914170933.1922584-2-graham@determinate.systems/T/#m433939dc30c753176404792628b9bcd64d05ed7b
The complication is just not worth it. This is the end of my flatpak explorations.
P.S. The more I learn, the more I appreciate TCL's minimalistic approach to everything, including package management. :-* TCL
-
thanks for your investigation, i'll try to look what bwrap is all about, if i ever get some time :D
i use chroot+namespaces directly on tcl bec. it was easier for me, less than 10lines of shell iirc ;)
-
thanks for your investigation
Hi hiro. You're welcome. Thanks for the kick in the pants to be more specific about what "things" are required :)
If you discover anything interesting about bwrap + TCL, please do share.
Here are the portable package formats I've tried on TCL and whether they worked or not, in case it's helpful to others:
==========
Snaps: No (systemd) *
Flatpak: No (bwrap doesn't like initramfs root)
AppImage: Yes **
nix package manager: Yes ***
==========
* If not a hard dependency on systemd, it needs more than Devuan's systemd shims provide and is banned from Devuan for this reason. See https://pkgmaster.devuan.org/bannedpackages.txt
** Most AppImages work fine, but they all need fuse.tcz plus one or more of these:
$ sudo ln -s /usr/local/etc/fonts /etc/fonts
$ sudo ln -s /usr/local/etc/ssl /etc/ssl
$ sudo ln -s /lib /lib64
$ tce-load -wi bash
*** I only tested the single-user installation (see https://nixos.org/download). There are several caveats to using it on TCL:
1. sandboxing needs to be off: $ sudo mkdir /etc/nix; sudo sh -c "echo 'sandbox = false' >/etc/nix/nix.conf"
2. GNU cp is needed: $ tce-load -wi coreutils
3. Over 80,000 files are placed in user's home directory just for initial setup, before even a single package is installed!
Bottomline for me is that 95% of the software on my daily driver are official TCL extensions, 5% are AppImages. Things will remain this way.
-
"3. Over 80,000 files are placed in user's home directory just for initial setup, before even a single package is installed!" hahahahaha
might be easiest to fork flatpak/bwrap, replace pivot with chroot and make it work that way.
-
Hi GNUser
With regard to pivot_root , maybe try the noembed boot code? Found here:
https://forum.tinycorelinux.net/index.php/topic,22443.msg140629.html#msg140629
-
maybe try the noembed boot code?
Hi Rich. YES! That was the missing piece of the puzzle! :o I've always known you are a wizard in disguise!
I've been trying to create a flatpak extension for TCL off and on since 2020 (see https://forum.tinycorelinux.net/index.php/topic,23848.0.html). Well, here we are 5 years later and I think it will finally happen. Better late than never :)
-
flatpak submitted for TCL16 x86_64 :)
-
Hi Rich. Is there a way to use a startup script (e.g., /usr/local/tce.installed/flatpak) to achieve the same end result as booting with the noembed boot code? I will also be looking into this.
EDIT: I see that the noembed boot code is handled by /init
-
Hi Rich. Is there a way to use a startup script (e.g., /usr/local/tce.installed/flatpak) to achieve the same end result as booting with the noembed boot code? I will also be looking into this.
EDIT: I see that the noembed boot code is handled by /init
Never mind, Rich. /init takes care of this before /sbin/init even runs. I doubt it is possible to do this after system is up and running and, even if it were possible, I don't think this is something that an application's startup script should be doing without user being aware.
In flatpak's .info file I will note that the noembed boot code is required.
Thank you so much for suggesting this boot code. Thread may be marked as Solved! :)
-
Hi GNUser
You might be able to switch_root with a running system, but I
suspect it might not be safe to do.
... Thread may be marked as Solved! :)
So marked. ;D
-
nice, GNUser :D
-
nice, GNUser :D
Hi hiro. Enjoy!
While I'm here, let me point out two issues I've encountered when playing around with flatpak:
1. /var/local/lib/flatpak/repo: No such file or directory
Some flatpaks (e.g., com.google.Chrome) fail like this:
$ flatpak --user run com.google.Chrome
...
error: While opening repository /var/local/lib/flatpak/repo: opening repo: opendir(/var/local/lib/flatpak/repo): No such file or directoryWhen run with the --user flag, flatpak should not be mucking around in /var (its root dir should be $HOME/.local/share/flatpak, not /var/local/lib/flatpak). The solution for this kind of naughty behavior is simple:
$ mkdir -p /var/local/lib; ln -s $HOME/.local/share/flatpak /var/local/lib/flatpak; flatpak --user run com.google.Chrome
2. No sound
Flatpak requires pulseaudio for sound. If you are an alsa purist like me, your terminal may show errors like this when a flatpak tries to output sound:
ALSA lib ../../pulse/pulse.c:242:(pulse_connect) PulseAudio: Unable to connect: Connection refused
If alsa is properly configured, it is trivial to temporarily use pulseaudio:
$ tce-load -wil pulseaudio; sudo /usr/local/etc/init.d/dbus start; pulseaudio 2>/dev/null &
[Edit]: Fixed typo. Changed puseaudio to pulseaudio. Rich
-
Hi Rich. Can you please fix the typo in the last command above? I'd fix it myself but the forum won't let me any more (the timeout for allowing edits is very short--it would be nice if the timeout were longer). It should be pulseaudio in the command, of course, not puseaudio. Then please feel free to delete this post.
-
Hi GNUser
Typo fixed. :)