How to: Diagnose Qubes-OS boot issues?

User Support Hardware Issues
1

A Lenovo Thinkpad W540 running Qube-OS 4.1 will only run if kernel version 5.15 is selected. If any kernel version 6.1… is selected the PC starts to boot and then reboots. (see Qubes-dist-upgrade (4.1 to 4.2) Details for other related questions)

I want to diagnose the issue with the 6.1… kernels rebooting and would like tips on this diagnostic process.

I started by removing the quiet keyword in the GRUB kernel line. This demonstrated to me that kernel execution seems to make considerable progress before the reboot occurs.

After this I added the line acpi=“off” which lead down an interesting path that may be an indication of what the issue is.

I also tried other kernel command line switches in GRUB with little effect but perhaps this was not quite right. Any tips would be appreciated. Some options tried or considered were (vt.handoff=7, vga, vga=0x31B, debug, debug=“top”) As far as I know it is not possible to pause or step through the boot process, so if there is a way please let me know.

So after booting with acpi=“off” this is what happened: (note: may not be verbatim -and ignore automatic syntax highlighting colours)

  System boots but stops at:
    ...
    [OK] ... 
    [OK] Started Command 
         Starting Light Display Manager...
         Starting Hold until boot process finishes up...

At this point the operating systems has booted but X session and LightDM have not started.
I Logged into a terminal (Ctl+Alt+F2) - systemctl indicates:

                          LOAD   ACTIVE SUB
        lightdm.service - Loaded failed failed   - Light Display Manager

/var/log/lightdm/lightdm.log indicates:

      Process 3646 terminated with signal 6
      XServer 0: X Server stopped
      ...
      Required seat has stopped
      Stopping display manager
      Display manager stopped 
      Stopping daemon
      Exiting ...

Trying to run X session using startx fails with similar errors
Try to run X Server with X command:

     ...
     (EE) 
     Fatal server error:
     (EE) no screens found(EE)      
     ...

/var/log/Xorg.0.log reveals:

         ...  X.Org Video driver version 24.1
        ...
        (II) VESA: driver for VESA chipsets: vesa
        (EE) open /dev/dri/card0: No such file or directory
        (WW) Falling back to old probe method for modesetting
        (EE) open /dev/dri/card0: No such file or directory
        ...
        (EE) Uable to find a valid framebuffer device
        (WW) Falling back to old probe method for fbdev
        ...
        (EE) open /dev/fb0: No such file or directory
        (EE) Screen 0 deleted because of no matching config section.
        (II) UnloadModule: "modesettings"
        (EE) Screen 0 deleted because of no matching config section.
        (II) UnloadModule: "fbdev"
        (II) UnloadSubModule: "fbdevhw"
        (II) Loading sub module: "vbe"
        (II) LoadModule: "vbe"
        ...
        ...
        (II) VESA(0): initializing int10
        (EE) VESA(0): V_BIOS address 0x2e180 out of range
        ... unload modules: vesa, int10, vbe
        ...
        (EE) Screen(s) found, but none have a usable configuration. 
        ...

Conclusion:

  1. There seems to be an ACPI (Advanced Configuration and Power Interface) issue.
  2. There seems to be a display adapter support issue.

Is this assessment right?
What further diagnostics steps can be taken to verify and resolve these issues?

2 Likes
2

Hi @qubanoid,

I will start off with a few questions and a recommendation of something to try.

Questions:

  1. What GPU is being used in this system?
  2. Are you sure that the initramfs image for the 6.1 kernel contains the necessary modules to support your GPU? (can be an issue with newer GPU’s or GPU’s which require an additional package to be installed)
  3. What behavior occurs when you append “nomodeset” to the grub cmdline?

Advice:

  1. Identify what kernel modules are being leveraged for the display while booting into the functional image and work to ensure those same kernel modules are present in the non functional image.
  2. Conduct extensive research on issues reported for your particular GPU on any available bug trackers (and google). This should include searching the Qubes Issue tracker, xorg issue tracker, xen issue tracker, stackoverflow, askubuntu, reddit, Fedora issue tracker, Qubes mailing list. The goal here is to identify any already reported issues involving your GPU and the tech-stack being utilize in your instance.
1 Like