R3.2 Easiest way to reset my netvm?

18 zobrazení
Přeskočit na první nepřečtenou zprávu

rqwan...@gmail.com

nepřečteno,
17. 2. 2018 10:00:3317.02.18
komu: qubes-users
R3.2

It seems that my wireless network controller sometimes failed to work even when I use the method described below:

https://www.qubes-os.org/doc/wireless-troubleshooting/#automatically-reloading-drivers-on-suspendresume

My wifi controller as in lspci is:
Ethernet controller: Intel Corporation Ethernet Connection I217-LM (rev 04)
Network controller: Intel Corporation Wireless 7260 (rev c3)

I will provide my observation and conjecture here ...

Sometimes when wireless network failed, usually it is when qubes have difficulty suspending all the vms at suspension within a short amount of time, because some of my VM were doing some CPU/memory intensive jobs when I suspend (for example, batch fedora updates, install part). I suspect that the netvm is just being suspended before its job is done.

Well, as it seems like a common problem and I am grateful that qubes has already solved tons of my problems, I do not expect the original problem will have a quick solution ... But I want a way to recover from the state.

The state is that sys-net cannot access to wifi, which is annoying. I tried killing and restarting sys-net. As far as I remember it worked one time, but other times it will not work and the sys-net will simple failed to boot (something like, in Qubes VM manager it becomes yellow, and then without becoming green it goes off as if it has not been started).

I tried detaching pci devices before shutting down sys-net. I cannot do it in GUI, so I use qvm-pci -d sys-net 03:00.0 and try detaching the network controllers. But the detaching and attaching fail with:

libxl: error: libxl_device.c:1269:libxl__wait_for_backend: Backend /local/domain/0/backend/pci/34/0 not ready

and the device is not visible in GUI! (It seems like a problem that xen failed but qubes gui has finished the transaction prematurely)

And the story goes the same.

Moreover, I have tried to change the netvm of sys-firewall to be none before I play with sys-net, but sometimes it also will not work, sometimes it fails with no reason (unknown error something like that), I tried changing the netvm via commandline and it fails with the same reason.

However, it seems when I have closed all the vms - actually maybe sys-firewall, when I close that, I can open sys-net with the network controllers and it runs without problems. But for qubes when you do this basically it is like rebooting since you are rebooting your worker vms actually ... It becomes inconvenient when you have 3 jobs to do at the same time, your 3+ vms are starting different project with several files open and suddenly wifi fxxk up and you will need to close everything and start over and ...

The report seems messy, so if anyone is interested in some of the details I can take time to try out how it works when I am free.

So here comes the problem: How can I recover without rebooting all my working vms when wifi fails?

Andrew David Wong

nepřečteno,
17. 2. 2018 20:18:0817.02.18
komu: rqwan...@gmail.com, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
You don't have to shut down any other VMs in order to restart sys-net.
You just have to change the NetVM settings of any ProxyVMs that are
using it first (which is usually just sys-firewall). Try this:

$ qvm-prefs -s sys-firewall netvm none
$ qvm-kill sys-net
$ qvm-start sys-net
$ qvm-prefs -s sys-firewall netvm sys-net

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlqI1EUACgkQ203TvDlQ
MDA6QRAAsnKQWCmFdoCSh5YaF8ZdlNZdMhNDqWa4wEX9OoVkDt6dFZ/BSYlJGQcm
RHr2FEN0zB0CkEo4tDdr7jfli1WcO4czG0RKLt8JzWZcLWJl7LV7IKQQO6PMTTIJ
LMQVzFbyfiCSRRdPJY2TUrT1O1ipP4AwCQ6uU+2yuG44lS1OcQ7cC21xLSqIIhfA
uLVXbR9Vbcga+A28P/ZNbqI4VD3knkWQTyvCnALMIBrGmcLy6WeO3lm60NofVrUV
hPBCmrU396W3JDqEiK4fgXhCXzNkmw1D3GT1ep1L5ILur+jvezOFa4OVykFd99u1
e49hiIjt7jzFjKIShCo9GLqF195swuyYFY3Pcr8lIbGsWvF0/tgHrluY4MDtSxdz
AWkcOqW3/A2xGZyA2gtaBno5qCeVOePiK2mujZLg1/sYxKG3KZa7tCSmHGFirmmy
YFDXeYLfOASP5w7ec0bG94ps/yzTsrBpXmiRuuvBzbHIaH0aaLvrjMebV6fAJYO1
mJ7SpTBaOoR343RevHQgeW2RMeE08mHZyYcCaKztfEzh3JxATnhy3KBu+UtkWOh8
yMX0BJBAhYuZIADdYBlR8tRecFX8/2/iu4akzF6G9wjjaYwdKabLSnzbMIh0e8I9
8s1D/8aj0HIMlEGWJwoWTMVG1k33Zncmgu1KSmGopMWWND6ZNT4=
=tc7p
-----END PGP SIGNATURE-----

