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.
I’ve recently learned that the X13s likely also needs efi=noruntime on the kernel commandline. Hopefully adding that helps.
I’ve just finished writing a set of detailed instructions for installing Fedora 44 on arm64 laptops, which includes the full list of necessary commandline instructions + also some post install instructions and explanations of all the workarounds:
Thank you for following up on this. I just tried booting F44 Beta 1.2 aarch64 with the following:
menuentry “Start Fedora-Workstation-Live” --class fedora --class gnu-linux --class gnu --class os { linux ($root)/boot/aarch64/loader/linux quiet rhgb root=live:CDLABEL=Fedora-WS-Live-44 rd.live.image clk_ignore_unused pd_ignore_unused arm64.nopauth modprobe.blacklist=qcom_q6v5_pas systemd.tpm2_wait=0 efi=noruntime initrd ($root)/boot/aarch64/loader/initrd }
The system started the boot, screen went immediately black. I left it alone for 10 minutes and then forced powered off the system.
I then tried again, removing quiet rhgb to see if I could learn more about what is going on. This time it successfully booted, not sure what was different
I’m going to see how reliably it runs from the live image before I try to install it.
Thanks for you help! I’ll post a follow-up in a day or two on how things are holding up or if I get it installed and booting.
Update, running live image, observing the following below. However, based on the instruction link provided some if not all of these things maybe addressed.
Battery status is unavailable, no change if plugged in or not
Volume buttons & mute show “Dummy Output” on screen when adjusted
Sound does not work
Night light unavailable
Bluetooth is unable to be enabled
Journal output, looks battery related
Apr 14 22:44:40 fedora udevadm[1170]: qcom-battmgr-ac: Failed to write ‘add’ to '/sys/devices/platform/pmic-glink/pmic_glink.power-supply.0/power>
Apr 14 22:44:40 fedora udevadm[1170]: qcom-battmgr-bat: Failed to write ‘add’ to '/sys/devices/platform/pmic-glink/pmic_glink.power-supply.0/powe>
Apr 14 22:44:40 fedora kernel: synth uevent: /devices/platform/pmic-glink/pmic_glink.power-supply.0/power_supply/qcom-battmgr-ac: failed to send >
Apr 14 22:44:40 fedora udevadm[1170]: qcom-battmgr-usb: Failed to write ‘add’ to '/sys/devices/platform/pmic-glink/pmic_glink.power-supply.0/powe>
Apr 14 22:44:40 fedora kernel: power_supply qcom-battmgr-ac: uevent: failed to send synthetic uevent: -11
Apr 14 22:44:40 fedora udevadm[1170]: qcom-battmgr-wls: Failed to write ‘add’ to '/sys/devices/platform/pmic-glink/pmic_glink.power-supply.0/powe>
Apr 14 22:44:40 fedora kernel: synth uevent: /devices/platform/pmic-glink/pmic_glink.power-supply.0/power_supply/qcom-battmgr-bat: failed to send>
Apr 14 22:44:40 fedora kernel: power_supply qcom-battmgr-bat: uevent: failed to send synthetic uevent: -11
Apr 14 22:44:40 fedora kernel: synth uevent: /devices/platform/pmic-glink/pmic_glink.power-supply.0/power_supply/qcom-battmgr-usb: failed to send>
Apr 14 22:44:40 fedora kernel: power_supply qcom-battmgr-usb: uevent: failed to send synthetic uevent: -11
Apr 14 22:44:40 fedora kernel: synth uevent: /devices/platform/pmic-glink/pmic_glink.power-supply.0/power_supply/qcom-battmgr-wls: failed to send>
Apr 14 22:44:40 fedora kernel: power_supply qcom-battmgr-wls: uevent: failed to send synthetic uevent: -11
Apr 14 22:44:40 fedora systemd[1]: Finished systemd-udev-trigger.service - Coldplug All udev Devices.
I’m also seeing a number of kernel oops, this is one of them.
Yes following the instructions from the new wiki page to get those added should resolve these issues.
A good question. For starters I would first update to the latest 6.19.y kernel available as Fedora package sudo dnf update "kernel*" hopefully that helps.
If you’re still seeing issues / that oops then please file a bug against the kernel component in Fedora’s bugzilla and drop me a note with the bugzilla URL. I’ll likely ask you to directly report these upstream but it is probably a good idea to first do some triaging inside Fedora’s bugzilla.
I just got around to attempting an install to the NVMe and I’m running into the following kernel messages below. These are text derived from images, aka. OCR, the text maybe incorrect.
QCOM_GPI has no DMA_PRIVATE mask bit. The other modules (such as async-tx) with FPU optimizations will break it.
This patch in lore will fix this bug. In F44, I think you can pass a kernel param modprobe.blacklist=async_tx or modprobe.blacklist=raid456 to blocking these modules temporary.
Thanks for the directions so far. With all the options suggested in this thread, I got farther through the install process Fedora 44. However, I’m getting the same hang at install screen problem as described above. I tried blacklisting both async_tx and raid456, but it didn’t work. Any help is appreciated.
