Open GWeck opened 3 weeks ago
On Qubes R4.2.1, Fedora-40-xfce, and kernel 6.9.2, with wifi only, I can't reproduce this.
sys-net often loses connectivity after suspend, but restarting the qube restores it.
On Qubes R4.2.1, Fedora-40-xfce, and kernel 6.9.2, with wifi only, I can't reproduce this.
sys-net often loses connectivity after suspend, but restarting the qube restores it.
@marmarek The above would justify the additional OpenQA unit test I suggested here in last paragraph.
For me, after suspending and restarting Qubes, the network is still running. So this seems to be something different.
This seems to be a hardware-dependent issue, because the effect occurs on an HP Elitebook, but not on other hardware - but why does it occur in Qubes R4.2.1 and not in R4.1.2?
Do you have the same PCI attach options in Qubes OS 4.1 and 4.2?
Maybe you have no-strict-reset
and/or permissive
option/s set only in one system?
Did network work in sys-net after restart in Qubes OS 4.2 before on this machine? Or is it a first time that you've installed Qubes OS 4.2 on this machine (or tried restarting sys-net)? You can also try to use the same kernel in Qubes OS 4.2 that you have in Qubes OS 4.1. Maybe it's an issue with latest kernel.
The PCI attach options in both R4.1 and R4.2 are identical. On top of that, setting or unsetting the no-strict-reset
option causes no change in the behavior in both versions.
I have been running the test installation of R4.2 for some time, but, unfortunately, I have never tried to restart sys-net
previously.
Both systems are running with the same kernel 6.9.4, but going back to an earlier kernel, e.g. 6.6.25, does not change the situation.
Did you check /var/log/xen/console/guest-sys-net-dm.log
in dom0? Maybe there will be some info.
@alimirjamali:
The above would justify the additional OpenQA unit test I suggested here in last paragraph.
I suggest opening a separate issue for adding such tests.
I did not find anything suspicious in /var/log/xen/console/guest-sys-net-dm.log
. The logs for both the working and the faulty start look the same, without any serious error.
Qubes OS release
R4.2.1
Brief summary
Whenever
sys-net
is restarted, network access via WiFi or ethernet cable is no longer possible.Steps to reproduce
Restart
sys-net
via Qube Manager or CLI and try to establish a network connection.Expected behavior
The previously enabled network devices should work again after
sys-net
has completed its startup.Actual behavior
After restarting
sys-net
, for WiFi, a message is shown that the connection is established, but no access to other networks is possible. For Ethernet cable, the icon in the panel shows a red circulating dot. Both types of interfaces cannot be started manually, and any attempt to connect to an external node, likeping
from asys-net
terminal will fail, possibly with a message likeNetwork not available
.Booting Qubes restores network access.
This happens for
sys-net
based on Fedora-39, Fedora-40, and Debian-12. So it seems that this is not a bug insys-net
itself, but possibly indom0
or the communication withdom0
.journalctl
does not show any errors insys-net
ordom0
.This effect is specific to Qubes R4.2.1. Under Qubes R4.1.2,
sys-net
can be restarted without problems on the same machine. Both are running kernel 6.9.4.