Brian, some questions about your issue with the X13s not booting with the F44 live images:

1. What distro are you running on the laptop currently and with which kernel version ?

2. Are you using the BIOS' builtin option to load a DTB from the ESP, copying a sc8280xp-lenovo-thinkpad-x13s.dtb file to /boot/efi ? Or IOW did you go into the BIOS setup (F1) and enable -> Config → Linux → Linux Boot (Beta) ?

If yes can you try disabling that option and then try the F44 live image again? That option should no longer be necessary with the auto DTB selection in the F44 live images.

One more question:

3. Assuming you already have Linux running on the laptop, can you download: https://raw.githubusercontent.com/ubuntu/stubble/refs/heads/main/hwids/hwids.py and run it and attach the output here. Maybe your laptop has some weird hwids / DMI strings causing the autodtb loading to not load any DTB...

Hans, I have Fedora 43 installed on the system. I've been using Fedora on this laptop since I bought it new in 2022. I have the Linux option turned off in the BIOS, and I explicitly specify the DTB in grub because I use this for kernel development. I have it setup as described in the Fedora Wiki at https://fedoraproject.org/wiki/Thinkpad_X13s. (I've contributed to that page the last few years to keep it current.)

Below is the hwids output. Stubble has an existing 21BX file, however my IDs only match for 3 IDs: 1) Manufacturer, 2) Manufacturer + Family, and 3) Manufacturer + ProductSku. I didn't look through the stubble source code yet, but would that be enough for it to match to that DTB?

Computer Information
--------------------
Manufacturer: LENOVO
Family: ThinkPad X13s Gen 1
ProductName: 21BX0016US
ProductSku: LENOVO_MT_21BX_BU_Think_FM_ThinkPad X13s Gen 1
BaseboardManufacturer: LENOVO
BaseboardProduct: 21BX0016US
EDID: IVO854b
Hardware IDs
------------
{a64bdbe1-02b1-5770-b6ba-844219bfddd4}	<- #3   Manufacturer + Family + ProductName + ProductSku + BaseboardManufacturer + BaseboardProduct
{ddb102a8-1024-51a4-8f19-175a687b652e}	<- #4   Manufacturer + Family + ProductName + ProductSku
{bc12a772-9d80-519f-84fa-9917208c9986}	<- #5   Manufacturer + Family + ProductName
{9288d1c4-798b-5afc-857d-bcd23662002c}	<- #6   Manufacturer + ProductSku + BaseboardManufacturer + BaseboardProduct
{3486eccc-d0ac-534a-9e2f-a1c18bc310c6}	<- #7   Manufacturer + ProductSku
{0cb2a404-5420-5520-9fce-21a1d01f1c38}	<- #8   Manufacturer + ProductName + BaseboardManufacturer + BaseboardProduct
{d453ed82-fbf4-59ac-89de-cba11d8e445a}	<- #9   Manufacturer + ProductName
{f90f8158-9aab-58df-afe8-e26eb53f2894}	<- #10  Manufacturer + Family + BaseboardManufacturer + BaseboardProduct
{f249803d-0d95-54f3-a28f-f26c14a03f3b}	<- #11  Manufacturer + Family
{5e820764-888e-529d-a6f9-dfd12bacb160}	<- #11  Manufacturer + EnclosureKind
{f2dcffaf-8970-5899-a750-2513c09957ab}	<- #13  Manufacturer + BaseboardManufacturer + BaseboardProduct
{6de5d951-d755-576b-bd09-c5cf66b27234}	<- #14  Manufacturer
{8cfdfe7c-6e08-5126-8d0c-a6d9ee46f5de}	<- #15  Manufacturer + Family + ProductName + EDID
{ac99dd0c-1290-5e52-8af9-59dbba940efe}	<- #16  Manufacturer + Family + EDID
{b5bfdbe2-e917-57dc-8f41-aaac043a963a}	<- #17  Manufacturer + ProductSku + EDID

As for no log messages from the kernel on the Live ISO:

- I checked the Fedora kernel config in kernel-ark, and I see that the relevant QCOM Kconfigs are set to built in. CONFIG_QCOM_GENI_SE=y, CONFIG_SERIAL_QCOM_GENI=y, and CONFIG_SERIAL_QCOM_GENI_CONSOLE=y are all set as expected.

- I also tried adding earlycon to the kernel command line (in addition to clk_ignore_unused pd_ignore_unused), and still no kernel messages after grub exits.

I see your changes to the kernel.spec file in kernel-ark, and how ukify is called with the hwids. I can one evening this week rebuild the UKI with the new hwids database that includes mine above and see if that fixes the issue.

Hmm, looking at https://github.com/ubuntu/stubble/blob/main/hwids/txt/sc8280xp-lenovo-thinkpad-x13s-21bx.txt / https://github.com/ubuntu/stubble/blob/main/hwids/json/sc8280xp-lenovo-thinkpad-x13s-21bx.json

The latter lists "3486eccc-d0ac-534a-9e2f-a1c18bc310c6", which is the Manufacturer + ProductSku match and that should match on your laptop.

So I don't think the hwids are a problem here.

Lets take this one step at a time:

1. Make a backup of your current grub:

sudo cp /boot/efi/EFI/fedora/grubaa64.efi /boot/efi/EFI/fedora/grubaa64.efi.f43

2. Add a boot menu entry for the F43 grub:

sudo efibootmgr -c -d /dev/nvme0n1 -p 1 -l '\EFI\fedora\grubaa64.efi.f43' -l "Fedora 43 Grub"

