Qubes Build20200726-4.1 libxenlight errors on MacBook A1706

[alzer89]

Qubes OS version:

Build20200726-4.1

Affected component(s) or functionality:

libxenlight (possibly others)

---

Steps to reproduce the behavior:

Installed Qubes OS, modified udev rules to hide Broadcom 43602 wifi card on boot to prevent freeze (MacBook Pro), rebooted, configured Qubes OS. Tried opening any VM.

Expected or desired behavior:

VMs open and PCI passthrough works.

Actual behavior:

“Libxenlight Failed to Create new Domain ‘(qube name)’, see /var/log/libvirt/libxl/libxl-driver.log for details”

General notes:

Running on a MacBook Pro A1706 with no other OS installed.

I am fully aware that this is a testing alpha with no support, however I would still like to be able to provide any information to the developers that may be of use.

---

I have consulted the following relevant documentation:

#3125

I am aware of the following related, non-duplicate issues:

#3125
However it is from version 3.2.

[iamahuman]

“Libxenlight Failed to Create new Domain ‘(qube name)’, see /var/log/libvirt/libxl/libxl-driver.log for details”

Can you boot the machine to another OS and post the contents of file /var/log/libvirt/libxl/libxl-driver.log from the disk partition containing Qubes installation, to https://gist.github.com/?

[alzer89]

<script src="https://gist.github.com/alzer89/c0628106370b8d52064a83bb7e7d306d.js"></script>

Would anything else help? (dmesg, maybe?
libxl-driver.log
)

[iamahuman]

Can you use Qubes R4.0 on the same machine? Then, this is likely a regression.

[alzer89]

No. I haven't been able to get any Qubes to run successfully on this machine.

[alzer89]

HVM works WITHOUT attaching any devices (I can run Windows 10, other Linux distros and MacOS in an HVM), but PV or PVH doesn't work at all.

[iamahuman]

Working HVM implies that Xen's PV itself at least is also working as well, since there is a PV domain hosting QEMU device model for each HVM.

Is the following table correct?

Qubes version	PCI passthrough	HVM	PV	PVH
R4.0	No	✔	❌ (as a Qube) ✔ (Only as stubdom)	❌
R4.0	Yes	❌	❌	❌
R4.1	No	✔	❌ (as a Qube) ✔ (Only as stubdom)	❌
R4.1	Yes	❌	❌	❌

[alzer89]

No. PV does not work at all (at least when it is selected in the Qube Settings tab).

Also, when trying to shut down a qube that isn't a standalone qube, it says that qubesd returned a zero exit status.

I've included some extra logs, hoping they might be helpful.
dmesg.log
journalctl.log

[marmarek]

I think the issue is that every VM you start is connected to network, so requires sys-net running. And sys-net fails to start, so regardless of your test VM type, it fails to start too.
Try testing with a VM that has netvm set to none ("networking" option in graphical VM settings).
You can also check why sys-net doesn't start - try starting it directly and collect some info - its console log (/var/log/xen/console/guest-sys-net.log) and perhaps also xl dmesg output.

[alzer89]

All template VMs go "starting..." -> "started" -> "halted" within the space of 5-7 seconds.

All other VMs with networking set to (none) do the same thing.

Standalone VMs with no networking and the virtualisation mode set to HVM work completely fine (apart from the fact that they have no access to the outside world).

Hopefully these help.
guest-sys-net.log
xl-dmesg.log

[marmarek]

 mount: /sysroot: wrong fs type, bad option, bad superblock on /dev/xvda, missing codepage or helper program, or other error.

Looks like broken template. Can you switch to another one (debian for example)?

[alzer89]

Sys-net starts as HVM (with no devices attached, I had to take its access to the Broadcom 43602 wifi card because it causes the entire machine to freeze) with fedora-32, debian-10 and archlinux as template.

Sys-firewall returns "libxenlight failed to create new domain for 'sys-firewall'." regardless of which template is used.

[andrewdavidwong]

#3125
However it is from version 3.2.

I think you are misreading issue #3125. Even the original report says it's from 4.0, not 3.2.

In any case, we do not typically have separate issues for the same bug in different versions of Qubes. Instead, we have just one open issue on the milestone for the earliest affected version.

@marmarek, does this look like a duplicate of #3125?

[github-actions]

This issue is being closed because:

• This issue is believed to affect only Qubes OS 4.1 (and possibly earlier).
• Qubes OS 4.1 has reached end-of-life (EOL).

If anyone believes that this issue should be reopened, please leave a comment saying so.
(For example, if a bug still affects Qubes OS 4.2, then the comment "Affects 4.2" will suffice.)