Booting Qubes OS 4.1.2 on MacBook Pro 14.1 [ A1708 ]

User Support Hardware Issues
1

Hello Qubes OS community,

I know that my MBP is not listed on HCL, but it’s the only device I have, and I really want to learn Qubes. Tails and Fedora works smooth on this machine.

I’ve partitioned the disk into two parts and then removed the second to leave free space for Qubes. The installation went smoothly, but upon booting the system, I encountered the following error window:

[Dom0] Error starting Qube!
Start failed: internal error: libxenlight failed to create a new domain ‘sys-firewall’, see /var/log/libvirt/libxl/libxl-driver.log for details.

I checked the libxl-driver.log:
2023-11-29 01:25:51.152+0000: libxl: libxl_device.c:1146:device_backend_callback: Domain 7:unable to add device with path /local/domain/5/backend/vif/7/0
2023-11-29 01:25:51.152+0000: libxl: libxl_create.c:1938:domcreate_attach_devices: Domain 7:unable to add vif devices
2023-11-29 02:04:30.347+0000: libxl_pci.c:1489:libxl__device_pci_reset: The kernel doesn’t support reset from sysfs for PCI device 0000:00:14.0
2023-11-29 02:04:36.677+0000: libxl_nic.c:487:libxl__device_nic_set_devids: Domain 5:Unable to set nic defaults for nic 0
2023-11-29 02:04:45.739+0000: libxl_pci.c:1489:libxl__device_pci_reset: The kernel doesn’t support reset from sysfs for PCI device 0000:00:14.0
2023-11-29 02:04:59.078+0000: libxl: libxl_device.c:1146:device_backend_callback: Domain 8:unable to add device with path /local/domain/6/backend/vif/8/0
2023-11-29 02:04:59.078+0000: libxl: libxl_create.c:1938:domcreate_attach_devices: Domain 8:unable to add vif devices

No network buttons appear in my system, I have no place to enter the WiFi password.
lspci -v | grep Wireless returns
02:00.0 Network controller: Broadcom Inc. and subsidiaries BCM4350 802.11ac Wireless Network Adapter (rev 05)

I kindly ask for suggestions on how to resolve this issue.
Your help is highly appreciated.

2

You can try this:

3

Tried, but it didn’t help.
I don’t understand at all what’s wrong and what I can do.
The only terminal I can open is dom0, and when I click on other places there are only settings

4

Maybe this has somethings useful for your case: HCL - Apple MacBook Pro (11,1)

5

I’ve tried it all without success.
It seems to be the same problem as here…. since 2019
https://github.com/QubesOS/qubes-issues/issues/5448

1 Like
6

Did you try to select btrfs for the filesystem, when you installed Qubes-OS?

I was testing Qubes OS 4.2-rc5 on this MacBook Pro 14.1 [A1708] - and after I

  1. picked btrfs at installation
  2. removed " HFS+ ESP" from the dom0:/root/anaconda-ks.cfg[1]
  3. ran sudo /usr/libexec/initial-setup/initial-setup-graphical

I had Qubes OS R4.2-rc5 running on this old MacBook Pro 14.1 [a1708]. With a USB-dongle for ethernet, I was looking at the steps from HCL - Apple MacBook Pro (11,1) to get WiFi working - but couldn’t get it to work.

So to see if it was something with 4.2-rc5, I found an old 4.1.2-rc1 and just did the same steps, to get Qubes OS running. :slight_smile:

Now I’ll try the steps from @balko to see if I can make it work …

[1]: Alternative: Change --label=Linux HFS+ ESP to --label="Linux HFS+ ESP"

7

@pxWho Is there any chance of getting the output of the following command in dom0:

lspci | grep '0000:00:14.0'

Basically, a Qube is trying to start with a PCI device passed through into it. In this case, it appears to be sys-firewall. However, sys-firewall doesn’t usually have PCI devices passed through to it. sys-net usually contains your NICs (ethernet hardware, wifi card, etc.).

Apple hardware usually contains Broadcom network hardware, which is notorious for being proprietary, locked-down, and having almost nothing in their firmware/drivers in places where you would usually expect them (just to be different, you know…).

This is likely what libxl is complaining about.

I have quite a lot of Apple hardware that will cause the entire machine to panic and freeze if you try and pass through the wifi hardware without setting it to permissive and not resetting it.

