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.)
Correct.
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?
Qubes updater already is working again (for me) and does what it was build for
and so I only use the terminal updates if the Salt updates fail in any way (i.e. updates went through properly, but orange star still can be shown in the info bar)
I never do the terminal updates in dom0 → always do them in the terminal of the template, which should be updated
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’s not good, because of build in security while updating via salt or dom0 (as I understood)
But then it is NOT reliable
If I update the VMs and they are after that NOT updated, it’s very bad.
Is salt = “native update tool”? Or did I understan it wrong.
The problem is. I updated some VMs via salt, the notification gone, but after a rather short time it appeared again. So as I understand, the salt did not work fine in that case.
I have also experienced this. Even if I can’t see the dom0 update, sometimes I do manual update using qubes-update-tool instead of terminal. As the wiki says, it’s not safe to do it with the terminal.
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 …
Of course we’re aware of the procedure. But, it is related to #6585 and what we have here is
So, that is where my confusion comes from. What is mitigation for this and all other recent issues? And if that procedure (should) help(s) with all of them, then it should be clearly stated.
I understand @unman to be saying that the original topic of this forum thread is separate (i.e., a distinct matter) from #6585, which is correct. It appears that some folks in this thread took a cursory glance at #6585, saw a bunch of similar-sounding key words, and arrived at the mistaken conclusion that the two are connected in some significant way.
Again, the mitigation for #6585 is clearly stated here:
Notice the part beginning with, “As a temporary mitigation until #6585 is fixed, the following update sequence is recommended (see PR #79 for explanation and discussion): […]”
As for “all other recent issues,” you’ll have to be more specific. If they’re off-topic for this thread, they should be discussed elsewhere.
As quoted above, it’s intended to be a mitigation only for #6585, nothing more. Whether it also happens to help with any other things depends on what those other things are.