Qubes-vm-update gotcha when qubes-update-check = off

Just sharing some findings for posterity.

[user@dom0 ~]$ qubes-vm-update --targets debian-12-minimal
No qube selected for update
[user@dom0 ~]$ qubes-vm-update --templates
No qube selected for update
[user@dom0 ~]$ qubes-vm-update --all
Skipping dom0. To update AdminVM use `qubes-dom0-update`
No qube selected for update

I first interpreted “No qube selected for update” to mean I’d misspecified the arguments to qubes-vm-update or that there were a new bug in argument processing. But what this actually means is none of the given qubes have a truth-y value for the updates-available feature:

[user@dom0 ~]$ qvm-features debian-12-minimal updates-available
<blank>

This is because I disabled checking for updates in all qubes.

  • Qubes Global Config → Updates → Check for qube updates
  • Or for each qube: qvm-service --disable <qube> qubes-update-check

The workaround is to specify the new --force-update flag:

[user@dom0 ~]$ qubes-vm-update --force-update --templates
# (Updates now happen as normal)
1 Like

That’s strange.
I’ve also disabled checking for updates in all qubes and updates-available feature is empty:

[user@dom0 ~]$ qvm-features debian-12-minimal updates-available
<blank>

But I can update the debian-12-minimal template without --force-update option:

[user@dom0 ~]$ qubes-vm-update --targets debian-12-minimal
debian-12-minimal (no updates):   0%|                                                                                                                            | 0/100 [00:25<?, ?it/s]

Hmm, interesting, thanks.

Ok, looks like the logic also includes a staleness check defaulting to 7 days:

[user@dom0 ~]$ qvm-features debian-12-minimal last-updates-check '2024-07-24 00:00:00'
[user@dom0 ~]$ qubes-vm-update --targets debian-12-minimal
No qube selected for update
# Change last update timestamp to a month ago
[user@dom0 ~]$ qvm-features debian-12-minimal last-updates-check '2024-06-24 00:00:00'
[user@dom0 ~]$ qubes-vm-update --targets debian-12-minimal
debian-12-minimal (updating):   0%

It works for me with recent last-updates-check. The last-updates-check feature is updated after every template update and I can successfully run qubes-vm-update --targets debian-12-minimal in succession.

Hmm! Could you share your version of qubes-core-dom0-linux?:

[user@dom0 ~]$ dnf info qubes-core-dom0-linux
Installed Packages
Name         : qubes-core-dom0-linux
Version      : 4.2.26
Release      : 1.fc37
Architecture : x86_64
Size         : 373 k
Source       : qubes-core-dom0-linux-4.2.26-1.fc37.src.rpm
Repository   : @System
From repo    : qubes-dom0-cached
...

I had old package version:

Installed Packages
Name         : qubes-core-dom0-linux
Version      : 4.2.23
Release      : 1.fc37
Architecture : x86_64
Size         : 357 k
Source       : qubes-core-dom0-linux-4.2.23-1.fc37.src.rpm
Repository   : @System
From repo    : qubes-dom0-cached

I’ve updated to the latest package version and now I have the same update behavior.

1 Like

Thanks. I felt it might have been a new change of behavior but I wasn’t sure.

Yes. That’s it. If you use the GUI updater you’ll the this feature in practice. Some templates will be marked as “MAYBE” having updates.

The reason why this exists (I think) is that templates know you have updates because opportunistically when you run an app qube, it checks for updates and if it has updates, its template has updates as well. Therefore, it marks the template as having updates.

There are two cases where this staleness check is useful:

  1. when no qube based on it has internet connection (e.g. if your vault is the only qube based on debian)
  2. for templates whose app qubes you haven’t started in a long while - the first time you start them after that they would be without updates

You can use --force-update to force updates regardless of the situation.

You can change this setting via the updater GUI application by clicking on the :gear:. The minimum is 1 day.

1 Like