Dom0 Doesn't Always Show Updates Available

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:

https://www.qubes-os.org/doc/how-to-update/#command-line-interface

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.

Not similar words, not significant way, but possibly related?

But, what is mitigation for this issue?

I wouldn’t expect such a noisy wording, but maybe it sounds not nice to me because English is not my first language.

as I understood, this is the mitigation for the #6585 (which has nothing to do with the issue I posted here):

What I still don’t understand, is why should I still update with Salt in the first step, if Salt falsely claims to succeed when it actually fails???

So I update via direct commands in dom0 and don’t think about Salt, till the issue #6585 is solved. It’s rather annoying, but so it is.

https://github.com/QubesOS/qubes-posts/blob/update-commands/2021-05-06-updating-via-direct-commands-no-longer-recommended.md

1 Like

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:-

  1. The “check for updates” never runs.
  2. The check for updates runs, but the output is incorrectly parsed, so
    the update tool does not report updates available.
  3. The check runs, the output is correctly parsed, but the trigger for
    displaying a warning of available updates does not fire.
  4. 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.
1 Like

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??

I was hoping to clear up confusion.

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.
1 Like

I thank you for this clear answer. I hope you understand regular user(s) are or were confused, so your response is exactly what we (I) needed.

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.

That’s i understood, but why is there Salt in the first step, if Salt does not deliver reliable result?

I mean these steps:

Update dom0 with Salt.
Update dom0 by direct command.
Update templates and standalones with Salt.
Update templates and standalones by direct commands.

Why not just
Update dom0 by direct command.
Update templates and standalones by direct commands (in dom0)

Or do I still understand something wrong? :slight_smile:

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.

1 Like

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.

hmm… but if it shows succeeded update, which is NOT succeeded… it’s just not good. So I can just hope, that it will be fully reliable soon. Thanks!

Moved thread into ‘User Support’

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.

2 Likes

THANKS A LOT!! Now I understand the point!
Will be there some news, when the issue with the salt is solved?

Just keep an eye on #6585. Any updates will be reflected on that issue.

1 Like