Hey I am having an issue with sys-net that I have had for a few months now. sys-net disconnects from the network properly but when i try reconnecting to the network after some hrs sys-net fails to search for WiFi networks or connect to the network previously used.
I find my self having to kill sys-net and starting it again and reconnect to the network again. This is not very convenient. Can anyone help with this?
How did you get sys-net to connect to wifi in the first place, if you’re using a disposable?
I’m having to actually open a terminal on sys-net and issue a command (nmcli with a bunch of parameters, including the wifi password) to get it to connect. As near as I can tell this is because, although normally wifi remembers its networks from one boot to the next, a disposable won’t remember that.
(I’ve tried putting the command into system-d as a startup service, but apparently that runs too early [i.e., before the wifi controller is running] to do any good. My next attempt will be to alter that startup service file to loop until success, then exit.)
It’s not even displaying the popup asking for my password, because the disposable doesn’t remember from one startup to the next that it’s supposed to try to connect to that network.
well i connect sys-net initially to the network i choose first. sys-net should retain the password until the vm is actually shut down, When i close my PC or disconnect from the WiFi, it fails to start WiFi/ connect to WiFi automatically when i reopen my laptop again.
Known issue related to fedora increasingly requiring more RAM and issues that would be shown under sys-net by keeping a scrolling system journal before the issue happens sudo journalctl -f to see logs when you loose network (and hopefully push devs to increase the sys-net/sys-usb default of assigned memory). Was reported in different threads for sys-usb (camera disconnection, usb proxy failing, etc) and sys-net (after resume of suspend, on high network throughput etc).
You could either assign more memory to those HVMs (no memory ballooning for sys-* machines), try to tune systemctl there, rely on a minimal template, switch to debian… But the simplest is to assign more memory to the faulty sys-net/sys-usb:
I would recommend starting your qubes session by opening a shell on sys-net and calling sudo journalctl -f. It might be a faulty driver causing it to oops the kernel, amongst other things. Depending of the network card used, there might be a lot of kernel modules dependencies, and maybe one of them is having a memory leak.
The symptom you express seems to be the consequence of a kernel driver being faulty, but it might as well be something killed by kernel memory manager, kicking out a process that consumed too much memory. Best is to see what is happening when you loose networking from sys-net perspective and go from there. My previous posts were related to fedora and its ever increasing memory cost at each release, having consequences. But as well, the size of applications that are running by default. Debian is normally more lightweight.
What is your hardware? Network card and sys-net memory assignment information would be a start, with journal trace around the moment of disconnection to know what is actually happening.
Clean install of Qubes 4.1.1 will require you to change memory assignment of sys-net yourself.
If you experience loss of networking, I recommended changing the default memory assignment to something around 500Mb.
The default will not be changed upstream. Some services might be deactivated by default later on, as discussed in referred issue in previous post in thread (Fedora related, while discussions are relevant to other service qubes as well).
Where important traces for troubleshooting of issues would still be the same and important to others as well:
I cannot replicate the issue on my side: Fedora-36-dvm based sys-net with 500Mb assigned.
Of course, you have to shut down sys-net first (dom0: qvm-shutdown --force --wait sys-net)
Open sys-net Settings, Advanced tab and set Initial memory to 500mb:
Fun fact: it is now possible to change the memory allocation (dunno since when) while sys-net is running.
Note that HVMs cannot have memory allocation dynamically changed, so the new setting will be applied on reboot of sys-net, even though nothing currently warns the user that those new settings are not currently applied.