Problems with Fedora templates

User Support
1

I’m trying to apply a Salt state to a template cloned from the fedora-40 templates in 4.2, and get the following error. The state file is simple, as follows:

deb-dev-packages.installed:
  pkg.installed:
    - pkgs:
      - autoconf
      - automake
[...]

Note I had a similar error in 4.1 when updating the fedora-39 template, whereas in the 4.2 case updating the template with qubes-update-gui does not show that error.

This seems a bit similar to Error updating fedora-39-minimal, but it would be strange that the official templates would lack such a dependency?

[root@dom0 ~]# qubesctl --show-output --skip-dom0 --targets=fedora-40-dev state.apply qvm.fedora-dev
fedora-40-dev:
      ----------
      _error:
          Failed to return clean data
      retcode:
          1
      stderr:
          Traceback (most recent call last):
            File "/var/tmp/.root_dd8a91_salt/salt-call", line 27, in <module>
              salt_call()
            File "/var/tmp/.root_dd8a91_salt/pyall/salt/scripts.py", line 438, in salt_call
              import salt.cli.call
            File "/var/tmp/.root_dd8a91_salt/pyall/salt/cli/call.py", line 3, in <module>
              import salt.cli.caller
            File "/var/tmp/.root_dd8a91_salt/pyall/salt/cli/caller.py", line 12, in <module>
              import salt.channel.client
            File "/var/tmp/.root_dd8a91_salt/pyall/salt/channel/client.py", line 13, in <module>
              import salt.crypt
            File "/var/tmp/.root_dd8a91_salt/pyall/salt/crypt.py", line 26, in <module>
              import salt.payload
            File "/var/tmp/.root_dd8a91_salt/pyall/salt/payload.py", line 12, in <module>
              import salt.loader.context
            File "/var/tmp/.root_dd8a91_salt/pyall/salt/loader/__init__.py", line 23, in <module>
              import salt.utils.event
            File "/var/tmp/.root_dd8a91_salt/pyall/salt/utils/event.py", line 67, in <module>
              import salt.ext.tornado.iostream
            File "/var/tmp/.root_dd8a91_salt/pyall/salt/ext/tornado/iostream.py", line 41, in <module>
              from salt.ext.tornado.netutil import ssl_wrap_socket, ssl_match_hostname, SSLCertificateError, _client_ssl_defaults, _server_ssl_defaults
            File "/var/tmp/.root_dd8a91_salt/pyall/salt/ext/tornado/netutil.py", line 57, in <module>
              import backports.ssl_match_hostname
          ModuleNotFoundError: No module named 'backports'
          [ERROR   ] An un-handled exception was caught by Salt's global exception handler:
          ModuleNotFoundError: No module named 'backports'
          Traceback (most recent call last):
            File "/var/tmp/.root_dd8a91_salt/salt-call", line 27, in <module>
              salt_call()
            File "/var/tmp/.root_dd8a91_salt/pyall/salt/scripts.py", line 438, in salt_call
              import salt.cli.call
            File "/var/tmp/.root_dd8a91_salt/pyall/salt/cli/call.py", line 3, in <module>
              import salt.cli.caller
            File "/var/tmp/.root_dd8a91_salt/pyall/salt/cli/caller.py", line 12, in <module>
              import salt.channel.client
            File "/var/tmp/.root_dd8a91_salt/pyall/salt/channel/client.py", line 13, in <module>
              import salt.crypt
            File "/var/tmp/.root_dd8a91_salt/pyall/salt/crypt.py", line 26, in <module>
              import salt.payload
            File "/var/tmp/.root_dd8a91_salt/pyall/salt/payload.py", line 12, in <module>
              import salt.loader.context
            File "/var/tmp/.root_dd8a91_salt/pyall/salt/loader/__init__.py", line 23, in <module>
              import salt.utils.event
            File "/var/tmp/.root_dd8a91_salt/pyall/salt/utils/event.py", line 67, in <module>
              import salt.ext.tornado.iostream
            File "/var/tmp/.root_dd8a91_salt/pyall/salt/ext/tornado/iostream.py", line 41, in <module>
              from salt.ext.tornado.netutil import ssl_wrap_socket, ssl_match_hostname, SSLCertificateError, _client_ssl_defaults, _server_ssl_defaults
            File "/var/tmp/.root_dd8a91_salt/pyall/salt/ext/tornado/netutil.py", line 57, in <module>
              import backports.ssl_match_hostname
          ModuleNotFoundError: No module named 'backports'
      stdout:

