No worries. It was more of me asking if a solution had been found for something identified earlier in this thread. I realized it might be partially self inflicted because of my misunderstanding on cacher role. Either way I’ll create new thread as requested. Thank you.
You still haven’t said what the problem is.
No need for a new thread - if you cant split this off to a new thread,
one of the @mods can.
My bad, I didn’t want to muddy the conversation here. The TLDR was that I started having apps that I was installing from your tool not work from the start with the easiest example of like for like issues was with the openvpn qube. It basically wasn’t working, was missing some of the services mentioned it should have, and was prompting for a password to do anything on it.
During my troubleshooting though I realized that I also wasn’t doing things when I was adding templates like updating sources for devices / templates for the cacher. I was just doing things as I was before installing that and read that wasn’t the correct process. I’m still relatively new to the Qubes ecosystem, but am fascinated with the potentials of the platform. I’ve actually scrapped that build and am working through trying to get a detached /boot version going now, so this isn’t an issue, but I didn’t really fix it either. I just keep realizing there is more to wrap my head around regarding the bigger picture of how it works and trying to learn but trying to avoid bad habits or cutting corners. I do appreciate the follow up but I didn’t open any other threads and just moved onto a different set of problems unrelated but also probbaly the me needing to find right document one.
The monero wallet set of qubes does not work.
I tried installing it via this tool on a fresh Qubes 4.1.2 install. Once monerod fully synced with the network, I opened monero-wallet-ws and attempted to open a wallet. It fails to connect to the daemon.
Thank you for that feedback.
I will see what the issue might be.
1 Like
Can anybody point me to the solution, if there’s one…
Issue still is, that since I installed cacher on my system (4.1.2) the fedora (35, 36, 37) qubes didn’t update anymore (or at least updating with errors).
I understand, that this issue still wasn’t fixed yet (or whatever the problem is, clouldn’t be fixed yet).
Question now is:
Will I be able to update the Fedora qubes again, by uninstalling the complete qubes-task.manager ?
@unman ? @anyone ?
You never have to use the cacher for your Fedora templates (for any templates really, using the cacher is always optional).
Assuming they’re currently set up to use the cacher, there are two aspects to ensure they don’t anymore:
- Set the source of updates to some other qube than the qube that provides caching in your setup, e.g.
sys-whonix. This way, updates will be downloaded from that qube instead of the cache. - Edit the repository configuration in each of your templates to use
https://instead ofhttp://HTTPS///(quoting from memory). Doing it manually can be tedious, but @unman’s repository contains a script to do that.
Does this informatiom make sense to you @TheGardner ?
1 Like
Thats a plan! Will try this out!
Looks like there’s a config on every qube, where you can setup the source of updates separately. Always was thinking, you do that globally (with the update qube in qubes settings [which is sys-whonix on my setup])
Two cents advice: start with one, and repeat one you’ve got the process right 
There are few things more annoying in my experience than troubleshooting a process that didn’t go right n times in a row instead of only once!
Yes - I’ve been tweaking the Fedora config to get those updates working.
Almost invariably the issue arises with the “updates” repository, and I
think that it relates to incorrect mirroring of the updates repo across
the mirrors. If I clear the cache (dnf clean all), and retry later,
updates usually work.
Whether you use cacher is determined by an entry in
/etc/qubes/policy.d/30-user.policy
The entry is this:
qubes.Updates.Proxy * @type:TemplateVM @default allow target=cacher
You can override this by inserting a line ABOVE this one, because policy
is applied to the first match.
qubes.Updates.Proxy * fedora-37 @default allow target=sys-net
This will mean that fedora-37 uses sys-net for updates, while all other
Templates use cacher.
Make any other changes you want.
(If you want to stop using cacher all together you can just delete the
cacher line, and then policy will revert to the default in 90-default.policy
using sys-net.)
When you set up cacher, repository definitions were rewritten to allow
for use of HTTPS repositories.
If you want to use something other than cacher you need to revert these
changes. There is a salt file in /srv/salt/cacher to help you do this.
You apply it like this:
sudo qubesctl --skip-dom0 --targets=TARGET1,TARGET2,TARGET3 state.apply cacher.restore_templates
This file will revert the changes in Debian based, Fedora and Arch templates.
If you inspect the restore_templates.sls you should see that it
replaces patterns in the repository definitions.
The process is (should be) relatively straightforward.
I never presume to speak for the Qubes team. When I comment in the Forum or in the mailing lists I speak for myself.
4 Likes
I have installed the @unman software successfully and proceeded to install the MullvadVPN package. It created two Qubes (template-mullvad and MullvadVPN). I received no errors during installation. It says in the instructions I should look for a menu entry called “Setup Mullvad VPN” in the Qubes Menu. I checked both those Qubes in the menu and none had an entry for “Setup Mullvad VPN” (and yes I refreshed to make sure).
What has gone wrong?
bump… any help on this?
@unman Thanks for your work on this 
Would you be interested in implementing a salt package to install BusKill? The BusKill installation process requires some changes to dom0 and sys-usb.
1 Like
BusKill looks fantastic
1 Like
Mullvas vpn package is missing fails to download
Indeed, the good folk at Mullvad were kind enough to send me updated
credentials, and I have built an updated package for the new version, and the
browser.
Unfortunately, for reasons, I have not yet been able to upload a new signed
package.
I dont share your enthusiasm, but others like it, and it should be a straightforward
package.
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
1 Like
I switched to the OpenVPN tool since Mullvad is not currently available. With the default sys-vpn that the Tool creates, I have no problem getting connected to a Mullvad OpenVPN.
However, if i create a new sys-vpn2 based on the same template (and also give networking access) following the exact same process that VM fails to connect to the VPN also no pop-ups or notifications saying its even trying.
The only way I can get a new sys-vpn is to clone the original. That works fine.
When creating a new sys-vpn AppVM based on a template is some additional things you need to do to get it to work?
Also these sys-vpn takes 3+ minutes to shutdown or reboot is that normal?
unman,
Thanks loads for your contribution to help users with qubes setups.
I used your system for 4.1 (pi-hole, sys-vpn, cacher) but now with 4.2 things don’t seem to install. Maybe the switch to nftables and newer zen hypevisor difference? I would rather not go back to 4.1.
Will you be updating your templates to use 4.2 in the near future?
Thanks for all the work and help.
4 Likes