Can't update dom0 over sys-whonix in QubesOS

Qubes-Whonix
14

Reproduced.

Fix pushed to all repositories.

It requires upgrading Whonix-Gateway Template first, then restart sys-whonix. This will unblock upgrading dom0.

The issue is probably far too complex for a pure AI chatbot to figure it out. An AI harness [1] has a much better chance to figure it out. But such as hardness comes with its own security issues so may require a dedicated computer.

Information for developers:

qubes-dom0-update runs /usr/lib/qubes/qubes-download-dom0-updates.sh.

fakeroot dnf upgrade --noplugins -y --best --allowerasing --downloadonly --installroot /var/lib/qubes/dom0-updates --config=/var/lib/qubes/dom0-updates/etc/dnf/dnf.conf --setopt=reposdir=/var/lib/qubes/dom0-updates/etc/yum.repos.d --setopt=cachedir=/var/lib/qubes/dom0-updates/var/cache/dnf --setopt=protected_packages= ‘–exclude=qubes-template-*’

Issue reproduced with:

[gateway user ~]% fakeroot dnf
Failed to connect to system scope bus via local transport: Operation not permitted (consider using --machine=<user>@.host --user to connect to bus of other user)
zsh: exit 1     fakeroot dnf
[gateway user ~]%

dnf is actually dnf uwt wrapper.

realpath /usr/bin/dnf

/usr/bin/dnf-3.anondist

Which includes:

if command -v leaprun >/dev/null \
  && leaprun --check try-wait-for-tor-service-running >/dev/null 2>&1; then
  leaprun try-wait-for-tor-service-running
else
  /usr/libexec/helper-scripts/try-wait-for-tor-service-running
fi

If we are root (or fakeroot) should we skip leaprun?

leaprun fails under fakeroot.

leaprun --check try-wait-for-tor-service-running
Account 'user' (1000) is authorized to run action 'try-wait-for-tor-service-running'.

fakeroot leaprun --check try-wait-for-tor-service-running
ERROR: Could not connect to privleapd!

/usr/libexec/helper-scripts/try-wait-for-tor-service-running was introduced to avoid APT errors in case a Template has run “sudo apt update” before Tor has started inside sys-whonix. [2]

[1]

[2]

2 Likes