Hello, I’ve got a shiny new laptop here and I’d like to get Qubes 4.2.3 running on it, but I’ve run into some snags. Here’s a list of problems I’ve encountered, and solutions where I’ve been able to find them:
Installer kernel panics on boot
Solution: Edit bootloader options, add module_blacklist=ucsi_acpi to the line containing vmlinuz
Trackpad does not work on installer boot
Additional issues in the installed Qubes environment includes screen blanking on FDE Password screen, screen brightness controls not responding correctly
Solution: Edit bootloader options, add ioapic_ack=new to line starting with multiboot2
To permanently fix the above at install-time:
Install as normal until you get to the end with the “Reboot Now” button
Press Ctrl-Alt-F2 to switch to another console
run nano /mnt/sysimage/boot/grub2/grub.cfg
add ioapic_ack=new to line starting with multiboot2
run nano /mnt/sysimage/etc/default/grub
add ioapic_ack=new to the quoted portion of the line beginning GRUB_CMDLINE_XEN_DEFAULT
Qubes does not seem to be able to turn off the internal display - It’ll blank it, but the backlight stays on no matter what power management settings I select.
Panel power-off is somewhat counter-intuitively (For a Windows user like me, at least) configured in XScreenSaver, not in Power Options.
I’ve so far discovered two issues which I haven’t been able to find solutions to:
Disconnecting the USB-C power-supply causes the machine to lock up and reboot - I presume this is a kernel panic that I’m just not able to see the text of.
Qualcomm QCNFA765 wifi does not work
The machine is running the latest BIOS published by Lenovo, version 1.39.
I went and installed kernel-latest for both dom0 and domU, and increased the memory allocation for sys-net to 1024MB
This also changed the USB-C power disconnect behavior - Qubes now manages to live for long enough to display a notification that the power supply has been disconnected, before freezing up and rebooting.
[ 0.000000] Linux version 6.11.10-1.qubes.fc37.x86_64 (mockbuild@98260ff37ee0473287dfc4b33934ad19) (gcc (GCC) 12.3.1 20230508 (Red Hat 12.3.1-1), GNU ld version 2.38-27.fc37) #1 SMP PREEMPT_DYNAMIC Sun Nov 24 02:21:12 GMT 2024
...
[ 3.573492] ath11k_pci 0000:00:07.0: BAR 0 [mem 0xf2000000-0xf21fffff 64bit]: assigned
[ 3.576373] ath11k_pci 0000:00:07.0: MSI vectors: 1
[ 3.577043] ath11k_pci 0000:00:07.0: wcn6855 hw2.1
...
[ 3.772613] mhi mhi0: Requested to power ON
[ 3.772694] mhi mhi0: Power on setup success
[ 4.226394] mhi mhi0: Wait for device to enter SBL or Mission mode
...
[ 4.854340] ath11k_pci 0000:00:07.0: chip_id 0x12 chip_family 0xb board_id 0xff soc_id 0x400c1211
[ 4.854366] ath11k_pci 0000:00:07.0: fw_version 0x11088c35 fw_build_timestamp 2024-04-17 08:34 fw_build_id WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41
[ 4.992797] ath11k_pci 0000:00:07.0: leaving PCI ASPM disabled to avoid MHI M2 problems
...
[ 6.018430] ath11k_pci 0000:00:07.0: failed to receive control response completion, polling..
[ 7.042458] ath11k_pci 0000:00:07.0: Service connect timeout
[ 7.042502] ath11k_pci 0000:00:07.0: failed to connect to HTT: -110
[ 7.043331] ath11k_pci 0000:00:07.0: failed to start core: -110
[ 7.173499] vif vif-8-0 vif8.0: Guest Rx ready
[ 7.252546] ath11k_pci 0000:00:07.0: firmware crashed: MHI_CB_EE_RDDM
[ 7.252594] ath11k_pci 0000:00:07.0: ignore reset dev flags 0x4000
[ 7.360063] ath11k_pci 0000:00:07.0: firmware crashed: MHI_CB_EE_RDDM
...
[ 17.538497] ath11k_pci 0000:00:07.0: failed to wait wlan mode request (mode 4): -110
[ 17.538577] ath11k_pci 0000:00:07.0: qmi failed to send wlan mode off: -110
Tried swiotlb=8192, 16384, and soft. No difference.
Digging through the logs, I did notice
[2024-12-07 20:02:19] [2024-12-07 20:02:19] [00:07.0] xen_pt_realize: Assigning real physical device 02:00.0 to devfn 0x38
[2024-12-07 20:02:19] [00:07.0] xen_pt_register_regions: IO region 0 registered (size=0x00200000 base_addr=0x78600000 type: 0x4)
[2024-12-07 20:02:19] [00:07.0] xen_pt_config_reg_init: Offset 0x000e mismatch! Emulated=0x0080, host=0x0000, syncing to 0x0000.
[2024-12-07 20:02:19] [00:07.0] xen_pt_config_reg_init: Offset 0x0010 mismatch! Emulated=0x0000, host=0x78600004, syncing to 0x78600004.
[2024-12-07 20:02:19] [00:07.0] xen_pt_config_reg_init: Offset 0x0042 mismatch! Emulated=0x0000, host=0x0003, syncing to 0x0003.
[2024-12-07 20:02:19] [00:07.0] xen_pt_pm_ctrl_reg_init_off: PCI power management control passthrough is off.
[2024-12-07 20:02:19] [00:07.0] xen_pt_config_reg_init: Offset 0x0074 mismatch! Emulated=0x0000, host=0x12c8fc0, syncing to 0x12c8fc0.
[2024-12-07 20:02:19] [00:07.0] xen_pt_config_reg_init: Offset 0x007a mismatch! Emulated=0x0000, host=0x0010, syncing to 0x0010.
[2024-12-07 20:02:19] [00:07.0] xen_pt_config_reg_init: Offset 0x0082 mismatch! Emulated=0x0000, host=0x1013, syncing to 0x1013.
[2024-12-07 20:02:19] [00:07.0] xen_pt_realize: no pin interrupt
[2024-12-07 20:02:19] [00:07.0] xen_pt_realize: Real physical device 02:00.0 registered successfully
Note the Linux kernel is making logs about “Disabling ASPM to avoid problems with MHI.” Is Xen not letting the kernel do that, therefore causing MHI to fail?
What’s the device 0000:00:07.0? Your QCNFA765 wireless adapter is 02:00.0, but ath11k_pci fails to interact with 00:07.0. Sorry if I missed it somewhere in the logs.
I think that’s Xen’s remapping - 02:00.0 is the physical hardware, but Xen remaps it over to 0000:00:07.0 in the virtual hardware space of sys-net. You can see that in the first line of the logs I just posted.
So I’ve produced a set of instructions to apply this patch on a new install of 4.2.4, and install it to dom0.
PLEASE NOTE
I make no guarantees regarding the security of this process. I don’t understand how all these moving pieces interact with each other.
These instructions will likely need to be updated in the event of a security update for xen-hypervisor. They almost certainly will not work for any later release of Qubes.
Building a patched xen-hypervisor to fix the Lenovo ACPI power-supply disconnect crash
This is based mostly on: https://github.com/QubesOS/qubes-builderv2/
Unfortunately, that page contains a million details for things that are not relevant for this task, so here's my boiled-down instructions
*** Setting up the environment and host for qubes-builderv2
* Open Qubes Manager
* Clone your fedora template as work-qubesos-template
* Clone your default-dvm to work-qubesos-dvm
* Adjust settings for work-qubesos-dvm
* Change the template to work-qubesos-template
* Set private volume storage to 32GB <-- double check this. There's a UI quirk in Qube Manager that means it might not take
* Create a new AppVM Qube, call it work-qubesos (This name is important!). Set it to the work-qubesos-template template.
* Launch a Terminal in work-qubesos, and run these commands:
* git clone https://github.com/QubesOS/qubes-builderv2/
* cd qubes-builderv2
* qvm-copy dependencies-fedora.txt
* Select work-qubesos-template from the popup
* qvm-copy dependencies-qubes-executor.txt
* Select work-qubesos-template from the popup
* git submodule update --init
* Open a terminal in work-qubesos-template
* sudo dnf install $(cat QubesIncoming/work-qubesos/dependencies-fedora-qubes-executor.txt)
* sudo dnf install $(cat QubesIncoming/work-qubesos/dependencies-fedora.txt)
* In a dom0 terminal, run the following:
* sudo qvm-run --pass-io work-qubesos -- 'cat /home/user/qubes-builderv2/rpc/policy/50-qubesbuilder.policy' > /etc/qubes/policy.d/50-qubesbuilder.policy
* qvm-prefs work-qubesos default_dispvm work-qubesos-dvm
* Open a terminal in work-qubesos-dvm
* sudo su
* mkdir -p /rw/bind-dirs/builder /rw/config/qubes-bind-dirs.d
* echo "binds+=('/builder')" > /rw/config/qubes-bind-dirs.d/builder.conf
* echo "mount /builder -o dev,suid,remount" >> /rw/config/rc.local
* Shutdown work-qubesos-template, work-qubesos-dvm, work-qubesos
*** Configuring and invoking qubes-builder
* Launch a terminal in work-qubesos
* cd qubes-builderv2
* cp example-configs/qubes-os-r4.2.yml builder.yml
* ./qb -c vmm-xen -d host-fc37 package fetch
* nano artifacts/sources/vmm-xen/xen.spec.in
* After the line starting 'Patch1202:', add a new line. Add a few newlines around here if you want to keep things readable. Feel free to add a comment if you like.
* Patch2000: 2000-lenovo-acpi-crash-fix.patch
* <Ctrl-x>, y, <enter>
* nano artifacts/sources/vmm-xen/2000-lenovo-acpi-crash-fix.patch
* Paste in the ACPI patch
* <Ctrl-x>, y, <enter>
* ./qb -c vmm-xen -d host-fc37 package prep build
*** Pulling the binary package into dom0 and installing it
* Open a dom0 terminal
* sudo qvm-run --pass-io work-qubesos -- 'cat /home/user/qubes-builderv2/artifacts/components/vmm-xen/4.17.5-6/host-fc37/build/rpm/xen-hypervisor-4.17.5-6.fc37.x86_64.rpm' > xen-hypervisor-4.17.5-6.fc37.x86_64.rpm
* sudo dnf reinstall ./xen-hypervisor-4.17.5-6.fc37.x86_64.rpm
Shutdown and restart the computer
Go ahead and disconnect the power supply, and enjoy your computer not crashing!