You are not logged in.
Hey everyone,
This is my first time posting here after many weeks of trying to fix random kernel panics on my laptop. I recently installed Arch on a new laptop, everything worked perfectly, and I quickly got to setting everything up, making it a usable development station for me. It's all working fine except for one thing : sometimes my screen simply stops responding, it freezes completely, and the only thing I can do is to hold the power button to force a shutdown.
The rate at which it happens varies, but I would say at least twice per week, and more if I keep the laptop open on idle a lot. I noticed that it happened most of the time while I wasn't doing anything on it, and then came back to it some time later. The logs from journalctl show nothing unusual right before the crash. I spent a lot of time on the forums and looking online for why that might be happening, but without any logs to refer to, I wasn't feeling like trying every solution until one eventually worked. For example, I stumbled upon https://wiki.archlinux.org/title/Ryzen# … k_freezing, but looking online, I see that this is a rather old issue that doesn't seem to be happening on recent Ryzen CPUs. So I tried instead to get the logs from the crash, by setting up Kdump.
Now, my main issue is that I'm using UKI, which makes things way simpler, especially for secure boot, but it simply seems to be incompatible with Kdump. For example, I do not have the /boot/initramfs-linux.img that's required to set up Kdump, but maybe I can generate one anyway using mkinitcpio ? I am no expert on that and didn't find anything useful online.
Another thing is that I'm using LUKS2 for encrypting my disk, and that would require a lot more memory for Kdump to decrypt the disk. I did try to set it up anyway using different guides from the Arch wiki, but it either didn't work, or I encountered a problem at some point.
So my main question is the following : is it possible to set up Kdump while using UKI and an encrypted LUKS2 disk ? Or should I consider something else like netconsole ? Although I'm not sure how that would work in my case.
System info :
OS: Arch Linux x86_64
Host: Laptop 16 (AMD Ryzen 7040 Series) (AJ)
Kernel: Linux 6.12.8-arch1-1
Packages: 877 (pacman)
Shell: zsh 5.9
Display: 2560x1600 @ 165 Hz (as 1706x1066) in 16" [Built-in]
DE: KDE Plasma 6.2.5
WM: KWin (Wayland)
CPU: AMD Ryzen 9 7940HS w/ Radeon 780M Graphics (16) @ 5.26 GHz
GPU: AMD Radeon 780M [Integrated]
Memory: 9.02 GiB / 30.66 GiB (29%)
Swap: 0 B / 4.00 GiB (0%)
Disk (/): 63.16 GiB / 1.79 TiB (3%) - ext4
Locale: en_US.UTF-8
I don't think posting any logs would be helpful, all the logs I get before any freeze are irrelevant and do not point in any direction as to why it happened.
Offline
Hey Yam,
I'm very sorry to hear you are having such issues. I'm struggling right now with the same situation.
I use uki, too, signed by sbctl into a EFI bundle https://wiki.archlinux.org/title/Unifie … with_sbctl ->
sbctl bundle --save /boot/EFI/Linux/Arch.efi --splash-img /usr/share/systemd/bootctl/splash-arch.bmp --kernel-img /boot/vmlinuz-linux --initramfs /boot/initramfs-linux.img --amducode /boot/amd-ucode.img
The `/boot/initramfs-linux.img` is generated by `mkinitcpio -P`
So I have all the files necessary files for kdump. But even when I set the `crashkernel=7500M` in /etc/kernel/cmdline, and then testing the kexec, I don't have a crash kernel loaded
ExecStart=/usr/bin/kexec -p /boot/vmlinuz-linux --initrd=/boot/initramfs-linux.img --append="cryptdevice=UUID=82302b8c-9628-4fab-b728-b414ed6fe596:cLVM root=/dev/cLVM/root irqpoll nr_cpus=1 reset_devices systemd.mask=kdump.service"
My slimbook laptop also randomly freezes frequently, I can't find why. BTW, during posting this, I found that accidentally had `--intelucode /boot/intel-ucode.img` in the bundle. So, maybe this caused issues. Will see during the next days.
Offline
Hi Felixoid ! Thanks for the reply.
Sadly mkinitcpio -P does not generate the /boot/initramfs-linux.img file, it only generates the necessary .efi files, which are automatically read by systemd-boot. I signed my .efi files directly from my BIOS for secure boot, and it works just fine... Until I get a freeze and forces a shut-down, then my files get unsigned, and I have to sign them again.
I really have no idea as to what could produce these crashes and looking into alternatives to Kdump, unsuccessfully.
Offline
Maybe, you can generete it as `sudo mkinitcpio -P --no-ukify`? according to https://wiki.archlinux.org/title/Unifie … mkinitcpio
Offline
Thanks for your suggestion, I did try with --no-ukify but it didn't seem to change anything. Still no initramfs-linux.img.
Offline
I have another issue with getting `kexec` working, see the https://bbs.archlinux.org/viewtopic.php?id=302660
I'll try to replace `sbctl bundle` with ukify/mkinitcpio, since bundles are marked as deprecated in https://man.archlinux.org/man/extra/sbc … en#BUNDLES. I'll be back with the results
Offline
I made a small hardware change on a piece that seemed slightly faulty, however I still had no luck with setting up kdump. How are the results with kexec ?
Offline
I wasn't even able to boot into a crushed kernel. Maybe it's because of a strange sddm/screen issue. The keyboard has shown that it reset at the "boot" time, but the LUKS prompt didn't show up.
Offline
Still no luck on my end either. I re-did the entire process manually following https://wiki.archlinux.org/title/Kdump (I used the same kernel as my current one), I have my kdump process running, it seems to be okay, my kexec parameters should all work, I reserved 2GB just in case for the emergency kernel to be able to decrypt the disk, but it still doesn't seem to load properly even though cat /sys/kernel/kexec_crash_loaded returns 1. I'll re-try again with a different kernel, but I am really starting to lose hope on finding an actual solution to the problem.
It's also interesting to note that I've had a few "random restart" happen, like as if kdump was suddenly going to trigger before a kernel panic, but upon rebooting I see that the system did not shut down gracefully, indicating yet another kernel panic, but this time the system rebooted on its own ?
Last edited by Yam (2025-02-03 20:48:53)
Offline