Andrew David Wong

nepřečteno,
17. 2. 2018 20:22:0017.02.18
komu: rqwan...@gmail.com, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Oh, I just caught that you may have already tried this. It sounds like
you're experiencing a separate bug when trying to change the NetVM of
sys-firewall. I'd check to see if there's an existing bug report for
that and, if not, file one.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlqI1SMACgkQ203TvDlQ
MDCVYRAAlpHYkCKYq4RM1TGoLAVxT+Ngx40S9NzqLWSx6qz/dKQu4HybZyY21VLp
QYcY1CpYwVskG6+WG1WuZjcjVdwO5q3lip3kNZy2cel9CaDq8GyNpQ64z/ZGUi8q
AH8FpbW797LdrdJWqKIh0zFVqhFqY7HmtTEua7WZboAT1JEE51zlXhM/RCeILKtO
obQF2n9JkbFZof2jh60yx367WxGSbY/ZrY+P9Y7U5GzrOUqotLXR/PcjMhJ3MDSj
FMs/EW7G2bGZugOjPN/5G07t4QyHChp0/JQjoZHsDNAYLD1KRfaG8w4HWw1roSxJ
Vo3oDJ8KvPB1f5+3UaT6qmetAZgHfuY9cgQ6hDPSyhB6WrNNp+GhGzh9SAS5v5Tp
pBwBly/uMSYeaXwNVWt0U2J2yr5ti7VmSu20fxVY1A1VB9K6o7SmIZbBgmtX8pup
vNrpu30k4ghl0ff0vgMYiXHK/XKtl+eyXRt8fBAQI/raqpQNIuOguIxHbWw9G4OV
l/XXBjxiDlMloetMOdBjSN2PDLwOQyyVadFSDFnZ+sC8reqsZ5w15Wde/Wd1YWSM
K6pAh71rfIaIfdQ0FiP6/pbWVLPQs2X6Yyg5aQFyKWQxNfKDnTdR4Wre/THOR3BR
LiQGzOb+Kzh2GFgtY8URqdfHUzmJnRGVnPz6q55iANMA8H2kVlo=
=A1k2
-----END PGP SIGNATURE-----

rqwan...@gmail.com

nepřečteno,
17. 2. 2018 20:36:1417.02.18
komu: qubes-users


It sounds strange, but when my wifi was working normally just now, and I typed the 4 lines that you provided me in dom0 terminal, I successfully reseted my netVM and network connection of all the other VMs works seamlessly.

It is not very easy to make failure of wifi controller happen deliberately, to see whether the four lines work when it fails ... And when failure happened in the past, what I did then that seems closest to what you have provided may be that, set the netvm of sys-firewall in the GUI to be none, and sometimes this failed with "unknown error". I never tried to use qvm-kill in the terminal, though - so when I use this in the GUI mode it does not work very well.

I am not very sure whether there is any difference between the effects when I use GUI or CLI, other than the visible ones, such as something just cannot be done in GUI (like live attaching/detaching PCI devices).

Odpovědět všem
Odpověď autorovi
Přeposlat
0 nových zpráv