Freeze during installation AMD Thinkpad L14 Gen 3

I have an AMD Thinkpad L14 Gen 3 Ryzen 7 PRO 5875U (HCL). I added the kernel parameters recommended in the HCL topic, but am still having an issue: I reach the initial setup screen and within a couple of seconds, my touchpad and buttons stop working. I am unable to continue with the setup.

Any suggestions?

Note: the post was slighty edited for clarity when the topic was split (bold text).

I missed nomodeset the first time. After adding all the below kernel options, I got the installer to start installing, but it froze on “Installing TemplateVM fedora-37”. I could still move the mouse, but the “[Dom0] Qubes OS Setup” window with the progress bar was frozen. I tried again and it got stuck on “Installing TemplateVM whonix-ws-16”

Any ideas?


dom0_max_vcpus=1 dom0_vcpu_pin nomodeset clocksource=tsc tsc=unstable hpetbroadcast=0

I added these by going to the line that loads the kernel vmlinuz and pressing Ctrl + e to go to the end of the line, then typing them in and pressing Ctrl + x

After GRUB, I was receiving the error:

Warning: USB in dom0 is not restricted. Consider rd.qubes.hide_all_usb or usbcore.authorized_default=0

So I added usbcore.authorized_default=0 to the list of boot options. Now it runs “Executing qubes configuration” then, a minute later, an error window pops up:

Qubes initial configuration failed. Login to the system and check /var/log/salt/-minion for details. You can retry configuration by calling ‘sudo qubesctl --all state.highstate’ in dom0 (you will get detailed state there).

I hit “OK” and log in, open a terminal (using the trackpoint; the trackpad doesn’t work) and run

# qubesctl --all state.highstate
...
Succeeded: 25 (changed=2)
Failed:       4

When I scrolled up, I saw:

[Errno 2] No such file or directory: '/etc/qubes-rpc/qubes.TemplateSearch'

And then the system totally froze. So I hard rebooted and added all the boot flags above (this time rd.qubes.hide_all_us was already there).

I tried various things, but the system kept eventually freezing (and seems to be sluggish as it was before I added those flags), so I added to the end of /etc/default/grub:

# my customizations
GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX dom0_max_vcpus=1 dom0_vcpu_pin nomodeset clocksource=tsc tsc=unstable hpetbroadcast=0

Then ran sudo grub2-mkconfig -o /boot/efi/EFI/qubes/grub.cfg and rebooted.

Now I’m stuck with a system that keeps freezing.

Could you make a separate thread for your issue? This would give you more chances to receive support fan adding messages to an HCL report :slight_smile:

1 Like

@zaz I think @solene is right, so I went ahead and split the topic to give more visibility to your questions. I edited slightly the first post when doing that, please feel free to correct if I got anything wrong!

Note that the process of splitting a topic leaves a link in the original thread, so folks reading the HCL conversation will still come across your issue.

1 Like

Note that I never used dom0_max_vcpus=1 dom0_vcpu_pin and clocksource=tsc tsc=unstable hpetbroadcast=0 at the same time.
As I can remember, I first used dom0_max_vcpus=1 dom0_vcpu_pin to get installer working. Then I think that after installation was complete and I booted into Qubes, I also added nomodeset.
I then completed all Dom0 updates and only after that I discovered that clocksource=tsc tsc=unstable hpetbroadcast=0 resulted in proper performance. I did not try those earllier. That’s also just those parameters, so no dom0_max_vcpus=1 dom0_vcpu_pin or nomodeset.
Hope this helps you.
Also remove the default quiet parameter to get more information.

EDIT: if touchpad and lower mouse buttons stop working, maybe upper mouse buttons and red ‘trackpoint’ button still can be used.

Thank you! The trackpoint works fine, but it’s bizarre that the trackpad works for about 10 seconds after logging in. I still can’t open any Qube. Below are some of the errors I’m having.

