Hi,
see this thread on the QubesOS-forum: Qubes OS 4.3.2 has been released! - News - Qubes OS Forum
Seems like something is wrong with sys-whonix so that you can’t update dom0 over sys-whonix.
Just replied to that thread. I had encountered this in the past after trying to force-terminate a software update, and reinstalling my Whonix qubes fixed it, so I figured it was user error.
So who is gonna fix this, Whonix or QubesOS? Who is responsible for this? I WANT ANSWERS!
Just kidding. I just want a solution, but who is responsible for fixing that?
1 Like
We don’t know for sure yet. I’ll try to reproduce the issue again. If it turns out to not be user error, it’s probably a Whonix bug. (Even if it turns out to be a Qubes bug, we’ll probably help fix it upstream, but I doubt it’s a Qubes bug.)
If you need some information on the problem, I’m here to answer, because I still got that problem (which I never had before) and I don’t want to switch from updating over sys-whonix to updating over clearnet or some vpn. So in the meantime I can’t update dom0 
1 Like
Which is of course very important and also why I would appreciate a fast response here, even if it’s friday/saturday, depending on where you live.
And of course I’m not the only one in this situation. Many people with this problem probably won’t even come to the forums and will just try to “suffer” through this, hoping that someone else has the same problem and will write on the forums about it.
I just tested with my trixie-developers-enabled sys-whonix, and then again with a sys-whonix based on a cleanly installed and fully updated whonix-gateway-18 template, and could not reproduce the problem in either scenario. What software repos do you have enabled? Does /etc/apt/sources.list.d/derivative.sources contain trixie-developers or trixie-testers? Can you please also share a full journalctl --boot log from sys-whonix after reproducing the issue? (Note that you may have to redact sensitive data from these logs, so check them first. Use a Qubes Root Console if the inability to use sudo in sys-whonix gets in your way.)
If anyone here is affected and doesn’t mind being unable to help debug in the future, you can probably remedy this situation by deleting your sys-whonix and whonix-gateway-18 qubes, then reinstall whonix-gateway-18, create a new sys-whonix qube, and fully update it.
I can say this: I don’t have any problems updating (over sys-whonix of course) the whonix gateway or the whonix workstation or even the debian13xfce template. Only dom0 does not update, everything else works.
The other stuff I don’t know if can do this, because I almost don’t know anything about the terminal and especially nothing about what and where could be sensitive information if I provide you a log.
So you have to explain everything very detailed as if I’m an idiot.
Edit: Good thing about this is though, that I haven’t changed much in QubesOS and therefore it’s more like a standard installation of QubesOS and not a highly configured installation.
I’m awaiting your, very detailed and as if I’m an idiot, orders.
Also I might add, that in the installation of QubesOS I chose everything to be based on Debian and the standard is Fedora if I remember correctly. So maybe if you choose everything to be based on Debian in a fresh install of Qubes OS, you can reproduce the error.
- Btw the whole error message is:
Failed to connect to system scope bus via local transport: Operation not permitted (consider using --machine=@.host --user to connect to bus of other user)
- You can ask AI yourself about it of course, but what I read out of it using AI is that it probably has something to do with not having the right permissions or is a security policy issue, or a user identity mismatch, if I get from AI something like this:
The error is happening because the program you are running is trying to communicate with the system-wide manager (systemd) to check a status or change a setting. However, because you are inside a container, you are in a separate “namespace.” To the container, the host’s system bus is invisible or restricted for security reasons. When the program tries to “reach out” to the host, the system blocks it with "Operation not permitted.
The suggested flag --machine=@.host --user is systemd’s way of saying: "I realize you are inside a container. If you actually intended to manage the services on the physical host machine, you need to explicitly tell me to target the host’s user session rather than the container’s system scope.
- Also I found this Github thread and in the end the maintainer is saying:
yeah this is just the way of life I guess, if you run in a user namespace with a different uid on a rootfs and process tree that expects others uids then problems are likely to happen if the application is not really aware of said user namespace**
Just from a guess but I think the systemctl tries to connect to the dbus conn with uid 0 and authentication and then the server outside rejects that of course because in that uid view the process belongs to uid 1000 or whatever else.
I think the only reasonable would be to not have any uid dependencies in the profile scripts.
Don’t know though if this is the exact same problem as here. I just copy pasted it here because it looked somewhat similar.
I’ve encountered this problem as well.
There are dom0 updates available
Using sys-whonix as UpdateVM for Dom0
Downloading updates. This may take a while…
Failed to connect to system scope bus via local transport: Operation not permitted (consider using --machine=@.host --user to connect to bus of other user)
Dom0 was updating fine until recently. The issue started occurring right after I updated sys-whonix.
Same. Could have been the recent whonix updates that broke it.
I also may add that I update or rather look for updates for my all my Qubes sometimes like 3 times a day by clicking on “Qubes Update” and selecting all my Qubes, because sometimes I’m thinking about something very long or need to go to the toillete or something like that and think to myself: Why not check for updates in the meantime.
So I’m not that guy that had very old versions of his other Qubes.
I created a regular AppVM based on Debian 13, set its NetVM to sys-whonix, and configured it as the UpdateVM for dom0. The update completed successfully. This confirms the problem is specifically with sys-whonix after the latest update. It might be related to polkit (possibly a policy issue), but further investigation is needed.
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
Interesting move to close the vibecoding thread before releasing this fix and with that at least to some degree proving my point.
But still thanks for working on the weekend to get us the fix. I appreciate that.
And I mean I obviously think Whonix is a very good project, but I would sleep better if it had more developers. I think you can understand that.
Thanks.
This issue was caused by:
- project-wide scripting improvements, namely strict shell options almost everywhere
- a gap in (automated) testing
- me missing this issue during manual testing
This issue wasn’t caused by:
- vibecoding
This issue could have been prevented by:
- A) project hand-coded automated test suite
- B) third-party hand-coded automated test suite
- C) project vibecoded automated test suite
- D) third-party vibecoded automated test suite
- E) dedicated quality testing contributor
- F) dedicated stable release manager contributor
Options B and D are up for grabs and could be implemented autonomously by anyone.
Most projects wish for more developers, however chronic understaffing / underfunding is indemic in Open Source projects. See also:
1 Like
While I would love to help, I don’t feel I have the necessary technical expertise to take on responsibilities related to the codebase, especially given Whonix’s extreme security requirements.
However, as a dedicated user who relies exclusively on Whonix, I would be more than happy to contribute in other ways. If there are any non-coding tasks or other areas where help is needed, please let me know. I’d be glad to support the project’s development.