With the idea of adding the seemingly-missing package, I went the following way, and I’m puzzled by apparently not having the official QubesOS key registered in the official Fedora template - and the forum search on feels strangely silent for something I had already noticed quite some time ago. What is wrong here?

[root@dom0 ~]# qvm-run -p fedora-40 "dnf search backports"
Fedora 40 - x86_64                              5.4 MB/s |  20 MB     00:03    
Fedora 40 openh264 (From Cisco) - x86_64        1.3 kB/s | 1.4 kB     00:01    
Fedora 40 - x86_64 - Updates                    2.7 MB/s | 9.8 MB     00:03    
Qubes OS Repository for VM (updates)            2.1 kB/s | 833  B     00:00    
Qubes OS Repository for VM (updates)            2.3 MB/s | 2.4 kB     00:00    
Importing GPG key 0x8E34D89F:
 Userid     : "Qubes OS Release 4.2 Signing Key"
 Fingerprint: 9C88 4DF3 F810 64A5 69A4 A9FA E022 E58F 8E34 D89F
 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4.2-primary
Is this ok [y/N]: n
Qubes OS Repository for VM (updates)            2.3 kB/s | 833  B     00:00    
Error: Failed to download metadata for repo 'qubes-vm-r4.2-current': repomd.xml GPG signature verification error: Signing key not found
[root@dom0 ~]#

I don’t like accepting the key in the template, but I can reinstall it later. That search does not seem to give anything like what I’d expect. Can anyone shed light on what Salt is expecting and why it does not work?

2

Did you try to set fedora-40 as template for default-mgmt-dvm qube (or the qube that is set as management_dispvm qube)?

3

Following the advice in the reply to the linked post (with either fedora-40 or fedora-40-xfce) will not work as they are not dvm templates.

[root@dom0 ~]# qubes-prefs management_dispvm fedora-40
[root@dom0 ~]# qubesctl --show-output --skip-dom0 --targets=fedora-40-dev state.apply qvm.fedora-dev
fedora-40-dev: ERROR (exception template for DispVM (fedora-40) needs to be an AppVM with template_for_dispvms=True)

I do have a fedora-dvm template however, and using setting global management_dispvm indeed works, but that really looks like a workaround, so I’d rather set this only for that template I need to act on.

However, that rather looks like a workaround (due to regression inside the qube IIUC), so rather than making it the default I’ll set it on the relevant qube.

4

By default the management_dispvm is set to default-mgmt-dvm disposable template. So you need to change the template of default-mgmt-dvm qube.
You can use qvm-prefs CLI tool or Qubes Template Switcher GUI tool for this.

5

Oops sorry I had removed some text by mistake before posting :wink:
Restored the missing last 2 paragraphs.

6

There is a hidden default-mgmt-dvm disposable template that you don’t see in the Qubes menu that is used for salt management, so you need to change it’s template.

7

Not necessarily, I’m really set on using Fedora in the least possible amount. So I’m leaving the default-mgmt-dvm be debian12, and I’ll just use a fedora dvm specifically for this specific task.

Still, I’m surprised the VM updating, which was impacted in 4.1, works as-is in 4.2. Did it migrate away from using Salt?

8

I think the default-mgmt-dvm qube by itself is not used anywhere, it’s only used as management_dispvm. So if management_dispvm is set to some other disposable template then default-mgmt-dvm won’t be used for anything.

Yes:

1 Like