Dom0 Doesn't Always Show Updates Available

Continuing the discussion from Understanding "Qubes Updater":

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?

1 Like

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
different.
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.

1 Like

I mean that “details”… there I just see “Updating dom0” (for example) and nothing else.

That’s the point I have the whole time!

I tested it now again. The Qubes updates does not show any update for dom0. Updating via terminal (qubes-dom0-update) finds updates.

So it seems to me, that the updater does not work well. And do I understand it right? The problem is the #6585 issue and until it’s fixed I can not rely just on qubes updater (salt)?

Exactly.

ok, thanks! I mean, it would be very important to inform the users via official qubes news about that problem. It’s very big security issue.

1 Like

ok, understand…
Can somebody then make an issue (I have no idea how to do that)? Maby somebody who is technically more skilled then I :slight_smile:

Strong technical skills are not required: Issue tracking | Qubes OS.

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.

I have also experienced this.

Split this discussion into its own topic.

1 Like

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?

Hmm, sorry if my answer will cause confusion…

From, what I currently know:

  • 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.
2 Likes

that’s not good, because of build in security while updating via salt or dom0 (as I understood)

But then it is NOT reliable :slight_smile:
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.

Strange thing…

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.

DemiMarie commented on Jul 3, 2021

According to the DNF developers, this is a Salt bug.

Congrats to regular users who just want to update their system and aren’t confused what to do trying to do that. I admit I am.

1 Like

Just tried “Update qube” in Qube Manager for dom0, and it found updates which were not shown in the update widget. Indeed looks concerning.

Same here, today.

This section explains what you should do, step-by-step:

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

That could simply be because you manually updated in between automatic update checks.

  1. Your machine automatically checks for updates. (None found.)
  2. New updates appear on the server.
  3. You manually try to update. (Find updates.)
  4. 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.

A post was split to a new topic: Should I autoremove whonix-gw-16?

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 …