Upon reading this thread, I decided to run manually a full update (all templates + Dom0). To my surprise, Dom0 updated linux-firmware new: 20211216 old: 20200122, and linux-firmware-whence new: 20211216 old: 20200122, and many other updates. Does this mean that updates were available for 3 months, but the Qubes Updater failed to find that?
Also, is there a simple command to manually run Qubes Updater for all available templates + Dom0?
What you are reporting is that the update tool does not show dom0
updates even when they are available.
This has nothing to do with #6585.
That issue relates to salt not reporting failures to update, whereas the
issue here relates to updates not being reported. They are completely
In fact, if you read the issue you will see that imo #6585 is not so
important because users would see that updates are always available,
even if the update tool reports success.
So this would be a separate (possibly related) issue.
No.Issue #6585 is only about the bug described in that issue, which is not a bug that prevents the Qubes Update tool from working normally. (I won’t copy/paste the issue description here. Go read it if you want to know.)
There seem to be differing opinions about how important it is and whether it should be widely announced. @marmarek and Simon are aware of the issue. I’ve offered to make announcement about it but have not received a response, so I take that as an indication that they don’t consider it serious enough to merit further action right now. I respect that decision and haven’t pushed further on it.
What I don’t understand, why should I first update via salt and then via terminal in dom0?? As I understand, salt is at the moment rather useless, because it’s not reliable on correct update. So why not just always use dom0 till the problem is fixed?
salt may be used to configure your Qubes system. If you only use the
native update, you will not get this input.
To be clear - it isn’t that salt is not reliable. The issue is that it
doesn’t provide adequate feedback, so that it may tell you that an update
has succeeded when it has not.
If you use the native update tool you will see an error message.
The notification that an update is available will not be cleared, so you
should realise that something has gone wrong.
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
That could simply be because you manually updated in between automatic update checks.
Your machine automatically checks for updates. (None found.)
New updates appear on the server.
You manually try to update. (Find updates.)
Your machine automatically checks for updates again. (Would have found the updates, except you already manually ran the updater, so you already have them.)
This can happen with any update system, unless it’s constantly checking or updates are being “pushed” to it in real time as soon as they’re available, but I don’t think any operating system works that way.
In every Debian template and standalone: apt-get clean && apt-get -y update && apt-get -y dist-upgrade && apt-get clean
this actually fails with :
E: Could not open lock file /var/cache/apt/archives/lock - open (13: Permission denied)
E: Unable to lock directory /var/cache/apt/archives/
E: Could not open lock file /var/lib/apt/lists/lock - open (13: Permission denied)
E: Unable to lock directory /var/lib/apt/lists/
works fine with no leading $sudo apt-get clean and without the && , but guess I read in
that beginning with the $sudo apt-get clean matters?
afaik, I don’t have any dom0 silent update fails, but ran through the commands anyway …
I posted the whonix-ws-16 post because using the dom0 --templates command the command ‘hung’ on the -ws-16, so I went into a template terminal and ran the $sudo apt update / upgrade / clean, (again the leading ‘clean’) fails …