Last night I updated my debian and whonix templates (I didn’t pick the dom0 for updating, so it didn’t get updated last night). QubesOS (4.2) updater updated these two templates successfuly. After the update, in the update finished screen in QubesOS updater, I could see some qubes-* related packages got updated in these templates and I inferred that there must be dom0 updates also.
This morning, after starting QubesOS, the updater notification appeared on my xfce4 system tray, saying “Qubes Updates Available!” “Updates for 1 qubes available” “Launch updater”.
When I click on “Launch updater” button from the system tray icon, nothing happens. It is as if I haven’t clicked that, my system doesn’t bring up the QubesOS Updater GUI.
Next, I try launching the updater from the xfce4 start menu: Q icon → cogwheel → Qubes Tools → Qubes Update. No window pops-up. Nothing.
Next, I say, “most QubesOS GUI tools can be started from the dom0 command line,” so I open a dom0 terminal and type the command: qubes-update-gui. My dom0 terminal gets halfway filled with an error log in its stdout, concluding with IndexError: list index out of range.
What’s that all about? Is there a new problem with QubesOS updater? Did I mess up last night by updating the debian and whonix templates first, and not updating the dom0? Any way to resolve this?
After searching the forum for recent relevant issues, I found these topics that are about the same problem as my OP:
One thing with the first link I share here is this:
@alimirjamali I am seeing update availability nofitier in my xfce4 system tray. However, I am still getting no GUI pop-up when I click on the update availability notifier. Please check my OP for details.
In this case, what should I do? You say the If the update availability finds updates to dom0 (or other templates) the update GUI should work when it is clicked on. But in my case, I have the update availability notifier visible on the tray, yet no updater GUI pops-up into action when I click on the updates.
Skipping dom0. To update AdminVM [...]
Following templates and stanalones will be updated: [Lists my templates and standalones]
Following qubes will be updated: [Lists my qubes]
But then no updating happens, I guess as expected by the --dry-run flag.
Should I do this? Or wait for a proper dom0 update to get into the stable QubesOS repos? The second link I posted above to the marmarek’s post seems to refer to this.
The Qubes Update GUI will not crash once that is updated to 4.2.23. It is currently being tested as the update included some other changes and improvements (e.g. Adding warnings for end-of-life templates)
Yes. You could omit --dry-run flag and let it update your templates in the command line. I would do that.
The GUI update adds special flags to dnf (--exclude=qubes-template-*) while updating dom0. This is to assure that the user existing templates with their modifications and installed software are not overwritten. If you use qubes-dom0-update carelessly, your templates might be overwritten.
I will wait for this 4.2.23 to hit the stable repo and become available as an update to me. Then, when that day comes, am I correct to assume that my Qubes Updater GUI will work (that is, when I click on it I will have its GUI visible on my QubesOS desktop)?
And it has been weeks (not “a few days” as they originally said) that this has been hung up in the testing repository.
Meanwhile I am not going to update dom0 until it’s in the regular repository. I only just found out about this problem before doing the update that would have broken it.
Yes. I know. I fully remember you mentioning this in the past. I have the intention to make an informal announcement on Forum once it is moved to regular and mention your account ID.
I also believe that this specific one should have been released to regular sooner.
My main concern with switching to testing repositories is that I might not know when they are no longer needed, and never switch back. (The price I pay is having to hover over the update icon to see if anything other than dom0 needs an update. Normally the procedure is “see icon, do updates.”) This way I at least get a continual reminder that things are still “broken.” (A similar concern is why I haven’t done debian-12 (upstream from us) adjustments to account for the fact that zfs isn’t supported properly in the newest kernel.)
@SteveC I have not forgotten about you. Even-though qubes-desktop-linux-manager v4.2.23 is now in the main stream which fixes the old Updater Starting bug, there has been a lot going on with the vmupdate, updater GUI and systray updater notifier. Marmarta and Piotr (Bartman) has been working on it and did many improvements and fixes. Even I did some contributions. The new version that has to come will be very stable and reliable.
I accidentally updated dom0 a few days ago and the GUI ran well (so I figured, it must have been fixed), and I’ve been able to run it “on spec” (i.e., update a template marked “maybe” to see if it actually has updates–if it does, I have to update many others as well since they are clones of the one I updated).
One issue that the updater has had in the past is sometimes it would just “hang” at 100 percent on a template and never formally finishes, and because you can’t close it while it (thinks it) is updating, I end up having to issue kill -9 on a bunch of processes and even then it’s possible something will be locked and as far as I know, I have to reboot to clear it.
Because of that, most of the time I do “manual” (i.e., command line via a script) updates most of the time, but there are some cases where the Updater is easier (such as for a few templates not part of my automation).
One hopes that the issue is indeed fixed as part of this update. I’ll just have to see if the issue ever arises again.
It seemed more likely to happen if I gave it a LOT of templates to update. Perhaps next time I’ll do everything in the updater GUI to see what happens.