Hello dear Qubes Community!
I bought a ThinkPad X13 Gen 4 (AMD) to use QubesOS on it.
Unfortunately, I cannot start and install Qubes properly. The computer boots the written ISO from the USB stick and receives a long cryptic error message with a kernel panic at the end.
Unfortunately, the computer shuts down again in a flash after the errors, so I couldn’t even take a photo of the errors to do troubleshooting.
I am desperate.
What’s your laptop’s CPU?
Or laptop model?
Try to add module_blacklist=ucsi_acpi
to the kernel command line options in GRUB:
Kernel panic during installation on Lenovo Thinkpad P16s Gen 2 (AMD 7840U with 780M iGPU) - #5 by thinkpadfan443
You can add it like this:
Autostart troubleshooting | Qubes OS
The CPU is AMD Ryzen 7 PRO 7840U.
I will try your fix.
Thank you.
1 Like
Your command worked! I was able to start and install Qubes OS from the USB! Thank you.
Unfortunately, the touchpad does not work and my internal wifi adapter is not recognized after the installation.
The computer just turns itself off when I plug in or unplug USB devices, but not always?
I’ll do a few updates now and will get back.
Many thanks for your help!
Unfortunately I could not solve my problems. I think I’m still a Linux noob and need more time and knowledge to tackle these problems better.
To fix the problem with touchpad append this line:
GRUB_CMDLINE_XEN_DEFAULT="$GRUB_CMDLINE_XEN_DEFAULT ioapic_ack=new"
At the end of /etc/default/grub
file in dom0 and run this command in dom0 to regenerate GRUB config:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
What template do you use for sys-net qube?
If it’s Debian, then did you try to change it to Fedora to fix your problem with WiFi?
Thank you very much!
Unfortunately, I have already deleted Qubes OS again.
I will have another look at it when I find some time again.
In the meantime, I will upload an HCL report.
Hello,
I have reinstalled Qubes OS and tried your fixes.
The touchpad works!
I left the main template on Fedora during the installation of Qubes OS. The Net-VM runs on Fedora. Unfortunately the wifi card still does not work.
I was able to further isolate the sudden shutdown of the laptop via USB. My laptop shuts down with every USB connection that I disconnect from the computer, even when i disconnect the charging cable…
I have also noticed that the super key (Windows key) does not work/respond under Qubes.
1 Like
What’s your WiFI card model?
Check the output of this command in dom0:
lspci -nn
And post the VID:PID of your WiFi controller, it should be at the end of the line for your controller in brackets [XXXX:XXXX]
.
Append this line:
GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX module_blacklist=ucsi_acpi"
At the end of /etc/default/grub
file in dom0 and run this command in dom0 to regenerate GRUB config:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
It is a QCNFA765 Wireless Network Adapter from Qualcomm.
apparatus:
post the VID:PID
It is [17cb:1103].
I have also attached your line in GRUB. Unfortunately, this did not solve my USB problem.
I have another general question: Are there swipe gestures in Qubes OS that I can control using the touchpad?
It’s not supported by Xen:
QCNFA765 (wcn6855) WiFi6 controller not working
Similar issue was reported previously:
That’s strange, I didn’t see any such cases.
Does it work properly in other systems?
If yes then what if you run stress test in another system and unplug the power cable?
But without a fix.
To fix this issue you’ll need to get the crash log and report it to the Qubes OS developers so they could try to fix it.
If you’re up for it then you can get the crash log like this:
opened 04:58PM - 10 Aug 21 UTC
T: enhancement
C: installer
C: Xen
P: default
On laptops lacking physical serial console, collecting logs of a crashed Xen (or… dom0 kernel) is hard. One method is to use kexec to extract them from the RAM. Currently this requires several non-trivial changes to the system. This issue is to ease preparing system for such debugging.
Details from the original issue:
> > Isn't there tweaks that can be added from boot command line which would make logs saved synchronously and permit to troubleshoot this for everyone without a need of external additional devices @marmarek?
>
> Sadly, not. When Xen panic, dom0 has no chance to execute anything anymore. And it's dom0 who writes logs to the disk (or anything else for that matter).
@marmarek @fepitre
[From this comment](https://github.com/QubesOS/qubes-issues/issues/6066#issuecomment-891736396):
>As for collecting logs, I do have a method for that, but it's quite adventurous - make Xen kexec Linux on panic, to dump the memory content, and then to extract logs from there. It requires custom rebuilding Xen (because we have kexec disabled by default), kexec-tools (because the one in Fedora isn't built with Xen), build initramfs that dump the memory (kdump package helps with that, but requires few tweaks to make it work), and finally have some place to save the dump too - if using the main disk, you need to configure LUKS with a key file + allocate quite a lot of RAM for the crashkernel (because of memory-hard Argon2i in LUKS2). When having the dump, extracting messages is relatively easy - I use strings for that. Theoretically the crash utility can do that more conveniently, but it didn't work for me.
This exact QubesOS 4.1 ISO deployment (debug iso with all above dependencies preconfigured) would help to debug so many corner cases for QubesOS project, including this one? Instruct a willing [tester](https://forum.qubes-os.org/t/joining-the-testing-team/5190/1) to install QubesOS on spare drive and report results without having to go through the burden of customizing such testing testbed? Should that be discussed in a separate issue (with more details on doing this manual and then automate the process, maybe?)
> if using the main disk, you need to configure LUKS with a key file + allocate quite a lot of RAM for the crashkernel (because of memory-hard Argon2i in LUKS2)
@marmarek / @fepitre : Random thought, but if there is enough space affected to /boot in the default partitition scheme of that debug iso, dumping said logs from kexec'ed linux kernel to dump memory under /boot would work around a lot of the complexity added dumping needed logs and go faster into having what logs we need, easily, from an additioanl boot of said debug ISO in Read Only rescue mode from boot options.
_Originally posted by @tlaurion in https://github.com/QubesOS/qubes-issues/issues/6066#issuecomment-895447248_
And then report this issue on github:
GitHub - QubesOS/qubes-issues: The Qubes OS Project issue tracker
I think it depends on the desktop environment installed in dom0.
I guess XFCE doesn’t support it, but you can install other DE in dom0: KDE, i3, AwesomeWM etc, maybe they’ll support it.
There are guides for installing other DEs in Qubes OS on this forum and in the official docs:
Documentation | Qubes OS
Or maybe you need to install some app in dom0 to support in in XFCE e.g.:
2 Likes
Hello apparatus ,
thank you for your help.
Unfortunately, I can’t make a crash log because I need a special USB cable for this and I would have to schedule time again and get to grips with the subject a bit.
I have tested Qubes OS a bit and really wanted to make friends with this system, but unfortunately this USB error bothers me so much that the system is unusable for me.