Try to disable qubes autostart:
The following instructions are valid for Qubes OS R4.0 legacy mode and Qubes OS R4.1 legacy and UEFI modes. For Qubes OS R4.0 in UEFI mode, there is no GRUB, so manual boot from another operating system is needed. In several cases, there is a need to...
Maybe there is a problem with PCI passthrough in sys-net or sys-usb.
You can also enable additional logging but I’m not sure you’ll be able to see the reboot reason before it reboots:loglvl=all guest_loglvl=all vga=,keep noreboot=1console=hvc0 earlyprintk=xen plymouth.enable=0 panic=0plymouth.ignore-serial-consoles rhgb quiet
You can also try to debug it using USB:
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_
4 Likes