Trouble Installing Qubes (R4.0.4 / R4.1.0)

I have being trying to install Qubes R4.1.0 on a Intel NUC X15 Laptop (LAPKC71F - 11th Gen i7-11800H with NVIDIA RTX 3070) - There is a similar spec machine in the HCL lists - same CPU with RTX 3060, but the native screen is 1920x1080 where mine is 2560x1440. I have tried using a couple of external monitors but they don’t initialise even with the laptop screen closed.

I have verified that with the exception of the RTX 3070 the hardware should all be compatible. VT-x with EPT + VT-d + Intel PTT (Equiv of TPM).

I have tried multiple USB keys, with R4.0.4 & R41.0, installed multiple ways (linux and Windows). Both versions meet all signature and checksum checks. All of them seem to boot just fine and the problem occurs consistently within each version of Qubes but it not the same problem for v4.0.4 as v4.1.0.

I have tried both Secure and Non-Secure Boot and both perform the same as far as I can tell. Legacy BIOS is not supported on this machine as far as I can tell.

I have tried modifying the BOOTx64.cfg options in R4.0.4. I couldn’t find those options in the EFI partition on R4.1.0. I have tried to work through each suggestion from the “Installation Troubleshooting”, “UEFI Troubleshooting” and “Nvidia Troubleshooting” pages.

In the “Installation Troubleshooting” under the “Not asking for VNC….” section the second line of code appears abbreviated or possibly has a typo —- intitrd.img. I’m not fully confident with those changes and may have done them wrong, especially as I’m not sure if they should go in the main partition (1st) under EFI/BOOT/BOOTX64.cfg which I can’t edit.

R4.0.4 boots and produces the following screen, then the laptop reboots.

The last line is Initrd.img: 0x0000000026660000-0x0000000027a89410

R4.1.0 boots and allows me to chose 1 of the 4 grub options. The Troubleshooting (verbose) option produces the following, then the screen clears (from the top) and sits quietly until I eventually turn it off with a long press of the power button.
I will need to load the second image in a reply as I am a new user and limited to one media item per post.
The last line is (XEN) Xen is relinquishing VGA console.

I have tried to carefully search the forum, documentation and web but have not found the answer I need. Hopefully someone can give me a pointer in the right direction. TIA.

This was the image from R4.1.0

Progression on my R4.1.0 issue. When booting (secure or non-secure boot) I used the ‘e’ option in Grub to change the settings as follows;

multiboot2 /images/pxeboot/xen.gz console=vga loglvl=all vga=current,keep guest_loglvl=all
module2 /images/pxeboot/vmlinuz inst.stage2=hd:LABEL=QUBES-R4-1-0-X86-64 console=hvc0
module2 /images/pxeboot/initrd.img

This prevented the (XEN) Xen is relinquishing VGA console. and allowed me to see an error occurring. It runs very slowly, presumably because of the output to the screen, but after about 8 minutes it crashed with the error [ 287.471169] watchdog: BUG: soft lockup - CPU#3stuck for 22s! [swapper/0:1] and started a repeating loop.

I managed to capture the install using video from my phone and will attach a screen shot of the failure point. Which may hopefully provide further clues.

As an aside and for the benefit of others at my level, I found lots of posts regarding the missing /EFI/BOOT/BOOTX64.cfg in R4.1.0. The format may be different but options (as shown above) appear to work in grub.cfg. This can be edited either as above by pressing ‘e’ in the grub menu or by mounting the 2nd EFI partition (in Linux Mint mine doesn’t auto mount) and then editing from the relevant mount point. i.e.
vi /media/<userid>/ANACONDA/EFI/BOOT/grub.cfg
Hopefully this helps someone.

1 Like

This is the full error loop - the CPU# changes each boot

This may have been slightly misleading. I added the option watchdog_thresh=120 to the vmlinuz line and the installation has now progressed further. I am now hoping the Qubes installer screen will appear… Sadly it wasn’t to be…

The installer progressed until it hit another series of errors which all produced traces. There is a lot of output to go through! :face_with_raised_eyebrow:

I captured the following before shutting the machine down. I’ll have to video it again to try and work out where it starts.

1 Like

I am no expert by any means, but I read that it could be either customizing BIOS, or CPU clocks, or it is power supply… Sorry if this is misleading.

1 Like

Thanks for the link. I have read through and it gave me a few things to check tomorrow. I am hoping that it isn’t a power supply fault on a brand new machine1 :exploding_head:

Following on from this I thought I should test something else on the laptop, as nothing has ever been installed on this machine, to see if the machine works ok. I decided to use a Fedora 32 Live CD on the basis that it it the same as the main linux version used by R4.1.0. This booted ok with no changes. The touchpad didn’t work and the screen resolution was limited but it other seemed to be working ok. I used exactly the same dd method to create the bootable USB key from the ISO. Looking at the options used in Grub by the Fedora ISO wasn’t very revealing - there weren’t really any!

I also went searching the errors from last night which led me to the i915 drivers and a Qubes GitHub post indicating i915.alpha_support=1 has been depreciated in favour of i915.force_probe=*. I tried it but it didn’t seem to make any difference. Can anyone advise on this as the first one is still in the UEFI Troubleshooting Guide?