I downloaded the Fedora 43 workstation aarch64 iso, used fedora media writer to write to a USB drive. I get the grub menu. I tried editing the safe boot option and the main option with and without `arm64.nopauth clk_ignore_unused pd_ignore_unused`, and the boot just hangs with a blank screen and a tiny little underscore in the top right corner.
I’m running the latest release bios, secure boot is turned off, and the Linux boot (Beta) is selected in the bios configuration.
As another data point I booted to Ubuntu 25.10 live image and that worked and I installed it. However, there is a number of kernel error messages during boots and it appears that after a random amount of time, while using the track stick, everything freezes and then a couple seconds later the box reboots.
I updated the firmware for the NVMe device and the touch pad using https://fwupd.org/ tooling etc.. Everything else was good. I also tried installing the latest ubuntu kernel, but the install failed and I wasn’t especially interested in digging into that. I dumped the initramfs image and see no dtb in it or anywhere on the FS. I did notice that ubuntu has the kernel command line containing `arm64.nopauth clk_ignore_unused pd_ignore_unused` .
As I really want to run fedora, I ended up removing it and at the moment I’m running Win 11 pro and WSL and fedora 43, which works surprisingly well, but not where I want to be.
I’m willing to try more things if anyone has suggestions.
Thanks!
Updates
I created an iso image based on the fedora 43 workstation ISO, and added dtb file pulled from the matching kernel. That did allow the system to start to boot, and then I think I hit a kernel panic before the screen goes black and eventually reboots itself. I also added rd.break to the kernel command line and I still had same behavior, never got to the initramfs. I also tried nomodeset too, in addition to the arguments outlined above.
Beta 44 tried, exact same behavior where I need to add dtb to get boot to start, but system panics in early boot. I need to figure out a good way to collect the kernel output during boot.
dd that to a USB stick and when booting add the following to the kernel cmdline to work around various issues: “clk_ignore_unused pd_ignore_unused arm64.nopauth modprobe.blacklist=qcom_q6v5_pas”.
You should be able to boot into the live environment and do a successful install this way. You will also need to add “arm64.nopauth” to the kernel commandline when booting the installed system, the installer should preserve the “clk_ignore_unused pd_ignore_unused” options.
There still needs to happen quite a bit of work before we can boot these laptops without needing these commandline options.
This modprobe addition is new. I tried what you suggested above and the system booted, ran for a few seconds, and then the screen went black.
I attempted to record the output with my phone, but the messages scroll so quickly that I couldn’t determine whether anything meaningful appeared before the display went completely blank.
The last line of normal looking output I see is:
[ ok ] Reached target initrd-root-device.target - Initrd Root Device
Immediately after that the text turns aqua blue and a number of lower level debug messages appear briefly before the screen goes black. I do not see any panic message, register dump, or other obvious indication that the kernel is crashing.
I’ll try again later today and set up a better arrangement to record the screen output at a higher frame rate so I have a better chance of capturing whatever appears just before the display goes blank. I will also experiment with additional kernel command line parameters to see if I can obtain more debug output.
You need to make sure you keep quiet on the kernel commandline for the boot to work (some sort of display related race condition) which seems not ideal, but is worth a try.
The modprobe.blacklist is only necessary if you’re booting of one of the Type-C USB ports. But I don’t know of the X13s has any Type-A ports? (I have a T14s with X1E SoC myself).
How long did you wait when the screen went black? There is a known issue with recent kernels where some resource necessary for the EFI firmware framebuffer gets turned off, causing the screen to go black.
The screen turns back on when the msm kernel-mode-setting driver loads, but that driver is not part of the initrd. And first the initrd hits another issue with systemd waiting for a /dev/tpmrm0 device to show up, since some EFI tables indicate there is a TPM, but there is no driver for this TPM so the initrd sits there for 45 seconds until it times out.
After that timeout the boot happily continues and the screen does light back up again. Only to try the /dev/tpmrm0 timeout a second time from the rootfs to then finally complete the boot. But the second time you can see the messages.
A workaround for these 2 45 seconds timeouts is to add "systemd.tpm2_wait=0” to your kernel commandline on top of the other kernel commandline arguments.