Fairly frequently (~10% of the time) the updater doesn’t finish updating for some reason…and there’s no graceful way to quit it.
Because if you try to quit it, it assumes you’re trying to cancel the update, and won’t let you do that until whatever it’s working on is finished. Which of course, it never will.
Right now I am looking at it having spent the last ten minutes on an update…and it hasn’t even started the template! (And no, it’s not queued, or shouldn’t be…it’s the only qube left.)
Is there something better to do in such cases than going out and doing a ps -flea and killing processes?
Few things are more infuriating than a program that refuses to shut down because it thinks it knows better than me.
Don’t use the updater. It’s convenient, but as you note, tends to have problems if things don’t go smoothly.
I just update dom0 and all my templates manually.
qubes-dom0-update in a dom0 terminal.
sudo apt update && sudo apt dist-upgrade -y in my Debian templates.
do-upgrade-nonroot in Whonix templates.
If something fails, you can usually just run the command again and it’ll resume - I’ve had problems in the past with Spotify’s repo closing connections before the full file is downloaded, breaking the update, but if you try again, it resumes and gets the full file. The same goes for some of the Whonix updates - sometimes the Tor circuits are just flaky and don’t work right, but if you try again it’ll grab a different circuit and be fine.
And then close them, restart what’s needed, and go on my way.
This sounds like a bug that should be reported (if it hasn’t already been).
I use the command-line equivalents instead of the GUI tool (personal preference) and haven’t noticed any such problem. Perhaps you could try them instead.
Other than that, the only simple workaround I can think of is to restart the system, which is inconvenient.
I agree it’s a bug, but it’s intermittent and I have no idea what I could say other than “sometimes this damn thing doesn’t work and it won’t let me quit.” And then there will just be a flood of “gee it never happens to me” and it will likely be closed.
Quite possibly the best/most viable solution would be a “force exit” control, with a confirmation dialog.
(Another feature I’d want to add, BTW is the ability to, on completion, “go back” all the way to the initial screen, in case I only updated SOME of the packages, or want it to check more packages where the update status is unknown. To do this now, I have to let the app exit and restart since go back only takes you back one screen.)
As for the command line:
So, to clarify for anyone else reading this,
DON’T do sudo apt dist-upgrade -y in Debian templates (and the analogous fedora command).
but rather DO use salt and apply the update.qubes-vm state.
(Side note: this is a pain in the butt, because the full command would be something like: sudo qubesctl state.apply update.qubes-vm --skip-dom0 --target <qubename> which is quite a keyboard full and I probably got it wrong.)
As a matter of fact, I USUALLY do run salt to do updates, but because that command line IS such a pain in the butt, I have a script named “update-tmpls-seriatim” which goes through a range of my custom-built templates and invokes update on each of them. (This works because my salt files are numbered–the qubes aren’t, but the files are, and there’s some relationship between the numbering and the “tree” of template clones. I can get qube names from salt numbers because it’s all described in the user pillar.) In this particular case it was one template and I had to open the tool to find out what it was, so I opted to use it to do the update. Never again!
I’m sorry but NO, you cannot do this. As the topic is not marked “R4.2 only”, it should apply to the currently supported R4.1 too. And R4.1 does not have qubes-vm-update.
That’s fair. What’s the actual difference in commands run/the potential issues avoided? The output from the updater implied the normal apt commands were used, at least to me.