Hello,
Because my current mullvad-vpn qube in fedora 41 is no longer supported, I decided rather than have to reconfigure things again through a new template (current fedora 41 appvm suddenly got a case of unexplained ‘curl being unable to resolve dns’ 
when I tried to upgrade in place) to move forward and capitalize on unman and mullvad support’s work and implement @unman 's 3isec packaging from github using debian-13-minimal rather than upgrade fedora.
Knowing absolutely nothing about managing anything with ‘salt’, I first reviewed salt and yaml basics so I might review the github code and have a basic idea of how the updating was to work before installing in addition to what was actually taking place codewise.
I decided to use the ‘qubes-task-gui’ to do this and the setup of that all worked great! I did a quick bkp of dom0 and then did the install of the mullvad-vpn with the gui. Things appeared to be ok…almost. 
The update summary was: Succeeded: 9 (changed 4) Failed: 1.
Reviewing the errors indicated: a problem calling 'state.apply mullvad.configure…sys-mullvad. Result: False Comment: Source file salt://mullvad/set_forward.sh not found in saltenv ‘base’.
This error occurred on creating both /rw/config/qubes-firewall.d/set_forward.sh and /rw/config/network-hooks.d/set_forward.sh files.
Also Source file salt://mullvad/update_dns.nft not found in saltenv ‘base’ for creating /rw/confi/qubes-firewall.d/update_dns.nft
However in checking /srv/salt/mullvad both those files exist and both have permissions of -rwxr-xr-x owner root:root and the contents match what is in the files on github.
When I checked the gui settings for the template-mullvad that got created in the process, it reflects that the mullvad-browser.desktop and mullvad-vpn.desktop are both missing and subsequently they are also missing in ‘mullvad-dvm’ and ‘sys-mullvad’.
Unless I read incorrectly, these missing changes would only occur in sys-mullvad so in checking sys-mullvad in the /rw/config directory neither directory qubes-firewall.d, nor network-hooks.d existed. So of course neither does set_forward.sh nor update_dns.nft exist. (I did check about the /rw/config/qubes-bind-dir.d/50_user.conf and that was appended as reported in the log.) So I have several questions in order to complete the setup. Is the fix:
- Create the 2 directories: qubes-firewall.d and network-hooks.d in /rw/config and…
- copy set_forward.sh over to sys-mullvad into the /rw/config/qubes-firewall.d directory and the /rw/config/network-hooks.d directory AND also copy update_dns.nft to the /rw/config/qubes-firewall.d directory?
- What should the permissions on the newly create directories and the scripts be set to?
- What might be the solution to getting the mullvad-vpn and mullvad-browser .desktop files enabled? Refreshing applications in the gui did not enable them.
- Lastly, any ideas on why the files appear on /srv/salt/mullvad in dom0 but didn’t apply and said missing instead? Was it because the directories did not exist on sys-mullvad? Was it implied that the process would create them prior to copying them from /srv/salt/mullvad, or was the salt path incorrect? I did not catch exactly how the salt file structure works when defined in yaml. Does salt: //mullvad equate to /srv/salt/mullvad (which exists) or rather /srv/mullvad (which doesn’t exist)??
Anyone else run into this?
Thanks for taking a look at this!!
Followup:
I moved ahead and manually created the 2 missing directories in /rw/config and moved the files as well. Permissions are listed in the configure.sls file so set these to 755. This part should be done.
Moving on to the missing applications. I booted up the template-mullvad and checked apt for mullvad-browser and mullvad-vpn. Neither were there. I checked the mgmt-template-mullad.log for further issues and found an issue regarding the mullvad keyring missing.
Error is as follows:
Comment: An error was encountered while installing package(s):
W: OpenPGP signature verification failed: httpss://repository.mullvad.net/deb/stable trixie InRelease:
Sub-process /usr/bin/sqv returned an error code (1), error message is:
Error: Failed to parse keyring “/usr/share/keyrings/mullvad-keyring.asc”
Caused by: 0: Reading “/usr/share/keyrings/mullvad-keyring.asc”: No such file or directory (os error 2)
1: No such file or directory (os error 2) output:
E: The repository: //repository.mullvad.net/deb/stable = trixie InRelease is not signed.
This was followed by the errors for mullvad files not in the salt-env base. This seems to explain the missing applications shown by the application missing errors shown in the gui applications settings tab.
Moving on I came across an older somewhat similar post from June 2023 where a user had the error: ‘user’ not available during this same process and he stated he had used a non-standard user name in dom0 with the implication that I got from the post was that doing so broke the process or at least threw errors. This may be so because I also noticed those same errors which at the time I hoped were just benign like many errors in Linux are but which instead might explain the earlier missing directories and files for /rw/config. However, I did not see any other notification that they weren’t copied.
When installing Qubes long ago, not knowing that setting a username other than ‘user’ might break things, I also had set a username other than ‘user’ being a newbie and not knowing it was going to dom0 and not fedora. I would venture a guess that many people do this. So if that is truly an issue, it might be nice to use a variable in the salt scripting getting the actual username used in dom0 maybe rather than assuming ‘user’?? Maybe it isn’t even related, I’m not sure at this point…
Anyways I need to find the time to fill in the remaining missing files and see if things resolve to get this up and running. The reason, I chose to use this route to create the mullvad-vpn qubes was to avoid some of the configuration hassle but—unfortunately it didn’t quite go as intended…
So this is a great option available to use as well as the 3isec qubes package.