Early userspace debugging of standalone qube

User Support General
1

Hi,

I’m in the process of configuring a standalone HVM qube based on Fedora-40-xfce, with the end goal of installing an nvidia driver and virtual gl. I was previously successful with qubes 4.2.2, but I’ve run into an issue with the installation of the nvidia driver on 4.2.3. While it seems to install just fine, the subsequent boot stalls until inevitably reaching the qrexec timeout. Monitoring the boot from a console uncovers a lot of failing services. I’ve tried to add various rd.break=X to the qube’s kernelopts, but to no avail.

My immediate concern is not so much the failing services as it is my inability to see what’s going on during boot. Rd.break is invaluable for debugging early userspace problems. Is there any way I can get the qube to honor this kernelopt?

Thank you!

2

What’s your configuration steps? Are you stalling after successfully building the driver, or the build fails?

3

Build succeeds and the installer even loads the kernel modules without issue. It’s just the following reboot where I encounter problems.

As for the build itself, I just extract the *.run file with - x (to avoid having to resize /tmp) and run nvidia-installer --ui=none -m=kernel-open.

4

Do you have a requirement to run fedora 40? Maybe jumping to 41 will magically solve your problems

Also try installing from rpmfusion.

5

Thanks otter2. No I have no particular need for Fedora 40. In the end I was able to get everything (nvidia, virtualgl, and emergency shell) working by switching the kernel and initramfs to the those provided the qube itself. Having said that, I would still like to understand how I might be able to drop to an emergency shell when using the common (default) kernel and initramfs. Not being able to do this constitutes a big hole in my general ability to debug problems.

6

Oh, thing is that you must run in-qube kernel if you want to have modules built for it (like nvidia drivers). I don’t think you can have a shell until the qube boots (or more precisely you can have a console, but there is nothing to interact with, just look at the messages (except of grub)), and it might just not boot with a wrong kernel.

Nonetheless, you don’t need a console to read logs. You can find them in /var/log/xen/console/guest-VMNAME.log (in dom0)