sys-net cannot always be started

[kototama]

Qubes OS version:

4RC3

Steps to reproduce the behavior:

Have sys-net as default netvm. Boot computer, start a disposable VM with Firefox. The VM cannot connect to the Internet.

Expected behavior:

sys-net is started

Actual behavior:

sys-net is not started

General notes:

sys-net is not started even if the option "starts automatically at boot" is activated for it. I tried qvm-start sys-net. I got error:

Start failed: invalid argument: network device with mac 00:16:3e:5e:6c:00 already exists, see /var/log/libvirt/libxl/libxl-driver.log for details

Last lines from libxl-driver.log:

2018-02-01 17:41:31.902+0000: libxl: libxl_pci.c:1174:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:00:14.0
2018-02-01 17:41:49.808+0000: libxl: libxl_device.c:1074:device_backend_callback: unable to remove device with path /local/domain/2/backend/vif/7/0
2018-02-01 17:41:49.811+0000: libxl: libxl.c:1673:devices_destroy_cb: libxl__devices_destroy failed for 7
2018-02-01 17:42:00.012+0000: libxl: libxl_linux.c:155:libxl__loopdev_cleanup: unable to release device /dev/loop0: No such device or address
2018-02-01 17:42:00.070+0000: libxl: libxl_linux.c:155:libxl__loopdev_cleanup: unable to release device /dev/loop0: No such device or address
2018-02-05 08:18:55.033+0000: libxl: libxl.c:1857:libxl_console_get_tty: unable to read console tty path `/local/domain/1/console/tty': Resource temporarily unavailable
2018-02-05 08:18:56.629+0000: libxl: libxl_pci.c:1174:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:00:14.0
2018-02-05 09:34:06.636+0000: libxl: libxl.c:1857:libxl_console_get_tty: unable to read console tty path `/local/domain/17/console/tty': Resource temporarily unavailable
2018-02-05 16:32:56.191+0000: libxl: libxl_pci.c:1174:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:00:14.0
2018-02-05 16:32:57.705+0000: libxl: libxl_device.c:1074:device_backend_callback: unable to remove device with path /local/domain/7/backend/vif/11/0
2018-02-05 16:32:57.709+0000: libxl: libxl.c:1673:devices_destroy_cb: libxl__devices_destroy failed for 11
2018-02-05 16:32:57.817+0000: libxl: libxl_device.c:1074:device_backend_callback: unable to remove device with path /local/domain/6/backend/vif/10/0
2018-02-05 16:32:57.824+0000: libxl: libxl.c:1673:devices_destroy_cb: libxl__devices_destroy failed for 10
2018-02-05 16:33:14.358+0000: libxl: libxl_device.c:1074:device_backend_callback: unable to remove device with path /local/domain/4/backend/vif/13/0
2018-02-05 16:33:14.361+0000: libxl: libxl.c:1673:devices_destroy_cb: libxl__devices_destroy failed for 13
2018-02-05 16:33:22.519+0000: libxl: libxl_linux.c:155:libxl__loopdev_cleanup: unable to release device /dev/loop0: No such device or address
2018-02-05 16:33:22.568+0000: libxl: libxl_linux.c:155:libxl__loopdev_cleanup: unable to release device /dev/loop0: No such device or address
2018-02-06 08:30:01.088+0000: libxl: libxl_pci.c:1174:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:00:14.0
2018-02-06 08:30:03.532+0000: libxl: libxl.c:1857:libxl_console_get_tty: unable to read console tty path `/local/domain/5/console/tty': Resource temporarily unavailable

Workaround is to reboot. I also reinstalled sys-firewall and sys-net weeks ago but still see this problem times to times.

[andrewdavidwong]

Possibly related: #3163.

[andrewdavidwong]

Possibly related: #3163.

[marmarek]

The error you get when starting sys-net manually is indeed #3163 and should be already fixed (install updates).
But the reason for not starting it initially probably is different. Actually I think it started, then crashed. Can you check journalctl for entries related to Start Qubes VM ... services - something related to sys-net failed start, or being started twice. Check also /var/log/xen/console/guest-sys-net.log - maybe there is some info about the crash.

[marmarek]

The error you get when starting sys-net manually is indeed #3163 and should be already fixed (install updates).
But the reason for not starting it initially probably is different. Actually I think it started, then crashed. Can you check journalctl for entries related to Start Qubes VM ... services - something related to sys-net failed start, or being started twice. Check also /var/log/xen/console/guest-sys-net.log - maybe there is some info about the crash.

[kototama]

Do you need the logs? I would have to dig for them. If it's fixed by the update, I would assume it works now and provides the log only if it occurs again. What do you think?

[kototama]

Do you need the logs? I would have to dig for them. If it's fixed by the update, I would assume it works now and provides the log only if it occurs again. What do you think?