Flatpak integration in Qubes OS templates

You would need to install flatpak first , with :

apt install flatpak 
2 Likes

that did it, thanks :heart_eyes:

The flatpak apps are not getting updated with the Qubes Update utility. I think the Flatpak update process gets forcefully terminated when the Qubes Update completes, which then triggers the template shutdown.

I manually executed /etc/qubes/post-install.d/05-flatpak-update.sh and it is executable. It works fine and instantly starts updating the apps. However, this is not happening when using the Qubes Update tool.

Is there a way for the script to deny the shutdown command triggered by the Qubes Update utility if an update is underway, and shut down the template only after the Flatpak updates are complete?

BTW, is there a way to confirm if the script /etc/qubes/post-install.d/05-flatpak-update.sh is actually executing with the Qubes Update utility?

I tried to modify the script as follows:

#!/bin/sh

LOGFILE=/var/log/qubes-post-install.log

echo "=== $(date) : script started ===" >> "$LOGFILE"

if [ "$(qubesdb-read /type)" = "TemplateVM" ]; then
    echo "Running in TemplateVM" >> "$LOGFILE"

    export all_proxy=http://127.0.0.1:8082/
    flatpak upgrade -y --noninteractive >> "$LOGFILE" 2>&1

    echo "Flatpak update finished with exit code $?" >> "$LOGFILE"
else
    echo "Not a TemplateVM" >> "$LOGFILE"
fi

echo "=== $(date) : script ended ===" >> "$LOGFILE"

So the script would create a log file when executed. However, no log file was created. It means the script is not actually running.

Although its executable:

-rwxr-xr-x 1 root root 508 Apr 23 10:31 05-flatpak-update.sh

1 Like

A post was merged into an existing topic: QubesOS - Coreboot/U-boot

I don’t understand why this mention, for various reasons. No one owes you a reply. This is an open source project. solene is a community contributor & documentation maintainer. I consider that a cautious attitude would be not to add some burden to someone else, especially here. We need to take care of each other.

To get back to your original question, is it triggered when running /etc/qubes-rpc/qubes.PostInstall directly?

It gets triggered when I run /etc/qubes/post-install.d/05-flatpak-update.sh directly, yes.

And I apologize, I had no intention of putting a burden on anyone.

If it’s not a template and has no persistency in /var logs won’t be saved. Also stuff in post-install.d only runs when there are updates via conventional package manager.

An alternative is to write up a plugin for flatpak and put it into /usr/lib/python3.13/site-packages/vmupdate/agent/source/plugins/ because that runs before the normal update

I think I’ve seen an attempt somewhere

It was a template

Four packages were upgraded using the Qubes Update utility.

If I were that capable, I would have resolved this issue on my own.

1 Like

@solene please update guide on this problem. It’s very inconvenient to use Flatpak without automatic updates

Output of post-install scripts is captured when running updates. Even if you don’t have anything to update via flatpak it shoud show the “nothing to do” message.

Perhaps you could try to simplify it to make sure that it is not the problem with the script? Try replacing it with just single echo or something.

it does work, troubleshoot

1 Like

Again.

Yes but I was talking about this script:

etc/qubes-rpc/qubes.PostInstall

I wasn’t thinking that you had this intention but it’s a quite common pattern I see all around me. Now you know.

1 Like

This was the result

./qubes.PostInstall 
Trimming qube storage. This may take some time...

After running the script, it didn’t show anything for a few seconds, then displayed the above message and terminated immediately afterward.

Do you have the log though? Or you no longer redirect?

This is the related log I think:

[template workstation sysmaint /etc/qubes-rpc]% sudo journalctl -b | grep PostInstall         
Apr 24 16:56:12 host audit[6808]: USER_CMD pid=6808 uid=1001 auid=4294967295 ses=4294967295 subj=unconfined msg='cwd="/etc/qubes-rpc" cmd="./etc/qubes-rpc/qubes.PostInstall" exe="/usr/bin/sudo" terminal=pts/0 res=failed'
Apr 24 16:56:12 host kernel: audit: type=1123 audit(1777049772.790:338): pid=6808 uid=1001 auid=4294967295 ses=4294967295 subj=unconfined msg='cwd="/etc/qubes-rpc" cmd="./etc/qubes-rpc/qubes.PostInstall" exe="/usr/bin/sudo" terminal=pts/0 res=failed'

I mean the one created by your script :sweat_smile:

You could also make your own version of qubes.PostInstall that prints paths it runs to be absolutely sure

As I mentioned before it did not generate any log.

1 Like

So you’re running Whonix or Kicksecure? I’m not convinced, but it might be the issue here?

All the commands in this guide are meant to be run in a Fedora or Debian template as root.

Could you try with a test script in another template?

That seems to be the case. I was doing this on a Whonix Workstation.

When I run /etc/qubes-rpc/qubes.PostInstall in Debian 13, it runs fine and starts updating Flatpak packages.

What could be the reason? Or should I ask this in the Whonix community?