Qubes dom0 script to update all templates sequentially, avoiding Qubes Update bugs and saving RAM

User Support General
1

Warning: Updating with direct commands such as dnf update and apt update is not recommended, since these bypass built-in Qubes OS update security measures. Instead, we strongly recommend using the Qubes Update tool or its command-line equivalents, as described in the docs: How to update.

It’s a script intended to be placed in /bin on dom0 so that, just by typing a command in the dom0 terminal, you can start updating every template currently present in the system. It can be run with sudo ./updater.sh! The script updates the templates one at a time, not several simultaneously. The problem with Qubes’ built‑in updater is that it opens a bunch of templates perhaps four or five at once consuming a lot of RAM. Moreover, it fails many times, and the usual fix is to open each template manually and run sudo apt update and sudo apt upgrade.
What the updater.sh script does is exactly that, but it iterates over each template and executes:
qvm-run <template_name> “sudo apt update && sudo apt upgrade”
One template at a time, so it doesn’t hog memory the way Qubes Update does! Users with limited RAM or who are already using a lot of RAM can run the updater without heavily impacting their system.

How to install
Download the updater and updater.sh shell scripts from

Example using the vault AppVM, assuming your Qubes user name is user:
In the default vault AppVM, create a folder called scripts under /home/user/ → /home/user/scripts.
Copy updater and updater.sh into that scripts folder.
Turn the scripts folder into a tar archive:
tar -cvf scripts.tar scripts/
Open a terminal on dom0 and transfer the archive into the vault AppVM:
qvm-run --pass-io vault ‘cat “/home/user/scripts.tar”’ > /home/user/scripts.tar
Extract the archive on dom0:
tar -xvf /home/user/scripts.tar
Make the scripts executable:
sudo chmod +x scripts/*
Move the updater script to /bin:
cd scripts
sudo cp -r updater /bin

Usage
From anywhere in the dom0 terminal you can now simply type:
updater
…and it will update all templates one by one.
Alternatively, you can run it directly with:
sudo ./updater.sh inside /home/user/scripts

2

I put a warning at the beginning because the method proposed has many drawbacks:

  • Qubes Updater has a setting to achieve the same result
  • use of direct apt upgrade command: discouraged and only with debian-based templates
  • no exit code check
  • no use of the Qubes API (qvm-ls)
  • why copying the files in dom0 via vault???
6 Likes
3

Sloppy, this:

    # 2️⃣ sudo apt update && upgrade in template
qvm-run "$qube_name" "sudo apt update -y"
qvm-run "$qube_name" "sudo apt upgrade -y"

Also emojis in the script wtf

Too bad there aren’t downvotes in discourse

5 Likes
4

You can configure it to start a single template at a time.

3 Likes
5

This makes your script obsolete, except if I overlooked a feature ?

2 Likes
6

I think that the result is the same as:

sudo qubes-vm-update --templates  --force-update --max-concurrency 1

But without error and progress logging and failing for any template not using apt.

4 Likes
7

You have flags as:

--log LOG 	Provide logging level. Values: DEBUG, INFO (default), WARNING, ERROR, CRITICAL
--dry-run 	Just print what happens
--quiet, -q 	Do not print anything to stdout
--show-output, --verbose, -v
 	Show output of management commands

So you can troubleshoot and follow for errors.

1 Like
8

:robot:

9

Maybe i missunderstand something but… Qubes already update all vm without any bugs no? Or i missed something ?

1 Like
10

You right, QubesOS have build-in distro universal patch management tool called “Qubes Update”.
And here documentation about it:

1 Like
11

I already know but what i did not understand is why he created a script to do something already done by Qubes ?..

12

Presumably because OP did not understand that this is already
available. It’s behind the “Settings” button, and perhaps they did not
try that.
There’s no man page but qubes-update-gui --help does show the
available options.
I’d say it’s a deficiency in GUI and documentation. This thread may help
others find the setting.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

3 Likes
13

Perfect! In the dom0 terminal, qubes-update-gui opens a graphical interface showing all the templates. In the gear icon (Settings) there is an option that can be configured to update one template at a time instead of four simultaneously, which consumes more RAM; users with little RAM may encounter problems updating and continuing other activities in Qubes.
In Settings there is the option “Limit how many Qubes can update at the same time.” By default it is set to 4, but the ideal setting for low‑RAM systems is 1.
I didn’t mention in the post that the script works only for Debian templates. I only use Debian and don’t use Fedora. I forgot to note that; sorry about that.
As I said in the post, the reason I created this script was that, when using the Qubes Updater, many updates failed, especially on dom0. The issue was solved by manually entering the template, opening a terminal, and running:
sudo apt update -y
sudo apt upgrade -y
To update dom0, you also had to go to the dom0 terminal and run qubes-dom0-update. Using these methods I could update without problems, which is why I developed the script, but it works only for Debian templates.
Is anyone else experiencing the same problem of failed updates through the Qubes Update graphical interface?

14

Works perfectly… thanks
sudo qubes-vm-update --templates --force-update --max-concurrency 1
without errors!

15

I moved the thread outside the community guides category.

1 Like
16

@parulin Could you please elaborate on this?

I followed the link to the warning note / description:

I see there are some useful error messages but I do not see security measures.

Could you please point out where the security measures are documented, or explain what kind of protection they provide? Thanks

1 Like
17

I can’t. That’s just a copy-paste from the docs. I don’t really understand. I took a look at update.qubes-vm but I can’t see any current “built-in security measures”. It might have been the case previously? So, even if there are currently no security measures, it might be the case in the future?

Anyway, I think it’s better to stick to the official API. Maybe this warning is too dramatic in this context, but I wasn’t convinced by providing this script as a community guide and I was looking for a quick way to tell users about this, thus the copy-paste.

1 Like
18

I feel this is true, but I add a UI experience from last week: Output when an update fails seems not clear.

For me, during gui-update, one Debian template failed to update, and showed the red X.
The detailed output pane was very difficult to interpret, and certainly did not give me any clear indication of how/why it had failed.

Some simple higher level diagnostic message -after the raw output- would be really nice.

Does this mat wit anyone’s experience?

(I am wondering: Is there some acceptable possibility for parsing/grepping of apt/dnf output for the final cause of failures AND/OR of journal, to spot problems like OOM murder events that happen during the process? I am assuming this must happen inside the Template, and then get sanitised for display.)

Stupidly, I did not save the output, suspecting a networking problem, and next update was OK.

19

After a little testing with qubes-vm-update, I find that more useful information is in /var/log, except that there is no strerror/ text description of the meaning of the exit code, as described in man qubes-vm-update.

The gui display panel shows only a part of the output of qubes-vm-update -v. This is not as useful, and could easily lead to frustration.

Even if the qubes-vm-update log is provided by the gui, I suspect that some common errors may still only yield very general message.

(Test was to set sys-firewall netvm to “none” and use different update methods. There are other potential tests.)

20

The command sudo qubes-vm-update --templates --force-update --max-concurrency 1 does not always work. It fails for some templates. For example, out of 10 templates, it successfully upgrades templates 1 to 4 but fails on 5, 6, and 7, although it upgrades the rest.

The solution is to upgrade manually or use a script; however, the author should include an option to upgrade Fedora templates as well. Currently, the script only works for Debian templates, while Whonix Gateway and Workstation function correctly.

The GUI tool, Qubes Updater, also fails, just like the command line with sudo qubes-vm-update --templates --force-update --max-concurrency 1.