3. Reboot, press F12 to show boot-menu this should now show both a "Fedora 43 grub" and a regular "Fedora" boot option, select "Fedora 43 grub" to test this.

4. Run "sudo efibootmgr | grep Fedora" to get the xxxx number of the 2 Fedora entries, run "sudo efibootmgr | grep BootOrder" to get the bootorder and finally run "sudo efibootmgr -o xxxx,xxxx,xxxx,...." swapping the 2 Fedora entries

5. Reboot press F12, check the regular Fedora is now the default again

6. Upgrade grub, run "rpm -qa | grep grub2 | sort" to get a list of all grub packages you have installed. Open https://koji.fedoraproject.org/koji/buildinfo?buildID=2925339 and download all grub2 packages you have installed into a dir. Then in that dir with all the downloaded rpms run: "sudo rpm -Uvh grub2*.rpm".

7. Reboot, hopefully things still work. If not we've found a (the?) problem, in that case reboot again, hit F12 and use the "Fedora 43 grub" entry to boot, that should still work.

8. Now that we've the new grub, lets see if there is a kernel problem, from: https://koji.fedoraproject.org/koji/buildinfo?buildID=2941457
download the aarch64 kernel-core, kernel-modules and kernel-modules-core packages into a dir. From that dir run: "sudo rpm -ivh kernel*.rpm"

9. Reboot, if things do not work, we've found a problem.

10 .Download kernel-uki-dtbloader from: https://koji.fedoraproject.org/koji/buildinfo?buildID=2941457 and in the dir with the downloaded files run: "sudo dnf swap kernel-core-6.19.2-300.fc44.aarch64 kernel-uki-dtbloader-6.19.2-300.fc44.aarch64.rpm".

11. Reboot, if things do not work, we've found a problem.

12. The last boot has used the UKI / dtbloader kernel but the /boot/loader/entries/....conf file for it should still have a devicetree line, which will cause systemd-stub to not load the devicetree. Edit /boot/loader/entries/...-6.19.2-300.fc44.aarch64.conf and comment ('#') the devicetree line.

13. Reboot.

If that all works then the f44 grub + f44 kernel + f44 auto DTB-loading all work ...

Hans: Those steps worked on my Fedora 43 install with a few extra steps. It was actually a separate problem. The x13s requires booting the kernel with arm64.nopauth, in additional to clk_ignore_unused and pd_ignore_unused.

This gets the x13s to boot at least to inside the initramfs since I see systemd messages come through. At a certain point, the display goes blank, but the panel backlight is still turned on.

I tried a few other kernel command line parameters:

- I also included regulator_ignore_unused, otherwise 30 seconds in the screen backlight is turned off.
- I disabled plymouth splash screen with plymouth.enable=0
- Older versions of Fedora we had to also boot with 'modprobe.blacklist=qcom_q6v5_pas', however that's supposedly not needed anymore according to the Fedora Wiki at https://fedoraproject.org/wiki/Thinkpad_X13s
- I also tried disabling the msm driver in the initramfs with 'modprobe.blacklist=qcom_q6v5_pas,msm' since that was also needed for older Fedora releases.

Now that I can see Linux booting, and it's pretty far into the boot, I'll see if we are far enough into the boot to see if any console messages come through via the USB serial driver. I suspect the USB and all of it's dependencies are all compiled as kernel modules, so USB won't be available until the initramfs is loaded at the earliest, or at the latest when the root filesystem is mounted and systemd starts from there.

Hans: I did some more testing on my x13s laptop. So I upgraded the relevant Fedora 43 packages to the Fedora 44 versions using the procedure that you outlined above. Automatic DTB selection is working when I upgrade my system. Linux boot is off in the BIOS, and there is no devicetree lines in my BLS configuration. When I boot the system with the Fedora 43 grub, then the Fedora 44 kernel fails to boot, which is expected because there is no DTB.

My screen goes blank (with the backlight on) when it appears to be booting in the initramfs. I know that a DTB was selected because I see that it probed regulators that are listed in the Thinkpad x13s DTB.

I am booting the system with the parameters `arm64.nopauth clk_ignore_unused pd_ignore_unused regulator_ignore_unused` and removed the parameters `quiet rhgb`.

I also added `plymouth.enabled=0 systemd.unit=multi-user.target` to boot to a text console.

On the next boot, I also tried removing the msm DRM driver, and q6v5_pas driver with `modprobe.blacklist=msm,q6v5_pas` and `rd.driver.blacklist=msm,qcom_q6v5_pas` for good measure.

For all of these, the screen still goes blank around the initramfs time with the backlight on. Do you have a suggestion for other kernel parameters that I can add to keep the screen from going blank during the boot so that I can see the kernel messages when the system hangs?

OK, I got this working. I have to boot the Thinkpad x13s with the kernel parameters: clk_ignore_unused pd_ignore_unused arm64.nopauth modprobe.blacklist=qcom_q6v5_pas quiet.

The modprobe.blacklist=qcom_q6v5_pas looks like it's needed when booting off USB. I know in the past that the USB would reset during boot up. Without this, I encountered some erofs errors on boot up.

quiet is needed because there appears to be some kind of race condition on boot up with the more verbose messages. quiet is there by default, and I kept removing it for the more verbose boot messages.

Anyways, with those changes, I'm at the graphical shell, and it prompted me to install Fedora 44. I'm going through that now.