I’m not sure exactly what your workflow is, so I will suggest a number of things, some of which might strike you as relevant. I’m hoping something here will give you ideas; please do not just blindly do as I suggest. I’ve left out a lot of details (including how to do things on the command line). I’m assuming you know how to do bash scripts.
You could, instead of directly issuing the start-vm command for sys-net, create a script that checks to ensure the device exists, and only then starts it.
If the issue is happening during bootup because sys-net tries to start, you can switch off “Start qube automatically on boot.” (You will want to do the same for sys-firewall.) On logging in you will want to run a script that starts sys-net (but only if the device isn’t killed) and then sys-firewall.
Unfortunately that won’t guard against some qube that has networking set to sys-firewall, firing up sys-firewall, which then fires up sys-net. Perhaps you could set things up so that when the wifi device isn’t there, sys-firewall’s net qube is set to none. (There’s a qvm-prefs command line to do that.) That’s perfectly allowable, even while sys-firewall is running. VMs using sys-firewall won’t be able to communicate with the internet, but that’s the whole idea, isn’t it?
As I am thinking about this, I could see a combination being used.
-
Disable start qube automatically on boot for both sys-net and sys-firewall. (This is a one time thing).
-
Create a script that checks to see if there is a wifi device. If there is no device, ensure sys-firewall’s network VM is set to none, and start sys-firewall. If there is a device, ensure sys-firewall’s network VM is set to sys-net, and make sure sys-net has the device assigned to it.
-
Put that script in .config/autostart-scripts.
Those three steps should have two effects: 1) sys-firewall and sys-net will NOT start on boot but will wait for you to log in (this will shorten boot time). 2) When you do log in, you’ll either have sys-net and sys-firewall ready to access the internet through the device (if it’s not killed) or sys-firewall will be a dead end with no internet (if the device is killed).
If you flip the switch while the system is on (and I have a librem13 so I know you can do that), you can mitigate the pain by writing a “flip off” script that resets sys-firewall’s netvm to none and shuts down sys-net, and a “flip on” script that ensures the device is assigned, then turns on sys-net, and sets sys-firewall’s networkvm to sys-net. Run “flip-off” before flipping the kill switch to off, and run “flip on” after flipping the kill switch to on. It won’t be perfectly automatic BUT typing one script name is a lot faster than the manual process you’re alluding to.