Each time I update qubes-core-agent, qubes-bind-dirs service get disabled

User Support General
1

I did work around this with update trigger that re-enables the service, but WHY?
The template is debian-13-minimal based.

Apparently line 60 has something to do with it, but I have no clue how to fix.
I tried running preinst, postinst and postrm scripts manually with different arguments but was not able to reproduce the effect, yet, with each package upgrade I see this.

2

sh: 5: shopt: not found

Looks like a qubes script is trying to set shopt settings when it has been invoked with #!/bin/sh rather than #!/bin/bash. That works ok on Fedora but doesn’t work on Debian.

3

I get it all the time on every qvm-run, so it is unlikely the issue.

4

Played a bit more with that, but could not find why it is not reactivated.
Even more: if I reset status of qubes-core-agent to “unpacked” and manually run dpkg --configure, qubes-bind-dirs gets properly re-enabled.

5

Ignorant question:
Is it disabled only in template, but not in AppVM based on the template? It would seem like correct behaviour.

6

When it gets disabled in template, it gets disabled everywhere (like, actually disabled, not “condition not met” disabled)

7

Some magic stuff happens which makes no sense to me.
If I add DPkg::Post-Invoke hook that is

  • runs from a spawned shell (sh -c systemctl works, /usr/bin/systemctl fails silently, no stdout no stderr)
  • interacts with systemd (systemctl status qubes-firewall works, “id” runs but affects nothing)

the effect ceases, qubes-bind-dirs is re-enabled normally.

WTF??!!

8

also, no issue if i run dpkg outside of apt, everything is fine.