It seems odd that dom0 requires the hardware wifi switch to
be set ‘on’, else it gives “PCI device dom0:01_00.0 does not
exist” error and does not allow any qube to open.
I have not (knowingly) “attached the device to some VM”
as tripleh mentioned in PCI device dom0:03_00.0 does not exist
It isn’t a problem - just have to remember to switch wifi on
before booting up or else I’ll have to shut down, switch it on, and reboot.
Librem14
qubes 4.1.1
Maybe your WiFi is attached to the device list in sys-net, and if it’s not turned on you get an error because it’s missing.
Maybe when hardware wifi switched off it’s about controller to which wifi device is attached to and not wifi adapter itself?
wifi hardware switch must be on for ethernet to work as
well or else the same error - it runs from the cable, the wifi is idle but has to be switched on.
Doesn’t seem to like to work with just ethernet - I’m sure it
will work itself out with v4.2
Lots of confusing information here in replies.
Important info is model of laptop: Librem 14.
The physical design of this laptop makes it different then others: it is a mechanical switch that disconnects the wifi pci device, hence making it nonexistent if switched off.
Consequently: yes, switch needs to be on at boot, otherwise sys-net and app qubes depending on sys-net will fail to start. Switching physical switch at runtime should permit app qubes to start sys-net on-demand though.
Ethernet wired connection will work with hardware wifi switch off as long as it is not switched off until AFTER wired connection has connected - ie. ethernet wired works if librem14 boots up with wifi switch on, but does not work if Qubes boots up with wifi switch off. Once wired connection is up the wifi can be switched off with no ill effect.
That all said, it’d be nice if network-connected qubes would still run without their netvms being up. In that state, of course, it’d be as if the network were absent, which software should be able to cope with–and does.
Switch their netVMs to none on the fly. But, I really hate I cannot restart sys-net to apply updates from it’s template, without shuting down all other VM in the chain above it…
1 Like
…well…duh! I was just assuming you couldn’t change that without shutting down the qube. (After all, every other dependency out there needs a shutdown.) Now I feel slightly foolish.
Agree about shutting down what I call “the stack:” cacher on top of sys-firewall-wifi on top of sys-net-wifi. (And even more entertaining if whonix and/or a vpn qube is involved.) And on the ethernet side there’s another stack: vera-store (part of my split-veracrypt infrastructure; I set it to autostart on boot) on top of sys-firewall-ether on top of sys-net-ether. Of course if I’m planning to (re)build a template in the wifi stack, I have to provide an alternate wifi stack for cacher to connect to. I will automate that process someday…probably soon.
But at least now I know I don’t need to shut off all my running internet-connected qubes while this happens, just temporarily change their netvms either to the alternate stack or to nothing. Thanks!
1 Like
I got Sven’s method to work…and then I tried to automate it in salt. The critical line (after setting all those prefs and attaching the device to the dvm template) is to connect to it with nmcli.
Try as I might, I can’t get that to “stick” via qvm-run. The network manager must be running; OK so my command reads wait 2; <start network manager; wait 15; ; wait 15. And then I shut the dvm template down, and undo all the prefs; and reconnect the dvm to the dvm template. It doesn’t show me as logged in.
So I guess for now that’s just something that needs to be done manually.
If you have sys-firewall, you only need to do this before restarting sys-net:
qvm-prefs sys-firewall netvm ''
and after restarting you turn it back on:
qvm-prefs sys-firewall netvm 'sys-net'
I wonder how to automate the whole restarting procedure though.
You mean this 
Well, scripting, and I don’t prefer custom ones.
For me the real question is: how (not why) is not possible to detach anyVM when shutting down/restarting? Some security risk going offline?
Oh, and yes
Of course, but my qubes-shutdown-idle is 10 sec and restarting cannot be done in 10 sec, so… you imagine, hahah
If you are going to use dom0 to change prefs, i would recommend instead:
qvm-shutdown --force --wait sys-net && qvm-start sys-net
Not sure why qubes widget doesn’t permit to force shutdown/restart any qube.
Afterall, routing is static under Qubes OS and IPs are static. Once sys-net gets back online, everything goes back online, with sys-whonix’s tor maybe taking a little time to understand that circuits are dead, otherwise should work, same for vpns in the chain that would try reconnecting until sys-net is back online. Otherwise the impatients can kick those to retry faster if bothered.