Hi,
I am observing something strange:
user@dom0:~ > qvm-check D13
qvm-check: D13: exists
user@dom0:~ > qubes-vm-update --targets D13
No qube selected for update
I can successfully update the same template through the GUI though.
The only difference between that particular template and others is that it is on a different pool.
Is that a bug?
If not, what is the way to update the template through CLI?
A target is only selected for update if dom0 is already aware that updates are currently available for it because the target (or in case it’s a template: a qube based on it) has informed dom0 of this, causing the updates-available feature to be set.
You can override this with qubes-vm-update --force-update ...
Thanks!
But how does dom0 know if updates are available, considering all templates have update checks disabled?
Usually, qubes based on the template will inform dom0 of available updates for the template. If you’ve disabled the update checks for those qubes too (or there are no such qubes, or they can’t check for updates e.g. because they aren’t running), then you have to pass --force-update.
A qube using that template nay have reported updates available. If you
have disabled update checking, then dom0 does not know.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
Usually, qubes based on the template will inform dom0 of available updates for the template.
Assuming this means AppVMs, I think I am missing some basic knowledge:
If you’ve disabled the update checks for those qubes too
How or why is it possible to enable/disable updates for AppVMs? What is there to update in an AppVM - it holds no system (at least not persistently)?
I understand that but I am still confused why an AppVM should be updatable.
There are three distinct concepts here:
Whether a qube is updateable in principle, as shown by qubesdb-read /qubes-vm-updateable inside the qube. It means that if you install regular package updates, they will persist if the qube is shut down, which is true for TemplateVMs and StandaloneVMs.
Whether dom0 has been notified that there are updates available for a qube, causing dom0 to set the updates-available feature for that qube.
Whether the update check is running periodically in the background inside a qube through the qubes-update-check Qubes OS service (corresponding to a systemd service and timer of the same name). If it is running inside an AppVM (which it is by default for all AppVMs, unless the service was explicitly disabled), it notifies dom0 about (2) for its TemplateVM.
It is possible to update AppVM but any changes made will not persist,as you know.
As far as Qubes is concerned, the AppVM is not updateable but the
template on which it is based is updateable based on a signal
received from the AppVM.
If you update through Tor but use an APPVM on clearnet, then the update
check will run in the clear. You may not want this.
You can disable update checking in the config GUI under
Global Config → Updates → Check for qube updates
The checking is on by default - newly created qubes will have it
enabled. There should be options for this not to occur.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
Thanks for explaining the mechanism. This is what I noticed too:
- Whether the update check is running periodically in the background inside a qube through the
qubes-update-checkQubes OS service. If it is running inside an AppVM (which it is by default, unless the service was explicitly disabled), it notifies dom0 about (2) for its TemplateVM.
Isn’t that incorrect behaviour in an AppVM the template of which has updates disabled? Why waste resources (however minimal) for something that is not desired by the user?
Well, it would be useful to be able to express the high level preference “I want AppVMs based on this particular TemplateVM to default to not running update checks inside of them”, or even a system wide “I want all AppVMs to default to not running update checks inside of them”. But there is currently no way to express either one. I think there’s a recent open ticket for the latter, but I can’t find it. Or maybe it was a forum post?
Disabling the qubes-update-check service on any (Template)VM really just means “I want this (Template)VM to not run update checks inside of itself”. I wouldn’t call it incorrect, it’s just a more low level building block. Edit: It’s also unnecessary to express this low level preference for TemplateVMs, which (in contrast to AppVMs) don’t implicitly enable the qubes-update-check service.
Thanks for sharing your thoughts.
It is possible to update AppVM but any changes made will not persist,as you know.
Exactly. Then why should it even be possible to have an updatable AppVM? I mean - conceptually it makes little sense, unless the user wants a temporary volatile update for the AppVM for whatever peculiar reason but even then: one can run manually e.g. apt-get update, right?
If you update through Tor but use an APPVM on clearnet, then the update
check will run in the clear. You may not want this.
I am aware of that but thanks for the reminder.
What is the way to install a package in an AppVM (knowing that would be volatile) that has a clearnet NetVM but through the system-default Tor update proxy?
Will running the qubes-vm-update on an AppVM that has clearnet NetVM result in a clearnet connection (unlike running apt-get update directly in it)?
The checking is on by default - newly created qubes will have it
enabled. There should be options for this not to occur.
There is more to that: I have noticed that cloning a template that has updates disabled results in an instant update check for the clone. Is that a (known) bug? I may be wrong but I think in 4.2.4 it was not like that.
Enable the updates-proxy-setup Qubes OS service for the AppVM, and add a policy so that it can access the torified qubes.UpdatesProxy.
No that doesn’t make a difference.
What do you mean? Update checks run inside of the VM, and cloning doesn’t start the clone.
Thanks.
What do you mean?
I can’t reproduce it right now but I have noticed what I describe. I may be missing some detail. I will report back if I notice it again.