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.
The position seems clear to me, so I will try to make it clear.
#6585 reports that the update mechanism based on Salt will sometimes
fail, but that the update tool will report success. This is probably
due to the salt state failing to correctly parse output from native
update tools( dnf/apt-get/ etc).
This issue reports that the update tool does not report when there
are updates available for dom0.
There may be a number of causes:-
The “check for updates” never runs.
The check for updates runs, but the output is incorrectly parsed, so
the update tool does not report updates available.
The check runs, the output is correctly parsed, but the trigger for
displaying a warning of available updates does not fire.
The trigger fires, but the display mechanism is broken.
There are probably other routes to failure.
Case 2 may be related to #6585 - it is possible that fixing salt for #6585 will fix this issue.
If this is a genuine issue in 4.1 the mitigation would be to run a dom0
update manually, using qubes-dom0-update.
That is, as a matter of fact, the same mitigation suggested to deal
with #6585. Even if the root causes are completely different, the same mitigation
may apply. This is not unusual.
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
I’m f… confused.
Salt falsely claims to succeed when it actually fails, so why should I use Salt for the update process??
And I did not write “direct command”, but “direct command in dom0”. It’s big difference and is just the mitigation of the #6585 issue. The question is, why should I still use Salt on the first step??
There are some cases where Salt does not report failure. In most cases
it does report failure correctly.
As has been repeatedly said, Salt is the current route for distributing configuration and update
changes.
If you do not use the update tool you will not get these.
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
you surely cleared some central points, but does it make sense to use Salt, if it works just in “most cases”? Because I can not see, if in that particular case the Salt reports the succeeded update or not.
I now realize that we simply don’t have an alternative. We are advised to use procedure for #6585 and there isn’t anything else that can be done at the moment.
AFAIK there are things which cannot be updated with the direct commands. Also, Salt is already almost reliable and will become fully reliable soon. There are some explanations in my links.
As these examples show, the main reason to update via Salt rather than via direct commands is to benefit from security features that are only available via Salt updates.
It’s all written there. It just needs significant amount of focus to read it.
Because Salt updates can deliver special fixes that the old direct commands cannot. These special fixes don’t happen all the time; just in special circumstances. However, if you never use Salt updates, you will never get these special fixes, and your system may remain vulnerable. This will continue to be true even if you diligently update with the old direct commands.
The fact that the Salt updates aren’t reliable (in the sense that they sometimes claim to have updated successfully when they actually did nothing) doesn’t change the fact that the Salt updates have greater capabilities that the old direct update commands don’t have. You can refuse to use Salt updates because they’re unreliable, but then you’ll miss out on any special fixes that only they can deliver. That’s why the workaround steps recommend using both methods (Salt updates followed by the old direct commands). This way, you can try to get any special fixes that might be available, and in case Salt falsely claimed to do something when it actually did nothing, you follow it up with the old direct commands, which are better at telling you whether they succeeded or not, so that you don’t miss out on any updates that the old direct commands are capable of delivering.