How do I actually update Qubes OS v4.1?

I’ve spent a lot of time reading various issues related to installing updates in Qubes OS, but still have no idea what’s working, what’s not working, whether my system is even getting updates, and what I’m actually supposed to be doing to simply update my Qubes OS v4.1 system. During OS installation, I opted to get my updates through Tor using Whonix and am now wondering whether this was a mistake because Whonix seems to be very flaky on my machine (despite me not doing anything to it).

First, I note that I almost never see updates for dom0 in the Qubes Update tool. I’m not sure I’ve actually seen any since I installed Qubes OS v4.1 ~6 weeks ago, but I may have seen one come through. Is this normal?

I also keep reading that you should update through the Qubes Update tool for security reasons, as opposed to command line, but there may be multiple problems with this tool (e.g. Updating via Salt falsely claims to succeed when it actually fails · Issue #6585 · QubesOS/qubes-issues · GitHub), so what are users supposed to do?

I tried forcing updates to dom0 through the Qubes Update tool (by checking “Enable updates for qubes without known available updates.”), but this didn’t work:

  • Ran for ~1 hour and did nothing (just a spinning wheel)
  • I tried to cancel it, but this didn’t work either. It showed me a dialog (“Waiting for current qube to finish updating. Updates for remaining qubes have been cancelled”), but wouldn’t do anything, so I had to restart the machine.

I read through (How to update | Qubes OS), but am still confused because the commands described in this page do not reliably work for me:

1st Attempt

  • sudo qubesctl --show-output state.sls update.qubes-dom0: This didn’t seem to do anything, so I eventually killed it with Ctrl+C
  • sudo qubesctl update.qubes-dom0: I didn’t record the error, but this kept saying something to the effect of dom0 not being available
  • I restarted the machine

2nd Attempt

  • sudo qubesctl --show-output state.sls update.qubes-dom0: This claimed 4 succeeded and 0 failed, but the output above indicated there was nothing to update (“No changes need to be made”, “No changes need to be made”, “Cache cleaned”, “System is already up-to-date”)
  • qubes-dom0-update --clean -y: This failed in a sys-whonix shell stating “Segmentation fault (core dumped). Fetching updates failed with code 139; press Enter to exit.”
  • When I restarted and logged back in, I started having major graphical issues that almost made the machine unusable. Another restart seemed to fix this, but now I’m afraid the OS is corrupted.

I should also point out that the Fedora, Whonix, and Debian updates fail ~1/3 of the time in the Qubes Update tool, but I have no idea why. Usually, rebooting and trying again fixes this, but this is very time-consuming. The updates are painfully slow as it is (despite being on a fast system) even when they do succeed, so dealing with all of this nonsense can easily consume more than 1/2 hour per day just trying to get updates installed.

Can anyone tell me how I can simply, securely, reliably update my system? I can’t find a straight answer on this, or any answer that actually works. Is it just me, or should updates be easier and more transparent on a security-focused OS? I have a hard time trusting that this is secure if I can’t even be confident that it’s receiving updates.

1 Like

I must admit that

to get why would security have to do anything with easiness and transparency.
I lost my temper too many times recently for the exact same reason, but for a second I didn’t relate it to the security.
Because, very few updates are actually related to security, and when they are, we are specifically notified about it.
So, I think you might mix stability with security.

made me to stop here.

This is a pretty accurate way of putting my experience with QubesOS, too.

I’ll try to summarise:

What isn’t currently working properly:

  1. Notification of dom0 updates.
  2. In some cases, the Update tool will report “success” when an update
    has not been applied.
  3. In some cases, updates via Whonix are broken.
  4. In some cases, updates fail, and the Details given are unhelpful.
  5. No feedback is provided during the update process.

Issue 1 has been fixed, and updated packages are working their way to
users now.
Issue 2 is a shortcoming in Salt, the mechanism used by the Update tool.
It doesn’t override the GUI notification, so users will still see that
updates are available.
Issue 3 may be a bug in Whonix, or may be a reflection of the fact that
updates over Tor can be generally flaky.
Issue 4 is a shortcoming in Salt, the mechanism used by the Update tool.
There are moves to use a custom non-interactive update tool to replace Salt.

I tend not to use the GUI update tool, but I do use Salt for updates. I
don’t use Whonix, but do update with a caching proxy over Tor. I have fibre
to the desktop. I very rarely see the issues that bother other users.
Make of that what you will.

Most users I know who don’t update over Tor are happy with the GUI
update tool - I advise them to manually select dom0 on each run, and
that seems fine.
Sometimes repositories report errors or are unavailable. I advise users
to wait and try again later. In a few cases I get them to update
from command line in the template. In very few cases, some manual
configuration is needed.
Users who update over Tor have to learn patience.

I once worked with a developer who would float about, on the grounds
that he was “compiling”.
Updating and taking Backups are things you should do in the background.
They should not occupy your time.

My advice generally:

  1. Use the GUI tool and manually select dom0 on each run.
  2. Check the “Details”
  3. If the GUI tool shows updates still available after apparently successful
    updates, run updates manually.

The docs advice:

  1. Update dom0 with Salt.
  2. Update dom0 by direct command.
  3. Update templates and standalones with Salt.
  4. Update templates and standalones by direct commands.
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
4 Likes

Let me add one personal observation to @unman’s excellent summary.

I use the shutdown-idle script in almost all my qubes and had the respective shutdown-idle on service set also for templates. And then one day I shortened the timeout from 15 minutes to 20 seconds. :wink:

Next thing: all my updates wouldn’t work anymore, because the script would kill the template qubes before they finished updating. So obviously I disabled this service for the templates and the problem was gone.

To me it is conceivable that if updating via Tor with a crappy connection even a 15 minute timeout could lead to issues. So if you have update issues and you use the shutdown-idle script, make sure it is NOT enabled for your templates!

1 Like

Every time I do this, my system locks up and I have to force-shutdown. Any ideas?

We are notified in what way? All I see is that there are updates available, which brings up a separate issue - I don’t get to see what the updates are. In Linux Mint, for example, you can see what needs updated and whether they are security or other updates, which is helpful.

Regardless, I’m not sure I agree that security and stability are separate issues here. For an OS to be so unstable that you can’t even update it reliably, it’s difficult to trust that it is secure.

1 Like

I guess @enmus means Qubes security bulletins. However, the notification only occurs on the website, this forum and mailing lists, not in the actual running OS (related issue, another one).

1 Like

How long are you giving it before aborting? For example, when updating over Tor, even 15 minutes may not be long enough. Try just letting it run overnight or something just to be sure.

Could be anything. Folks will probably need the exact output in order to be able to help with this.

This sounds like the normal result when your system is already up-to-date and no new updates are available.

That sounds like something bad that shouldn’t be happening, but diagnosing it is beyond my skill set.

It sounds like something about your setup is broken. This may not even have anything to do with updates.


In general, following the instructions in the documentation should work and is confirmed by many users to work (aside from temporary network and server issues that aren’t under our control, where simply trying again later eventually works). If it doesn’t work for you, then there’s a problem somewhere, but more info will likely be needed by those who are capable of diagnosing it (starting with exact outputs and error messages). If you’re confident you’ve identified a bug, please see: Issue tracking | Qubes OS.

Then, what does the “4 succeeded” mean, if there were no updates taken place? What succeeds, when the update process doesn’t update a thing?

As it says: successfully ran 4 states?

Yes, I think that means is successfully ran four components of the update checking mechanism. Even if there are no updates available, the process of checking for updates must still run (in order to find out whether there any updates available), and that process (including its component sub-processes) can either succeed or fail.

It’s important to know whether the attempt to check for updates succeeded or failed, since if it failed, there might be updates even though your system wasn’t able to ascertain the status of their availability. If you know that the attempt to check for updates succeeded, and you know that the result was that there aren’t any updates available, you now know that your system is fully up-to-date, and that’s a valuable thing to know.

1 Like

The ways to update the whole entire system as the following:

  1. Use Qubes Updater

  2. CLI

That’s all

But it’s presented in somewhat misleading way: it doesn’t say “No new updates found upon performed checking”. It says: “success” upon hitting “update”.

1 Like

Ok, but that’s a UX issue. I was merely explaining how it works, not attempting to defend the current UX.

I’m not saying it’s not a problem. I’m just saying it’s a different kind of problem.

1 Like