dom0 kernel: i2c_designware AMDI0010:00: controller timed out
dom0 kernel: pciback 000:01:00.0: not ready 1023ms after FLR; waiting
dom0 kernel: i2c_designware AMDI0010:00: controller timed out
dom0 kernel: pciback 000:01:00.0: not ready 2047ms after FLR; waiting
dom0 kernel: i2c_designware AMDI0010:00: controller timed out
dom0 kernel: pciback 000:01:00.0: not ready 4095ms after FLR; waiting
dom0 kernel: pciback 000:01:00.0: not ready 8191ms after FLR; waiting

I was receiving this error:

dom0 libvirtd[1886]: internal error: libxenlight failed to create new domain 'sys-net'
dom0 libvirtd[1886]: internal error: Unknown PCI header type '127' for device '0000:06:00.0'
dom0 libvirtd[1886]: Failed to reset PCI device: internal error: Unknown PCI header type '127' for device '0000:06:00.0'

So I opened Qubes Manager » sys-net settings » Devices » and removed 06:00.0 Network controller: MEDIATEK Corp., but it still does not work:

$ qvm-start sys-net
Start failed: internal error: libxenlight failed to create new domain 'sys-net', see /var/log/libvirt/libxl/libxl-driver.log for details

/var/log/libvirt/libxl/libxl-driver.log:

libxl: libxl_dm.c:2801:stubdom_xswait_cb: Domain 8:Stubdom 9 for 8 startup: startup timed out
libxl: libxl_create.c:1913:domcreate_devmodel_started: Domain 8:device model did not start: -9

I checked this bug https://github.com/QubesOS/qubes-issues/issues/7717 and ran xl pci-assignable-list. Both my ethernet device and WiFi device are included in the output list, which should be a good sign.

Current problem: no VM will start

E.g. starting vault will claim success (or sometimes the VM will immediately shut down), but I will not be able to open any program, including a terminal. Sometimes the VM will use 100% CPU.

When I run sudo xl console -t pv vault, I get the below:

WARNING: CPU: 0 PID: 1 at kernel/time/clockevents.c:310 clockevents_program_event+0xac/0xf0

And after adding back in the clocksource boot flags mentioned above, I receive the same error:

Is this the kernel crashing and, if so, why?

Thank you for taking the time to read all of this!

Hmm that is really strange. Regarding the WiFi card: I’ve had similar errors but it only delayed boot, networking still worked fine: WiFi PCI issues on Thinkpad L14 AMD Gen 3
If sys-net can’t start, other VM’s with networking also fail to start. But vault should work then. It seems you experience other issues, with also the trackpad failing after 10 seconds.

Did you try updating the bios? I’m now on the latest 1.26.
And are you on kernel 6.1?
Other than that I don’t have any ideas, so I hope some else can help you.

1 Like

Thank you for your help!

I’m on BIOS 1.21 and the stock Linux kernel. Updated would be a great idea and I disabled WiFi in the networking Qube in the hopes I could connect via ethernet to update the kernel, but have not been able to open any VM.

How can I update the kernel and BIOS?

You can download a bootable ISO from Lenovo to update the bios:

You can download kernel packages for Dom0 on another machine here:
https://ftp.qubes-os.org/repo/yum/
Afaik somewhere on this forum are instructions how to verify and install them.

Thanks a lot for your continued help! I didn’t notice that BIOS update utility at first because it was marked as being for Windows 10/11. It worked and I’m now on BIOS 1.26!

I’m about to follow these instructions to install the kernel or, failing that, figure out how to do it based on this description of the dom0 update process.

I’m planning on using kernel 6.1.43, unless you would advise a different one that you know works for you?

Yeah that sounds good. Older 5.x kernel did work mostly for me, without your issues. I needed 6.1 though for proper suspend and WiFi support. Versions higher than 6.1 sometimes cause random crashes, so I would indeed advise 6.1.43.

Thank you. I had some issues installing 6.1.43, but on 6.4.8 I was having the exact same issues with any combination of boot flags I tried.

Do you have any idea from this log what might be going wrong? Or do you know where I should seek help or what other logs I should get?

vault-start-error5-without-CPU-boot-flags.log (23.7 KB)

