Hello,
I recently started getting this error whenever starting a standalone VM. I saw the issue on GitHub, as well as this Reddit post. Unfortunately, none of those solutions work.
If I disable networking in the VM, it will boot and run. I’m trying to get either the networking working again or at the very least getting the ability to connect a USB drive to the VM so I can backup and redo the VM.
Maybe you lack the VT-d.
Try to directly connect the ethernet controller to your “sys-net” qubes (in its settings) and try to start your desired VM.
Thank you for the response. The CPU (i5-5200U) does support VT-d and I can’t seem to disable (or enable) it in the BIOS. The Ethernet controller is listed in devices (on the right side) for sys-net. I removed the controller and restarted sys-net then shut it back down and re-added the Ethernet controller to no avail.
It would be helpful if you could give a little more information about
this standalone. (I’m assuming that the standaloneVM worked fine
before, and that otherwise your Qubes system works as expected.)
What devices are attached?
What is the netvm to which it is attached?
Do other qubes attached to the same netvm boot properly?(If there are
none can you test this.)
Can you identify any changes (configuration or OS updates) that preceded
the error?
Do you see anything in the Qubes logs?
I had/have a similar problem.
I disabled all the appVM that start on startup and I start sys-net manually. Then sys-net starts ok. Some conflict with sys-usb seems to be related.
I wouldn’t call this a solution (and happy to hear comments about implications). But, it works.
Just got this error during install of 4.2.
I am not using sys-net for USB.
Now i wonder if the problem might be because i installed without plugging in cat5 cable and giving the box internet during install. Will test later today and report back with any new findings.
Unfortunately i can’t get into the console and read the log, ctrl+alt+f6 or any f key does not give me login shell >.<
Post the exact error messages that you see.
Check this log file in dom0:
/var/log/libvirt/libxl/libxl-driver.log
It’s not related.
You can’t login in dom0 or what are you talking about?
There’s terminal emulator ready in dom0, you do not need to switch to tty2 or something to read the logs.
well quick update, it allowed me to log in but i fumbled and didn’t write down the exact location of that log, anyways it was a test install to on board connected ssd which i was going to replace with a nvme.
Now finished fresh install to nvme and same hardware but removed the ssd from mobo and the error did not pop up.
I encounter this error after an update v4.1 → v4.2. Some AppVms can be started, like those based on debian/fedora minimal templates. Also the sys-vms can be started which are based on debian-dvms. On the other hand a disposable debian-dvm and most of the other DVMs fail to start with the error:
„Qube dispXXXX/AppVm has failed to start: internal error: libxenlight failed to create a new domain ‚dispXXXX/AppVM‘“
Can’t find any usable information in the logs.
Issues on github regarding older versions of qubes do exist, but I couldn’t find any for version v4.2.
Any suggestions?
Check the logs in dom0 terminal with journalctl and check this log file in don0:
/var/log/libvirt/libxl/libxl-driver.log
journalcrtl doesn’t provide any additional information than the one already posted above.
libxl-driver.log shows 3 messages at the very same time when journalctl claims there’s an internal error with libxenlight:
How can I deal with this failing vif?
Thanks @apparatus. That did the trick. I forgot that during the migration v4.1 → v4.2 I excluded the mirage firewall from upgrading and after recreating it, everything works like a charm.