Thanks for your reply. That appears to be working.
So, what I am getting is that to install the new template I have to run the dom0 update as well as the template install as one command? I think that due to time I initially updated dom0 and then later came along and tried both
sudo qubes-update-fedora-36 and
qubes-update-fedora-36
And this is where I got the error. So, they must be run together I gather.
Either way its installing without a problem as I type so that must be the issue.
I had no idea that was an issue so thanks for that.
qubes-dom0-update is the name of a program that allows to install and update software packages
sudo allows to run that program with higher privileges (that’s required to install and update software packages)
qubes-template-fedora-36 is the name of a software package that provides the fedora-36 template for Qubes OS
The entire command installs that package.
If you were to run the qubes-dom0-update program without specifying which software package you want to install or update, then the program would by default update all the packages that are already installed. Does that make sense?
Since sudo is required, the entire command would be:
sudo qubes-dom0-update
Note that qubes-dom0-update is what that program happens to be called, nothing more. The fact that the name contains dom0 doesn’t have any particular effect on what the program does.
As far as I know, neither qubes-template-fedora-36 or qubes-update-fedora-36 are programs that exist in a standard Qubes OS installation. The errors you see are very likely Qubes OS telling you that those command were not found (because they don’t exist). Does that match what you see?
If you were to run the qubes-dom0-update program without specifying which software package you want to install or update, then the program would by default update all the packages that are already installed.
Blockquote
If “qubes-dom0-update” updates everything, what does
" qubesctl --show-output state.sls update.qubes-dom0"
do differently? (besides showing output)
That is, as you probably know, a salt call.
You can see the relevant state in /srv/formulas/base/update-formula/update
It’s relatively simple.
# Migrate to new onion repositories automatically, even if the user modified
# the repository file (in which case rpm do not automatically replace it)
/etc/yum.repos.d/qubes-dom0.repo:
file.replace:
- pattern: sik5nlgfc5qylnnsr57qrbm64zbdx6t4lreyhpon3ychmxmiem7tioad
- repl: qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad
- bufsize: file
/etc/yum.repos.d/qubes-templates.repo:
file.replace:
- pattern: sik5nlgfc5qylnnsr57qrbm64zbdx6t4lreyhpon3ychmxmiem7tioad
- repl: qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad
- bufsize: file
update:
cmd.run:
- name: |
if qubes-dom0-update --quiet --assumeyes --clean --action=clean expire-cache >/dev/null 2>&1; then
echo "result=True comment='Cache cleaned'"
else
echo "result=False comment='Could not clean cache'"
fi
- stateful: True
pkg.uptodate:
- refresh: False
Apart from the first 2 sections, which make sure that the right onion
addresses are used, you can see that the update section tries to clean
the cache before making sure that all packages are at the most recent
version.