You are not logged in.
After updating my linux kernel to version 6.16.8, my laptop refused to boot with the following crash pattern:
after reaching the "triggering uevents" line, the screen immediately goes to black, the capslock LED blinks (which I believe indicates a kernel panic) and eventually it shuts down or restarts.
If booting with the "nomodeset" parameter the system boots normally, which leads me to believe that this is a GPU issue.
Using nomodeset I downgraded to kernel version 6.15.9 with which the system boots normally. I have not yet searched for the exact breaking update.
The specs are as following:
Kernel: 6.15.9-arch1-1 (this boots fine)
CPU: Intel Core i5-1035G1 (8) @ 3.600GHz
GPU: Intel Iris Plus Graphics G1
I can boot everything fine on 6.15.9 but would eventually like to update my kernel, does anyone know what might be causing this? Is my GPU simply too old to be supported by newer kernel versions?
I also tried swapping to the zen kernel but there is no difference, as expected.
Offline
Hi, if you are looking for a new kernel you can consider linux-lts, it is in the official repos and is currently at version 6.12.50 which should be fine, however this is only a superficial solution, although safer than continuing to use kernel 6.15. 9 which may have vulnerabilities that were patched with versions like 6.16.x, since you mention that it used to boot normally, it could be ruled out that it is a lack of the linux-firmware package, even so your CPU does not sound to be very old for newer kernels.
Offline
Post full journalctl log from failed boot. If you use Xorg server, post also logs from it; there are 2 localizations of X server logs: /var/log/Xorg.* and/or .local/share/xorg/ . See on dates.
Offline
As far as I can tell the crash occurs before systemd even begins journalling, at least I can't find a log from the failed boot. When rebooting without nomodeset (which crashes immediately) and then rebooting with nomodeset again to view the log,
this is what the logs look like, the failed boot happens between 22:33 and 22:34. I was only able to find logs of successful boots.
Oct 03 22:33:18 mikas-laptop systemd-udevd[364]: Failed to push serialization fd to service manager: Connection refused
Oct 03 22:33:18 mikas-laptop systemd-journald[321]: Journal stopped
-- Boot 70ac3416e9864866886a7b293a248ee2 --
Oct 03 22:34:43 mikas-laptop kernel: Linux version 6.16.8-zen3-1-zen (linux-zen@archlinux) (gcc (GCC) 15.2.1 20250813, GNU ld (GNU Binutils) 2.45.0) #1 ZEN SMP PREEMPT_DYNAMIC Mon, 22 Sep 2025 22:08:18 +0000
Oct 03 22:34:43 mikas-laptop kernel: Command line: root=/dev/nvme0n1p4 rw initrd=boot\initramfs-linux-zen.img nomodeset
Oct 03 22:34:43 mikas-laptop kernel: x86/CPU: Running old microcode
Oct 03 22:34:43 mikas-laptop kernel: x86/split lock detection: #AC: crashing the kernel on kernel split_locks and warning on user-space split_locks
Oct 03 22:34:43 mikas-laptop kernel: BIOS-provided physical RAM map:
Oct 03 22:34:43 mikas-laptop kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009efff] usable
I'm on wayland so there are no xorg logs.
Offline
The journal is probably much longer than that?
Also Please use [code][/code] tags.
Wild guess: "module_blacklist=iwlwifi", https://wiki.archlinux.org/title/Kernel_parameters
Online
The journal is much longer but I just pasted the segment of the end of the first successful boot and the start of the second, because the unsuccessful boot didn't seem to be recorded at all. I'm sorry if I misunderstood, but I doubt a log of the nomodeset boot would be of much help (as that would just be a regular boot log).
Last edited by Stella (2025-10-03 22:57:52)
Offline
sudo journalctl -b -1 | curl -F 'file=@-' 0x0.st will upload the journal of the previous boot, so you can boot w/o nomodeset, reboot w/ nomodeset and post that journal from there.
The lines you've posted are completely irrelevant.
Online
This is the result of, on 6.16.8, booting 1. with nomodeset 2. without nomodeset 3. with nomodeset and journalctl -b -1
As I said, the boot crashes before it even reaches systemd so the broken boots don't get logged at all.
Last edited by Stella (2025-10-06 14:20:21)
Offline
Can you reproduce the issue with linux 6.17.arch1-1 currently in core-testing and linux 6.16.arch1-1? You can obtain 6.16.arch1-1 from the ALA if it is not in pacman's cache.
Offline
The issue persists on both of those versions, I tried 6.12.10 and it works.
I suppose I could keep binary searching for the breaking update...
Offline
I can boot everything fine on 6.15.9
The posted journal has nomodeset.
As I said, the boot crashes before it even reaches systemd so the broken boots don't get logged at all.
Remove the kms hook from mkinitcpio, make sure i915 isn't explicitly listed as module, regenerate the initramfs, reboot w/o nomodeset and do not reboot with the power button, use the https://wiki.archlinux.org/title/Keyboa … el_(SysRq) + the entire REISUB dance.
Online
I suppose I could keep binary searching for the breaking update...
The first bisection point between 5.15 and 5.16 is:
sudo pacman -U https://pkgbuild.com/\~gromit/linux-bisection-kernels/linux-mainline-v6.15.r8050.g43db111-1-x86_64.pkg.tar.zstOffline
The crash now occurs after systemd, so I was able to get this log https://0x0.st/Kuzk.txt
Offline
Did you use REISUB to reboot? As nothing from after the journal is first flushed to disk is recorded.
Offline
I didn't use REISUB the first time but I did now and it didn't seem to make a difference? Here is the log https://0x0.st/KuiQ.txt
By that I mean I used REISUB to reboot from the nomodeset boot, once the boot crashes the kernel panics and I can't reisub from there.
It did also create a truncated gibberish journal file.
Last edited by Stella (2025-10-06 16:39:54)
Offline
once the boot crashes the kernel panics and I can't reisub from there.
It did also create a truncated gibberish journal file.
Does the panic produce a QR code on the screen? If not I would suggest testing the first bisection point to bisect the issue.
Offline
It does not produce a QR code, I believe that requires the graphical interface to already be initialized. How does bisecting a linux kernel work?
Offline
Bisecting bugs with git gomit has prebuilt a number of kernels for linux bisection which you can use to avoid having to build those steps yourself you only need to test them and give me the result or you can track the bisection yourself locally.
Offline
The first bisection point between 5.15 and 5.16 is:
sudo pacman -U https://pkgbuild.com/\~gromit/linux-bisection-kernels/linux-mainline-v6.15.r8050.g43db111-1-x86_64.pkg.tar.zst
This one seems to crash.
since 6.15.9-arch1-1 boots fine but 6.16 crashes as well it seems to break on 6.16.
Offline
Initial git bisect setup:
$ git bisect start
status: waiting for both good and bad commits
$ git bisect bad v6.16
status: waiting for good commit(s), bad commit known
$ git bisect good v6.15
Bisecting: 7873 revisions left to test after this (roughly 13 steps)
[43db1111073049220381944af4a3b8a5400eda71] Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
$ git describe
v6.15-8050-g43db11110730linux-mainline-v6.15.r8050.g43db111-1-x86_64.pkg.tar.zst being bad:
$ git bisect bad
Bisecting: 4089 revisions left to test after this (roughly 12 steps)
[a61e26038143727d9b0f1bc01b0370f77f2ad7e4] Merge tag 'media/v6.16-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
$ git describe
v6.15-3960-ga61e26038143Please test
sudo pacman -U https://pkgbuild.com/\~gromit/linux-bisection-kernels/linux-mainline-v6.15.r3960.ga61e260-1-x86_64.pkg.tar.zstOffline
Please test
sudo pacman -U https://pkgbuild.com/\~gromit/linux-bisection-kernels/linux-mainline-v6.15.r3960.ga61e260-1-x86_64.pkg.tar.zst
boots successfully
Offline
$ git bisect good
Bisecting: 2195 revisions left to test after this (roughly 11 steps)
[47cf96fbe393839b125a9b694a8cfdd3f4216baa] Merge tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
$ git describe
v6.15-5854-g47cf96fbe393sudo pacman -U https://pkgbuild.com/\~gromit/linux-bisection-kernels/linux-mainline-v6.15.r5854.g47cf96f-1-x86_64.pkg.tar.zstOffline
$ git bisect good Bisecting: 2195 revisions left to test after this (roughly 11 steps) [47cf96fbe393839b125a9b694a8cfdd3f4216baa] Merge tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux $ git describe v6.15-5854-g47cf96fbe393sudo pacman -U https://pkgbuild.com/\~gromit/linux-bisection-kernels/linux-mainline-v6.15.r5854.g47cf96f-1-x86_64.pkg.tar.zst
boot crashes
Offline
This is probably too cumbersome to do on forum, I'll figure out for myself how to do this bisecting and post the results. I understand that you use git bisect, but how do you set up the linux kernel repository in the first place? Where do I cd before doing git bisect?
Offline
$ git bisect bad
Bisecting: 1032 revisions left to test after this (roughly 10 steps)
[f9fa01229339daea915c8f2a3df8d6f6a89f9b84] Merge tag 'drm-misc-next-2025-05-08' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-next
$ git describe
v6.15-rc5-861-gf9fa01229339gromit has not already built f9fa01229339daea915c8f2a3df8d6f6a89f9b84. gromit may appear and build it for you, I can build it or I can provide instructions for you to build it.
Offline