Knowing what PCI device 0000:00:14.0 is will help a lot in giving you the answer you seek :slight_smile:

8

So - with Qubes OS 4.2 just around the corner, I did [yet another] a reinstall of my MacBook Pro [A1708] with 4.1.2 to test the OP issues.

When I just picked the default LVM during install, I got a broken system, with

2023-12-17 19:04:02.512+0000: libxl: libxl_device.c:1146:device_backend_callback: Domain 5:unable to add device with path /local/domain/3/backend/vif/5/0
2023-12-17 19:04:02.512+0000: libxl: libxl_create.c:1938:domcreate_attach_devices: Domain 5:unable to add vif devices
2023-12-17 19:05:33.798+0000: libxl: libxl_pci.c:1489:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:00:14.0
2023-12-17 19:05:38.724+0000: libxl: libxl_pci.c:1489:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:00:14.0

in libxl-driver.log - and trying lspci | grep '0000:00:14.0' didn’t find anything promissing:

[root@dom0 ~]# lspci | grep 14
00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller (rev 21)

So I did a reinstall, picking “Custon - LVM (auto)” but ended almost the same place – this time the “INITIAL SETUP” failed to start, because the partition information in dom0:/root/anaconda-ks.cfg had changed from

ignoredisk --only-use=nvme0n1
autopart --encrypted
# Partition clearing information
clearpart --none --initlabel

to

ignoredisk --only-use=nvme0n1
# Partition clearing information
clearpart --none --initlabel
# Disk partitioning information
part pv.490 --fstype="lvmpv" --ondisk=nvme0n1 --size=237147 --encrypted --luks-version=luks2
part /boot --fstype="ext4" --ondisk=nvme0n1 --size=1024
part /boot/efi --fstype="macefi" --ondisk=nvme0n1 --size=600 --label=Linux HFS+ ESP
volgroup qubes_dom0 --pesize=4096 pv.490
logvol none --fstype="ext4" --size=20480 --thinpool --metadatasize=24 --chunksize=64 --name=root-pool --vgname=qubes_dom0
logvol swap --fstype="swap" --size=4027 --name=swap --vgname=qubes_dom0
logvol / --fstype="ext4" --grow --size=1024 --thin --poolname=root-pool --name=root --vgname=qubes_dom0

and dom0:/usr/libexec/initial-setup/initial-setup-graphical really doesn’t like/parse spaces in a label. The easy fix was to either add " around the label ("Linux HFS+ ESP") or simply remove the HFS+ ESP. The libxl-driver.log now had

2023-12-17 19:51:15.356+0000: libxl: libxl_device.c:1146:device_backend_callback: Domain 4:unable to add device with path /local/domain/2/backend/vif/4/0
2023-12-17 19:51:15.356+0000: libxl: libxl_create.c:1938:domcreate_attach_devices: Domain 4:unable to add vif devices

and the installation was still broken. :-/

Finally I installed and picked Custom - BTRFS (auto) – the “INITIAL SETUP” still fails, since the partition information is:

ignoredisk --only-use=nvme0n1
# Partition clearing information
clearpart --none --initlabel
# Disk partitioning information
part /boot/efi --fstype="macefi" --ondisk=nvme0n1 --size=600 --label=Linux HFS+ ESP
part btrfs.1030 --fstype="btrfs" --ondisk=nvme0n1 --size=233119 --encrypted --luks-version=luks2
part swap --fstype="swap" --ondisk=nvme0n1 --size=4028 --encrypted --luks-version=luks2
part /boot --fstype="ext4" --ondisk=nvme0n1 --size=1024
btrfs none --label=qubes_dom0 btrfs.1030
btrfs / --subvol --name=root LABEL=qubes_dom0

– but after removing the HFS+ ESP I can run the initial setup from a dom0 terminal and have working sys-net / sys-firewall / sys-usb:

sudo sed -i 's/ HFS+ ESP//' /root/anaconda-ks.cfg
sudo /usr/libexec/initial-setup/initial-setup-graphical

The build-in wifi doesn’t work [out of the box], so I’m using an USB network to write this - but I’ll probably play around with Qubes OS 4.2 and see if I can the internal WiFi working – I’ve already tested it with both Fedora 39 and Debian 12, so :crossed_fingers: it’s a matter of some configuration … :slight_smile:

1 Like
9

I got the WiFi working, as I wrote in:

:slight_smile: