Hello guys,
I need to disable the update for one qube. How can I make that qube not to appear in Qubes Update?
Best,
Ivan
qvm-features <vm> updates-available ''
or
qvm-features <vm> service.qubes-update-check ''
or
qvm-features <vm> supported-service.qubes-update-check ''
you can check first by typing qvm-features <vm> then make sure the 3 features i mention there is empty value.
3 Likes
To do this from the Qubes Manager, is slightly unintuitive, but the process is:
- Go to Qube Settings for a qube
- Go to the Services tab
- Click the dropdown and select
qubes-update-check - Click the “+” to add the service
- Uncheck the checkbox of
qubes-update-check
(update check will be disabled on next boot/reboot of the qube)
You can also do this for all qubes at once by going to:
- Qubes Global Settings
- Click on
Disable checking for updates for all qubes - Uncheck
Check for qube updates by default
2 Likes
Note that there is a difference between disabling updates and disabling update checking. There is also a difference between disabling updates for a TemplateBasedVM and disabling updates for the TemplateVM on which the TemplateBasedVM is based. There is also a difference between disabling updates for a VM and making that VM not appear in the Qubes Update tool.
Generally speaking, no one should be trying to disable updates for a specific TemplateBasedVM, since that doesn’t make sense. The TemplateBasedVM simply inherits its updates from its TemplateVM. So, you’d want to disable updates for the TemplateVM instead, which would affect all TemplateBasedVM based on it.
Finally, it is not recommended to disable updates for anything, since keeping up with security updates is one of the most important ways to keep your system secure.
1 Like
True, but OP specifically asked about stopping Qubes appearing in the
Update Tool, and disabling update checking helps. It would not stop
templates from appearing in the list but they would be greyed out and
not included in updates by default.
There are a few cases where disabling updates in this way is useful.
First, where you have a copy of the original template and wish to
preserve that in case of disaster.
Second, where some package configuration requires you to use older
packages. This can happen in Debian(e.g) where updating some libraries
will block functionality in a program.
This is another case in which Qubes comes out on top - you can clone
the template you are using and use the cloned template, not updated,
for a particular qube, while all your other qubes benefit from the
security updates.
Probably other cases too.
2 Likes
I followed the instructions above and selected qubes-update-check in the list and disabled the entry for my arch linux template. But I still get always the notification that the template needs to be updated. I don’t know if that is related to the rolling release within arch linux but I want to update this template by myself without the qubes update manager.
I would like to disable both update checks and updates for Windows 7 VMs because 1) Updates for Win 7 are no longer supported; 2) I want the Win VMs to be completely isolated from network. How do I do that?
Set the netvm to none.
Windows 7 qubes don’t participate in update checking.
In general, you can always disable checking on a per qube basis using
qvm-features QUBE service.qubes-update-check 0
When I comment in the Forum or in the mailing lists I speak for myself.
Set the netvm to none.
That is already set.
Windows 7 qubes don’t participate in update checking.
Then why running sudo qubesctl --show-output --skip-dom0 --templates state.sls update.qubes-vm starts the Windows 7 TemplateVMs?
In general, you can always disable checking on a per qube basis using
qvm-features QUBE service.qubes-update-check 0
That seems to disable only update check, not updates (which the above command seems to start for all domUs).
FWIW I also tried qvm-prefs <QUBE> updateable False but it tells me "property ‘updateable’ on TemplateVM instance cannot be set’ (for the moment I have only a Windows 7 TemplateVM).
Is there anything else I can do?
Because that is not update-checking, but updating actually, and of all templates as the command says?
I suggest that you look to see if the Windows 7 template is actually
updated.
I suggest that you look to see if the Windows 7 template is actually
updated.
It is not. It cannot be (as discussed here. Even if it could, I don’t want it to be (at least not automatically with all other VMs through the Salt formula). I would like it and its AppVMs to be explicitly network isolated.
How to do this?
This is answered
You don’t need to, since as you said, updates aren’t available for Windows 7 anymore, which you know:
Next one
This demand is absolutely unrelated to updating / update checking mechanism in Qubes. @unman already answered that this is achievable by setting netVM to none.
Qubes trying to update Windows 7 qube will NOT “un-isolate” it.
What network exactly?
So, your questions obviously aren’t formulated well, try with what goal exactly you are trying to achieve?
You don’t need to, since as you said, updates aren’t available for Windows 7 anymore, which you know:
The problem is that the update process starts the Windows 7 TemplateVM. I don’t want it to start as there is no need for that. That’s why I think it is necessary to block the updates for it. Hence the question.
What network exactly?
Any.
So, your questions obviously aren’t formulated well, try with what goal exactly you are trying to achieve?
Sorry for the confusion. I hope the clarification above is sufficient.
This is absolutely different from the topic’s subjects, and now it’s clear what is your goal.
Now what I don’t understand is, why do you think update process would start Win qube, unless you initiate it yourself specifically in terminal? If you use Qubes Update Tool, you’ll never get a notification to update Win qube, thus the qube won’t be started.
If you prefer to use typing instead of QUT, then I suggest you to create simple script with the argument targets= for the update where you would list all the qubes you’d like to be updated, name it update.sh and instead of typing whole command, run this one simple.
The other way might be this but I didn’t test if --skip-win-qube works as with --skip-dom0. I just have to much templates to list them all and I don’t have such a list. Please don’t say even if it works that it looks more like workaround. Neither --skip-dom0 looks like it isn’t when you want non-dom0 qubes to be updated, but you accepted it as is.
If you prefer to use typing instead of QUT,
That’s my preference, yes.
then I suggest you to create simple script with the argument
targets=for the update where you would list all the qubes you’d like to be updated, name it update.sh and instead of typing whole command, run this one simple.
The problem with that approach is that creating/deleting/renaming qubes would require an update of that script too - something one may forget to do.
The other way might be this but I didn’t test if
--skip-win-qubeworks as with--skip-dom0.
According to man qubesctl there is no such option.
I still hope there is a solution to this.
Well, I’m sure one day we’ll reach the point of giving voice command to Qubes.
Not sure of the relevance here,but this day is already here.
There is relevance actually. When we relate quoted words would require an update of that script too and forgot with voice commanding, then we hope someday we can give some voice commands to Qubes like
“Hello Qubes. I want to skip updates for this and that qube, because I’m lazy to keep on my mind maintaining my script”
or,
“Hello Qubes. I want you to maintain my scripts with newly added qubes”
That’s a level of semantic recognition beyond what is available.
You can have voice recognition and semantic recognition now.
One issue is that many of the best results come from offloading
processing to the cloud. Working with a locally installed engine is more
challenging, but still workable.
This is wildly off topic.
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.