How to swap sys-net from disposable to permanent (how to get WiFi to remember the password)

[barcodeman]

Hi,

My problem is that I accidentally made sys-net disposable on installation, not knowing this would not save the wifi network password on boot.

My goal is for qubes to remember the wifi passwords I have connected to as simply as possible, either by changing sys-net to a permanent template (?) or by another way. I do not care if it is disposable or not, I just want the wifi password to be remembered so I don’t have to enter it each time.

Thank you.

[fsflover]

Disposible Sys-Net VM - Forgets Password?

I followed the rules carefully in the wonderful manual for Qubes and managed to make a Disposable Sys-Net VM. I even got it working perfectly. Wonderful work this Operating System is! But, then I realized that the internet password was not being remembered. I realize this is less secure to leave it in there. But I’d like to have a Disposable Sys-Net VM with a password setup for a designated internet connection. I know, it’s doing what its supposed to. It’s deleting it self after each use. Wh…

Sys-net disposable? (4.1 rc)

When you connect to a Wifi, network manager stores all connection details inside /rw/config/NM-system-connections/[wifi].nmconnection. Just copy that file to the hopefully dedicated template of your disposable sys-net and your disposable sys-net will work with it on next boot. The same applies for all the other modifications that need to remain persistent. Do them inside the template. You can see from mount what is persistent in your template (everything on /dev/xvdb).

After reboot wifi password forgotten

You can do that much easier. All you have to do is to train the AppVM that serves as a template for your sys-net. So let’s say your disposable sys-net is based on fedora-34-dvm which in turn is based on fedora-34. shutdown all qubes change virt_mode of fedora-dvm to hvm temporarily make sure the provides_network of fedora-dvm is true add the WiFi PCI device to fedora-dvm run fedora-dvm with qvm-start fedora-dvm once it started you’ll see the network manager icon in the tray; now train it th…

[barcodeman]

How can I copy /rw/config/NM-system-connections/[wifi].nmconnection to my fedora dvm ? the docs aren’t very helpful with qvm-copy etc

[enmus]

How to copy and move files

[fsflover]

@barcodeman

the docs aren’t very helpful with qvm-copy etc

Could you point out what is unclear in the docs? Perhaps they could be improved.

You can copy files using a right mouse click, choose “Copy to other AppVM”.

[fsflover]

Update qvm-copy-to-vm doc

[barcodeman]

Ok, I did not run the command because I did not know what would happen. Perhaps the tutorial could say 'running this command will prompt the GUI, where you can choose the qube to copy to.

I appear to have done something wrong.

I succesfully copied the connection details file to fedora-36. I made a new NM-system-connections directory in /rw/config/, like the one found in sys-net. I placed the connection file in here, but my system does not remember the details and connect automatically.

The sys-net is based on fedora-36-dvm, which in turn is based on the fedora-36 template.

Sys-net disposable? (4.1 rc)

When you connect to a Wifi, network manager stores all connection details inside /rw/config/NM-system-connections/[wifi].nmconnection. Just copy that file to the hopefully dedicated template of your disposable sys-net and your disposable sys-net will work with it on next boot. The same applies for all the other modifications that need to remain persistent. Do them inside the template. You can see from mount what is persistent in your template (everything on /dev/xvdb).

The guy here said to put it in the dedicated template so I thought that meant fedora-36.

Where am I going wrong?

Thanks for everyones help!

[cayce]

@barcodeman

Where am I going wrong?

I think your misstep is quite common and a simple one. Applying changes in the wrong qube.

Here’s a break down of inheritance and persistence which I hope offers some clarity.

Possibly considered a sloppy way forward:

You could go ahead and make the changes you expected to work in the AppVM dvm template qube (fedora-36-dvm in this case) as opposed to the primary TemplateVM (fedora-36 in this case.)

That said, you’ve already “tainted” your fedora-36 template.

With the goal of having a “clean”/reproducible system, it’s often considered best practice by some to leave installed templates alone without modifications so as to be able to clone said template in the future without unqualified artifacts carried over to any new cloned templates and/or AppVMs based on the fedora-36 template.

@barcodeman

The guy here said to put it in the dedicated template so I thought that meant fedora-36.

Possibly considered a “cleaner” way forward:

1. Rename your now tainted fedora-36 and fedora-36-dvm qubes to something like fedora-36_tainted and fedora-36-dvm_tainted.
2. Reinstall fedora-36 in dom0 with:

qubes-dom0-update qubes-template-fedora-36

4. Create a new AppVM based on your newly installed version of fedora-36 called something like fedora-36-sys-net-dvm
5. Apply your changes with respect to your WiFi goals. You can review this for details on customization of disposable.
6. Shutdown sys-net & change the “Template” property to your newly created/modified fedora-36-sys-net-dvm
7. Start sys-net and verify the changes made are available as you intended. (ie: are your pre-defined WiFi connections available, are they auto-connecting or would you prefer they not, etc.)

[SteveC]

I agree. You should keep a clean copy of the template you are using, and clone from that to create new templates.

Once you know all of the different things you want to do you can even create a family tree. Perhaps you would want two templates, the first one has software packages A, B, C and D on it, the second has C, D, E, and F on it. So you could start with your Fedora 36 template, clone that to Fed36-C-and-D, install C and D on that template, then clone fed36-C-and-D twice, and install A and B on one of those clones, and E and F on the other.

I actually have a pretty substantial “family tree” like that, though mine is based on debian-11-minimal. But the principle is the same regardless of what template you are starting from.