You will laugh at me, but inserting a USB-A whilst booting gets past this.
1 Like
interesting. This changes the filesystem list in UEFI, so maybe its enough to get past the memory issue that grub seems to have. On the HP Omnibook X14 keyboard doesn’t work when booting fom type-c. It works when grub is on the internal SSD. Will try type-a, it should be supported to install from there now.
1 Like
Hardware: Thinkpad T14 Gen 6 Snapdragon Elite X
Only issues I am having with default install is unable to control brightness and no sound.
For brightness my only attempt to debug has been writing directly to sys/class/backlight/dp_aux_backlight/brightness but changing the value looks to have no effect
That also seems to work on my machine, just tried it. Weird. (maybe it was a coincidence but yeah)
Oh and Brightness control also doesn’t work on my T14s. (@ohchase just pointed that out)
1 Like
It does seem to be related to sth like that, I am assuming it is a firmware issue. I’ve seen the opposite before: it wouldn’t boot until I removed the plugged-in usb…
Anyway, time to add a bug to collect all that information.
1 Like
I created some bug reports addressing most of the issues
Maybe Lenovo might address that since they also ship ThinkPads with Ubuntu preinstalled? I’m not sure though…
Thanks for opening those, that helps a lot! I can’t promise anything but I am optimistic that the Lenovo team will be interested to hear about this and maybe even help us figure out what’s going on. The more data we have the easier it should be to narrow it down.
Unfortunately those errors seem to happen rather randomly on my machine. I have a feeling that they are more likely to happen after the machine has been powered off for a while but I don’t have data to back that up yet.
1 Like
After doing a slow-motion recording of my display I was able to capture an image of a totally different error message that leads to the same outcome
(it is really hard because its only visible for a single frame)
Edit: added to Bug Report 
2 Likes
I’ve done some more testing with FDE. Encryption with ZFS fails the same way.
Weirdly, when I install without encryption, then set up a new LUKS partition and try to mount it to /home using fstab and crypttab, it hangs during boot for a long while and eventually goes to the login screen without properly mounting it.
I discovered that systemd-cryptsetup-generator, which is responsible for converting /etc/crypttab entries into service entries, isn’t running. It’s also not among the other system-generators. I found it in the snap package ‘core22’ and ‘core24’, but there seems to be no ability to run them manually inside the snap (there are libraries distributed with them that aren’t on the base system).
For the time being, it seems that in order to automount encrypted partitions at boot, it’s necessary to author your own systemd service files.
So something goes sideways with the device tree. Memory issue as well?
1 Like
Until its in linux-firmware, you could try and use this board-2.bin to get working WLAN (and BT). For better BT quality/range a change in the btqca driver is required.
Well the only thing I can really say is the system completely being stalled after that and requiring a hard shutdown… so maybe there is a memory issue?
I do think though that it is definitely related to the device tree having issues… but why only sometimes?
Dynamic memory allocation. This UEFI stack is quite complex itself. And you see odd behaviour sometimes. On the Windows Dev Kit 2023 it is sometimes unbelievably stubborn with not recognizing USB keyboard. Or when you’re in EFI shell and browse around and load slbounce eventually, it might die on you (no kb reaction). No real causality visible. Best practice seems to have a setup that defaults into loading what you want most of the time.
1 Like
Well currently I’m in the state of (once again) being unable to boot Ubuntu at all, even with these “possible workarounds” of unplugging/plugging-in usb devices - it would be great if at least there was a pattern or anything like that but there isn’t.
Interesting though that the Dev Kit also has weird little quirks. Which firmware are these devices even using? Is it based on coreboot like the Surface Firmware or something else? It’s funny not seeing any Insyde branding in the ThinkPad firmware
cut from lshw and inxi -F:
capabilities: smbios-3.3.0 dmi-3.3.0 smp cp15_barrier setend swp tagged_addr_disabled
configuration: administrator_password=disabled chassis=desktop family=Surface sku=2043 uuid=e4a4662c-8367-75d0-a54f-1d04bd404860
*-firmware
description: BIOS
vendor: Microsoft Corporation
physical id: 8
version: 12.21.235
date: 07/09/2024
size: 1MiB
capacity: 4MiB
capabilities: pci upgrade shadowing bootselect edd int13floppynec int5printscreen int9keyboard acpi usb biosbootspecification uefi
UEFI: Microsoft v: 12.21.235 date: 07/09/2024
The base versions come from qcom according to the release pattern. They fix something, vendors adapt/propagate/release it.
Have you tried booting up EFI shell and starting grubaa64.efi from there?
Tried booting the EFI shell but for some reason it just resets my system… weird. Got it now, I will try doing that.
1 Like
Yeahhh, sadly that also doesn’t work. Weird, what changed for it to be unbootable right now?
Update: Wow after like 20 tries it booted now. Finally.
1 Like
Hmm to get the HP X14 boot reliably (grub was a PITA then with the kb issue) I went and installed systemd-boot and fought through its configuration. It worked, was ugly af, and after upgrading Ubuntu 24.04 to 24.10 with do-release-upgrade grub suddenly worked (from SSD).
But maybe it is a path to try out, since this Ubuntu 24.10 already supports efivars on Thinkpad T14s. I had to enable this first to get a working sd-boot install.
1 Like
I wonder if the bug you are seeing is related to Bug #2083919 “Oracular Oriole ARM64 ISO + install has boot conso...” : Bugs : livecd-rootfs package : Ubuntu
I’ve seen multiple reports suggesting that might not be entirely fixed yet but haven’t had time to try and reproduce it myself.
systemd-cryptsetup-generator should be part of the systemd-cryptsetup package.
$ dpkg -L systemd-cryptsetup | grep systemd-cryptsetup-generator
/usr/lib/systemd/system-generators/systemd-cryptsetup-generator
/usr/share/man/man8/systemd-cryptsetup-generator.8.gz