I’m suspecting some sort of clock issue or SSD issue, but I really don’t know.

Other logs

vault-start-error1.log (27.8 KB)
vault-start-error2.log (27.7 KB)
vault-start-error3-after-kernel-update.log (28.2 KB)
vault-start-error4-after-kernel-and-VM-kernel-update.log (11.4 KB)
Qubes-HCL-LENOVO-21C6S08E00-20231026-110531.yml (853 Bytes)
Qubes-HCL-LENOVO-21C6S08E00-20231027-112136.yml (879 Bytes)

Sorry, I can’t help there. When I check the logs for ‘error’ there are only a few about ACPI, but I have those same errors and no issues.
The only thing I can think of now is maybe your BIOS settings are wrong. Is Virtualization / AMD-V enabled? And maybe there is a separate option for IOMMU but probably not as I don’t have a separate option either.

Thank you for all your help! AMD-V is enabled, and there is no separate IOMMU option.

I’m starting to suspect maybe the sundry issues I had during the whole install process have resulted in an incorrect installation on disk.

At the start of boot, while the red Lenovo logo is still showing, I see:

Welcome to GRUB!

error: file `/EFI/qubes/fonts/unicode.pf2' not found.

What do you think my next step should be? Retry installation, using the cpu flags you suggest from the beginning? If so, which version? 4.1 or 4.2 (testing)? Or is there a way to verify integrity of an installation? Or is there a better place to seek help with these kernel issues?

And while I’m doing all of this, is there anything I can do to help get the laptop automatically supported? E.g. submit pull requests for boot flags that are required for this laptop? Or anything I should be careful to document?

In any case, thank you for all your help!

I would retry installation. I haven’t tried 4.2 myself yet. I installed Qubes back in january, so that was 4.1.1 specifically. If 4.1.2 doesn’t work, maybe try 4.1.1.

I don’t think there is a way to verify the installation. You could verify installation media after writing to be at least sure that it has been correctly written:

And about the boot flags, there is an issue here, but there doesn’t seem to be much progress:

One comment mentions Lenovo issued a BIOS update that fixes TSC clock issues on Linux and he didn’t need the boot flags anymore after the update.
It seems more recent Lenovo hardware has the same issue. I reported it for the L14 here:
https://forums.lenovo.com/t5/Other-Linux-Discussions/Thinkpad-L14-Gen-3-AMD-TSC-issues-under-Linux-Xen/m-p/5196833?page=1#5905538
Supposedly a BIOS update is still coming for the L14 but that was more than half a year ago…

Just a random thought, do you have a 4kn SSD drive? If you have nvme-cli tools installed in dom0, you can check that by running nvme id-ns -H /dev/nvme0n1, and see the Data Size of the “( in use )” LBA Format. Source: arch linux - How to understand the output of the nvme command? - Unix & Linux Stack Exchange

1 Like

Great idea! I was starting to suspect it might be an SSD issue myself seeing as RAM and SSD is one of the only way Scumbag’s setup differs from mine.

I do not have nvme-cli installed and its a pain to install packages without internet. I used SMART tools and also fdisk; both reported a sector size of 512 bytes. I’m using a Samsung 990 Pro. Does that rule out 4kn? If not, is there a way to check without installing nvme-cli?

Interestingly, fdisk does show an error above Disk /dev/mapper/qubes_dom0-vm--fedora--37--root--import and Disk /dev/mapper-qubes_dom0-vm--whonix--ws--16--root--import

The backup GPT table is corrupt, but the primary appears OK, so that will be used.

Does this add support for the theory that something went wrong during install and that I don’t have a clean install?

sudo smartctl --all /dev/nvme0n1 also shows an error:

Error Information (NVMe Log 0x01, 16 of 64 entries)
Num   ErrCount  SQId   CmdId  Status  PELoc          LBA  NSID    VS
  0     502501     0  0x0014  0x4004      -            0     0     -

Thank you both for your help!

1 Like

Now, with Qubes 4.2.0, installing on the L14 works out of the box!

2 Likes