Apart from the boot problem after installation (which I have a work-around now) I found a few more glitches:
After restarting sys-net (after having installed updates for defora) a connection to the network card could no longer be established; I had to do a power-cycle.
Syslog messages were:
Mar 29 23:34:03 sys-net kernel: r8169 0000:00:06.0 ens6: rtl_rxtx_empty_cond == 0 (loop: 42, delay: 100).
Mar 29 23:34:09 sys-net kernel: r8169 0000:00:06.0 ens6: rtl_rxtx_empty_cond == 0 (loop: 42, delay: 100).
Mar 29 23:34:15 sys-net kernel: r8169 0000:00:06.0 ens6: rtl_rxtx_empty_cond == 0 (loop: 42, delay: 100).
Info on ens6:
ash-5.1# ethtool -i ens6
driver: r8169
version: 5.10.104-3.fc32.qubes.x86_64
firmware-version: rtl8168g-2_0.0.1 02/06/13
expansion-rom-version:
bus-info: 0000:00:06.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no
I also noticed that I cannot use "Restart" on sys-net in the Qubes Manager (any more: It works in 4.0).
I had installed the debian-11 template, but no DVM was created, and I'm unable to select debian-11 as DVM template.
When booting the latest kernel (as of today) I noticed some odd kernel messages when VMs are starting:
ar 30 01:12:42 dom0 kernel: xen-blkback: backend/vbd/3/51760: using 2 queues, protocol 1 (x86_64-abi) persistent grants
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0xc (pfn 0x107bce)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0xd (pfn 0x107c5d)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0xe (pfn 0x1084c8)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0xf (pfn 0x106575)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x10 (pfn 0x104552)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x11 (pfn 0x10847d)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x12 (pfn 0x104582)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x13 (pfn 0x10725a)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x14 (pfn 0x104313)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x15 (pfn 0x1065d1)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x16 (pfn 0x10a7a2)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x17 (pfn 0x103998)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x18 (pfn 0x105eae)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x19 (pfn 0x107be2)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x1a (pfn 0x106585)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x1b (pfn 0x10659b)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x1c (pfn 0x105532)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x1d (pfn 0x106cc2)
...
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x2b (pfn 0x106cc7)
Mar 30 01:13:07 dom0 runuser[9072]: pam_unix(runuser:session): session closed for user master
Apart from the boot problem after installation (which I have a work-around now) I found a few more glitches:
After restarting sys-net (after having installed updates for defora) a connection to the network card could no longer be established; I had to do a power-cycle.
Syslog messages were:
Mar 29 23:34:03 sys-net kernel: r8169 0000:00:06.0 ens6: rtl_rxtx_empty_cond == 0 (loop: 42, delay: 100).
Mar 29 23:34:09 sys-net kernel: r8169 0000:00:06.0 ens6: rtl_rxtx_empty_cond == 0 (loop: 42, delay: 100).
Mar 29 23:34:15 sys-net kernel: r8169 0000:00:06.0 ens6: rtl_rxtx_empty_cond == 0 (loop: 42, delay: 100).
Info on ens6:
ash-5.1# ethtool -i ens6
driver: r8169
version: 5.10.104-3.fc32.qubes.x86_64
firmware-version: rtl8168g-2_0.0.1 02/06/13
expansion-rom-version:
bus-info: 0000:00:06.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no
I also noticed that I cannot use “Restart” on sys-net in the Qubes Manager (any more: It works in 4.0).
I had installed the debian-11 template, but no DVM was created, and I’m unable to select debian-11 as DVM template.
When booting the latest kernel (as of today) I noticed some odd kernel messages when VMs are starting:
ar 30 01:12:42 dom0 kernel: xen-blkback: backend/vbd/3/51760: using 2 queues, protocol 1 (x86_64-abi) persistent grants
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0xc (pfn 0x107bce)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0xd (pfn 0x107c5d)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0xe (pfn 0x1084c8)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0xf (pfn 0x106575)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x10 (pfn 0x104552)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x11 (pfn 0x10847d)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x12 (pfn 0x104582)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x13 (pfn 0x10725a)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x14 (pfn 0x104313)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x15 (pfn 0x1065d1)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x16 (pfn 0x10a7a2)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x17 (pfn 0x103998)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x18 (pfn 0x105eae)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x19 (pfn 0x107be2)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x1a (pfn 0x106585)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x1b (pfn 0x10659b)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x1c (pfn 0x105532)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x1d (pfn 0x106cc2)
…
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x2b (pfn 0x106cc7)
Mar 30 01:13:07 dom0 runuser[9072]: pam_unix(runuser:session): session closed for user master
To me it does not look very stable yet.
Regards,
Ulrich
On Fedora 34/Qubes 4.0, I also had this WiFi (TP-Link/Realtek - rtl8192ee) connection issue after doing the Fedora update that updated the wpa_supplicant to version 2.10.
Apart from the boot problem after installation (which I have a work-around
now) I found a few more glitches:
After restarting sys-net (after having installed updates for defora) a
s/defora/fedora/ # tired already
connection to the network card could no longer be established; I had to do a
power-cycle.
Syslog messages were:
Mar 29 23:34:03 sys-net kernel: r8169 0000:00:06.0 ens6: rtl_rxtx_empty_cond
== 0 (loop: 42, delay: 100).
Mar 29 23:34:09 sys-net kernel: r8169 0000:00:06.0 ens6: rtl_rxtx_empty_cond
== 0 (loop: 42, delay: 100).
Mar 29 23:34:15 sys-net kernel: r8169 0000:00:06.0 ens6: rtl_rxtx_empty_cond
== 0 (loop: 42, delay: 100).
Info on ens6:
ash-5.1# ethtool -i ens6
driver: r8169
version: 5.10.104-3.fc32.qubes.x86_64
firmware-version: rtl8168g-2_0.0.1 02/06/13
expansion-rom-version:
bus-info: 0000:00:06.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no
Apart from the boot problem after installation (which I have a work-around
now) I found a few more glitches:
After restarting sys-net (after having installed updates for defora) a
connection to the network card could no longer be established; I had to do
a power-cycle.
Syslog messages were:
Mar 29 23:34:03 sys-net kernel: r8169 0000:00:06.0 ens6:
rtl_rxtx_empty_cond == 0 (loop: 42, delay: 100).
Mar 29 23:34:09 sys-net kernel: r8169 0000:00:06.0 ens6:
rtl_rxtx_empty_cond == 0 (loop: 42, delay: 100).
Mar 29 23:34:15 sys-net kernel: r8169 0000:00:06.0 ens6:
rtl_rxtx_empty_cond == 0 (loop: 42, delay: 100).
Info on ens6:
ash-5.1# ethtool -i ens6
driver: r8169
version: 5.10.104-3.fc32.qubes.x86_64
firmware-version: rtl8168g-2_0.0.1 02/06/13
expansion-rom-version:
bus-info: 0000:00:06.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no
I also noticed that I cannot use "Restart" on sys-net in the Qubes Manager
(any more: It works in 4.0).
I had installed the debian-11 template, but no DVM was created, and I'm
unable to select debian-11 as DVM template.
When booting the latest kernel (as of today) I noticed some odd kernel
messages when VMs are starting:
ar 30 01:12:42 dom0 kernel: xen-blkback: backend/vbd/3/51760: using 2
queues, protocol 1 (x86_64-abi) persistent grants
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0xc (pfn 0x107bce)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0xd (pfn 0x107c5d)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0xe (pfn 0x1084c8)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0xf (pfn 0x106575)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x10 (pfn 0x104552)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x11 (pfn 0x10847d)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x12 (pfn 0x104582)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x13 (pfn 0x10725a)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x14 (pfn 0x104313)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x15 (pfn 0x1065d1)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x16 (pfn 0x10a7a2)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x17 (pfn 0x103998)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x18 (pfn 0x105eae)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x19 (pfn 0x107be2)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x1a (pfn 0x106585)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x1b (pfn 0x10659b)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x1c (pfn 0x105532)
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x1d (pfn 0x106cc2)
...
Mar 30 01:12:50 dom0 kernel: deferring g.e. 0x2b (pfn 0x106cc7)
Mar 30 01:13:07 dom0 runuser[9072]: pam_unix(runuser:session): session
closed for user master
To me it does not look very stable yet.
Regards,
Ulrich
On Fedora 34/Qubes 4.0, I also had this WiFi (TP-Link/Realtek - rtl8192ee)
connection issue after doing the Fedora update that updated the
wpa_supplicant to version 2.10.
SOLUTION: Downgrade wpa_supplicant to version 2.9
That's interesting, specifically as my TP-LINK adapter isn't detected at all (I'll have to use cable).