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.
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.Documentation | Qubes OS
Or maybe you need to install some app in dom0 to support in in XFCE e.g.:
2 Likes