It works for me.
To note, if you run Qubes Update for this qube and restart the template after update then the file /tmp/a.txt won’t persist because /tmp directory is not persistent. Write to /home/user/a.txt for a test instead.
Also the script in /etc/qubes/post-install.d will only be executed if some package was installed during update. If there were no new updates then nothing will be executed.
In addition to what was said, these scripts will also be executed if you install a program from an AppVM (it’s something I often do, even if it’s not persistent).
You can add this to your script so it exits on non templates, this checks if there is a network interface and exits if so, a template shouldn’t have a network interface.
# abort if not in a template
ip l show eth0 && exit 0
@Euwiiwueir You are right. None of the scripts get called in debian
templates.
If there is not an existing issue will you raise one on GitHub? If not,
I will.
Per the comment by marmarek in the issue, Debian templates don’t generally need to run the /etc/qubes/post-install.d scripts for soundness after doing package manager stuff. Qubes devs could make the behavior consistent and run these simple scripts unnecessarily, but maybe it’s better to just document the difference, as Debian already has fully-functional non-Qubes methods to hook scripting into apt and dpkg.
For example…
Case study: shortening the qubes-app-shutdown-idle timer, and keeping it short across package upgrades
#!/bin/bash
# 'unpack' seems like the most appropriate action to hook into, but you
# could choose a different one. See ACTIONS in dpkg(1).
if [ "$DPKG_HOOK_ACTION" ] && [ "$DPKG_HOOK_ACTION" != unpack ]; then
exit 0
fi
# Verify relevant package is actually installed.
if ! dpkg-query --show -f='${Status}' qubes-app-shutdown-idle | \
grep -q installed; then
exit 0
fi
# If you like, key off the qube type as suggested in
# https://forum.qubes-os.org/t/how-can-i-execute-a-script-after-each-update/25904/7
case "$(qubesdb-read /type)" in
TemplateVM|StandaloneVM)
dpkg --listfiles qubes-app-shutdown-idle | \
grep qubesidle/idleness_monitor.py | \
while read f; do
# Default is 15 min; make it 30 secs
if ! grep -q 'TIMEOUT_SECONDS = 30$' "$f"; then
sed -i 's/TIMEOUT_SECONDS = .*/TIMEOUT_SECONDS = 30/' "$f"
fi
done
;;
esac
(Note: parent dir /usr/libexec/dpkg chosen arbitrarily)
For apt update, there is /etc/apt/apt.conf.d/
For Arch Linux or Gentoo, there is surely something similar. I leave it to another poster, or a web search
I see… I think it must be new in dnf5. My old Fedoras, before about 39, have some Qubes-specific hook…
First I thought the dnf5 hook could allow Fedora to have the same minimal behaviour as Debian.
Now, I am thinking that the existing difference between Fedora and other templates can cause failure to keep an old apt-based template the same as a new installed one.
Fedora template does a full “post install” process of /etc/qubes/post-install.d at every update, but Debian does not seem to. If any scripts are changed or added there, then it can cause subtle bugs in Debian template for some users (I think, because I do not see when they are run by Debian.)
Probably I got it wrong, but I’m thinking that the proposed resolution of documentation-only fix to the issue is maybe not ideal… because of risk of missing functionality/features in Debian/apt qubes in current arrangement. It could cause Works-for-me type issues.
If Debian not running those /etc/qubes/post-install.d scripts at each package install/upgrade/remove could lead to subtle bugs for some users in some circumstances, then it would be worth making the behavior consistent. My takeaway from marmarek’s comment is that not running those scripts is not expected to cause bugs on Debian. But I haven’t audited the scripts myself or thought through upgrade scenarios. Probably a worthwhile project for someone in the community- I think that kind of implementation review is always a value-add.
I saw a script related to pipewire in there, and I had a vague memory of a cluster of forum reports of sound-related problems in Debian when that switch happened. It seemed worth investigating but I cannot find any of them now, so maybe I imagined it… and there are many other possible reasons for audio to misbehave.
Yep may be somewhat annoying: I discovered than on some “sufficiently minimal” debian templates post-install script of qubes-core-agent fails to re-enable qubes-bind-dirs after it disables in on previous stage (to be honest I am missing the point of disabling a bunch of services at the first place). Made an ugly workaround because I spent a few days in futile attempts to identify the root cause.
That’s a fair point. The documentation update to the README, which I still have yet to do, is a partial mitigation – the user might remember the operational difference – but it’s still a potential footgun for sure.
