Sorry! I think I messed up the script 05-flatpak-update.sh in Whonix Workstation while troubleshooting the issue. That’s why it wasn’t running in Whonix Workstation but was working in Debian 13.
But now there is a different kind of error:
Updating app/org.asamk.SignalCli/x86_64/stable
F: Failed to get revokefs-fuse socket from system-helper: Flatpak system operation GetRevokefsFd not allowed for user
Error: Failed to update org.asamk.SignalCli: Flatpak system operation Deploy not allowed for user
Trimming qube storage. This may take some time...
But the script is not being accessed by a user. When the Qubes Update utility runs this script, it should be executed as root, right? And now I am accessing it as sysmaint.
I modified the script and added sudo before flatpak upgrade -y --noninteractive.
Then it ran and said “Nothing to do.”
Then I checked manually by running sudo flatpak upgrade, and it didn’t find any updates, but running flatpak upgrade without sudo shows the updates.
So it seems that user-sysmaint-split is causing the issue somehow. But I still don’t understand, AFAIK, the Qubes Update utility runs it as root, so this should not be an issue there. Then why isn’t it running there?
My understanding from the start is that this script runs after the Qubes Update utility finishes the installation process, but then it sends the shutdown command, and this script gets terminated before completion. There should be a way to delay the shutdown command until the Flatpak upgrade process ends.
Or maybe, when the update finishes in the template, a script should be triggered from dom0 to run the Flatpak upgrade command?
BTW, even in Debian 13, although qubes.PostInstall ran fine manually, it never updated the packages when using the Qubes Update utility, because when Flatpak started updating, the installed packages were many versions behind the available updates.