Wifi Connection Issue - Must Wait Before Completing Login

I am running Qubes 4.1.1 on an HP Dev One.

I have established a connection to my wifi. If I shutdown my computer, and log in immediately after I get my log in dialog box (after decryption), the system will not reconnect to my wifi network and I must initiate the connection manually from the menu bar. However, if I wait about 3-5 seconds after I get my log in dialogue box, it reconnects to my wifi network without any problems. I discovered this solution, or work-around by serendipity – which makes it sound like a bug. Please advise.

Best regards.

What’s the template and memory of sys-net? You can check in dom0 with:

qvm-prefs sys-net template
qvm-prefs sys-net memory
qvm-prefs sys-net maxmem

@BEBF738VD

qvm-prefs sys-net template
fedora-36
qvm-prefs sys-net memory
400
qvm-prefs sys-net maxmem
0

Well, 400MB would be too less for fedora-36 as I see it. Try 1024 then decrease step by step…

1 Like

It did not seem to make a difference. In the mean time, I have left memory at 1024

I also see that if it fails to connect, and I attempt to reconnect the wifi from the menu bar, I am prompted for the wifi password and the system creates a new wifi connection entry with the number 1 appended to the connection name. I’m able to reconnect after a restart, sometimes to the first connection, other times to the newly created one.

Well, I’d try to create disposable sys-net based on fedora-36-dvm, based on fedora and create completely new connection in such a sys-net, then while still up, I’d copy it to fedora-36-dvm’s /rw/config/NM-system-connections, shut down both and start sys-net.

Once upon a time I too had similar issues (start on boot service qubes hanging/underperforming) if I logged into the GUI desktop “too quickly” which, would require me to powercycle down to the offending qube (usually sys-net but, sometimes sys-firewall or also sys-usb on occasion).

I too launch all of my service qubes with no more than 512MB RAM, in most cases this ought be sufficient.

I think the best place to start would be to migrate to a minimal template for your sys-net. IMO, the base templates are unnecessarily bloated in general and, especially so for sys-net.

In my current implementation sys-usb and sys-net are isolated so, if this is not the case; please stop here. Should you have separate sys-usb and sys-net qubes, this is the process which has worked for me in the past …

Recreating sys-net can easily and safely be achieved thanks to the default SaltStack formula by doing the following:

  1. While you have a functioning sys-net, update your minimal templates and, may as well
sudo qubes-dom0-update

in dom0 shell also.

  1. Use Qubes Manger to select sys-net, click on the “Settings” button & rename (or do this in dom0 via cli if you prefer) sys-net to sys-net-old. Additionally, disable “Start qube automatically on boot”.

  2. From the “System” menu drop-down, click/select Qubes Global Settings & change your default template under “qubes defaults” to the minimal template of your choosing (don’t forget to click “OK” button)

  3. Open a dom0 shell and enter the following:

sudo qubesctl state.sls qvm.sys-net

(this ought rebuild your sys-net with the newly selected template)

  1. Test out your newly created sys-net by assigning it as a NetVM for sys-firewall, starting sys-firewall, opening a terminal in sys-firewall & generating some traffic (ie: $ping qubes-os.org). If all goes well, you can change the NetVM setting for the remaining qubes which are currently configured to use sys-net-old to use sys-net.

  2. Before you forget, go back into Qubes Global Settings & change your default template under “qubes defaults” back to the template of your choosing

  3. Restart to confirm you’re happy with your new minimal sys-net

If anything goes wrong, simply disable “Start qube automatically on boot” for your newly created sys-net and enable for sys-net-old while also switching the NetVM for guest qubes as necessary.

There’s no need to immediately remove/delete sys-net-old aside from HDD space which, ought not be too much as, it can serve as a fallback in case any of the above doesn’t work.

@cayce - Thank you for the detailed suggestion. I will try it later and will let you know what I find.

1 Like