There are two ways to upgrade your template to a new Debian release:
Recommended:Install a fresh template to replace the existing one.This option may be simpler for less experienced users. After you install the new template, redo all desired template modifications and switch everything that was set to the old template to the new template. You may want to write down the modifications you make to your templates so that you remember what to redo on each fresh install. In the old Debian template, see /var/log/dpkg.log and /var/log/apt/history.log for logs of package manager actions.
For a complete list of template releases that are supported for your specific Qubes release, see our supported template releases. Please note that no user action is required regarding the OS version in dom0 (see our note on dom0 and EOL).
Hmm, I think 4.1 doesn’t retry download from alternative mirrors, and the first one on the list (mirrors.kernel.org) hasn’t fetched the package yet. I think it should appear there about 22:00 UTC…
Alternatively, you can edit /etc/qubes/repo-templates/qubes-templates.repo in dom0 and temporarily comment out metalink= entry and uncomment the baseurl= one
Another issue I’ve run into while upgrading my templates is that the qubes-contrib repo is missing for bookworm in r4.1. There is a bookworm-testing repo for r4.2.
I’ve noticed that /etc/apt/sources.list.d/qubes-r4.list once again uses tor+http for Tor repositories. However, if you uncomment those apt will give an error:
E: The method driver /usr/lib/apt/methods/tor+http could not be found.
N: Is the package apt-transport-tor installed?
Since Tor is done by the Whonix qube, shouldn’t the default be http instead of tor+http?
Well, now I get to see if my minimal template management stuff will work as well as I hoped it would when “upgrading” templates.
I’m not going to upgrade the templates; I’m going to generate a parallel set. Their names all begin with deb11*, the new set will obviously start with deb13*. (Just kidding: deb12*, actually.)
[I’ve already found one thing I don’t like about the way it works.]
Well I am using deiban-12 minimal right now. (I cloned it and installed firefox, et.al on a new template, which is the template for this VM.) Should be pretty good if this works, though I have one other use case that’s pretty likely to break if anything will.
REMINDER: this is from using it directly rather than trying to upgrade a deb-11-minimal based template to debian 12.
NOTE: Nevermind, I figured this one out. It’s trying to somehow unpack debian-12 onto dom0 somehow, and there wasn’t enough space. I still want to expand it. It turns out the lion’s share of dom0 is filled with all the stuff that comes with kernels. I have to figure out which ones I can delete and how to do it. Anyhow, for posterity I have not altered the original text of this comment, which starts…NOW:
In trying to get debian-12 (not minimal), I get the following. It is downloading just fine. This is some sort of install glitch.
Installing template 'debian-12'...
tar: ./var/lib/qubes/vm-templates/debian-12/root.img.part.05: Wrote only 512 of 10240 bytes
tar: ./var/lib/qubes/vm-templates/debian-12/vm-whitelisted-appmenus.list: Cannot write: No space left on device
tar: ./var/lib/qubes/vm-templates/debian-12/whitelisted-appmenus.list: Cannot write: No space left on device
tar: Exiting with failure status due to previous errors
ERROR: Failed to extract debian-12 template
qui-disk-space seems to think I have a LOT of space left–in vmpool (less than 100GiB out of well over 300 GiB used). On the other hand, varlibqubes is at 13.9 Gib out of 19.5 GiB. That could be the issue since debian-11 takes up about 6.4 GiB I would imagine debian-12 does too.