How do I debug non-booting Kernel? 5.12.10-1

I installed Kernel 5.12.10-1 from current testing. It appeared in xen.cfg, which I edited to make it ithe default.

Booting up again I got a complaint that the system could not start the virtual screen. I was not able to get into the system.

As usual, when this happens, I used another Linux to edit xen.cfg to point back to an earlier, working, version of the kernel.

How do I debug a problem kernel? Also, how do I find any other earlier kernels that might work? I used kernel-latest and kernel-latest-qubes-vm to get this one.

i assume you have entered grub menu, then load the configuration, after that you need to enter disk encryption session right ? if it was right, you can change to tty2 by :
ctrl + alt + 2
enter your disk encryption, then you should see boot up log.

1 Like

Thanks for your post. I believe I am using EFI, because editing the xen.cfg file in EFI effects change on the boot.

Thanks for letting me know that ctrl + alt + 2 will get me a shell. That is going to be useful.

I am wondering which files I should look at to figure out what the problem is?

Have you entered login session or not ? or you can’t enter the desktop ? i’m confuse with your statement about virtual screen, are you using sys-gui ?

if you can’t enter login session, the log will tell what causing it.

Thanks. I had to go out just now.

I didn’t enter the log on sceen. The system stopped and I rebooted it. It gave me an error message about not being able to start a virtual screen.

Then I booted from a Linux Mint USB and edited xen.cfg to select an earlier kernel.

I am typing from Qubes with an earlier kernel.

Which log? systemctl? dmesg? Something in /var/log/xen/console?

maybe you should try boot first with tty2 and seen for the boot log. I’m assuming it maybe because light dm / vm failed to start.

1 Like

I am unable to get into a shell on a failed boot (I just tried).

The error message on the screen is

Failed to start Setup Virtual Console.

It gets down to “Starting Plymouth Boot Screen…” but that is where it hangs. I can’t break in with ctrl - alt - 2 (I also tried Ctrl - Alt - F2, assuming that is what you may have meant).

After the error message it tells me to “See ‘systemctl status systemd-vconsole-setup.service’”

After getting into Qubes by using Linux Mint to alter the kernel back, I executed that command but it only said the service was presently running and the output has been rotated since the unit was started.

I wonder if I have properly installed kernel 5.12.10-1

When I try to install 5.12.10-1 it says that it is installed:

---> Package kernel-latest.x86_64 1000:5.12.10-1.fc25.qubes will be installed
--> Finished Dependency Resolution
/var/lib/qubes/dom0-updates/packages/kernel-latest-5.12.10-1.fc25.qubes.x86_64.rpm already exists and appears to be complete
Successfully verified /var/lib/qubes/dom0-updates/packages/kernel-latest-5.12.10-1.fc25.qubes.x86_64.rpm

When I run “rpm -qa” it isn’t listed.

rpm -qa "kernel"

If I try to package 5.12.10-1 for VMs, just to see if it is really there, I am told

qubes-prepare-vm-kernel 5.12.10-1.fc25.qubes 
ERROR: Kernel version 5.12.10-1.fc25.qubes not installed

I tried various ways to format that last command. I tried the numbers alone. I tried a longer string. I am not 100% I am typing in the right thing.

Hi Doria,

You installed a kernel-latest named package, rpm -qa "kernel" lists only the kernel named packages, so use:

rpm -qa "kernel*"

Yes because you installed a kernel-latest named package which is for dom0, and I see you want a kernel for a qube, so you should install the kernel-latest-qubes-vm

Read the managing-vm-kernels documentation.

1 Like

Thanks for your post.

I want to install a kernel which I can then modify to work with my NVIDIA card, so I want it in dom0.

I installed 5.12.10-1 but I can’t boot. It halts (see above). I was hoping to find out where the log files are which will help me see why the boot didn’t get to the login screen.

Hi @Doria

Kernel logs for N-1 boot (i.e. boot before current boot)

journalctl -b -1

Related documentation : systemd/Journal - ArchWiki

1 Like

For most, this is the recommended approach, but if you don’t mind giving an attacker who already has physical access easier access to your system without extra work, add the EDK2 UEFI Shell to your ESP partition and boot from that. It’ll allow “quicker” modification of xen.cfg and trial booting if playing with Xen/kernel options than having to load a full live USB distro.

Aside from the assortment of low-level access tools, it includes a simple text editor where xen.cfg can be modified quickly. Once in the shell, these commands will allow editing xen.cfg, then booting the Xen EFI loader:

# switch to the ESP partition

# go to where xen.cfg is
cd EFI
cd qubes

# open up xen.cfg in the "edit" text editor
edit xen.cfg

# start up Xen by running its EFI binary
1 Like