Dear Maintainer, quite often, when booting my PC, I get a kernel panic (the computer hangs and the caps lock led blinks) at boot time, or just after it ends. I suspect this might be related with me typing my password, or moving a mouse at an unfortunate time (too early, something still initializing?), but I'm not certain that this is it. Once the system boots successfully and I log in, the kernel panic doesn't happen. For example, today, the kernel panic happened when I submitted my password to the GDM login screen. I think I also had it happen while entering my LUKS password at least once. Also, the PC actually crashed the first time I booted it after installing Trixie, causing me to delay trying Trixie out for a couple weeks. My setup is a Lenovo P15v laptop, which is connected via USB-C to a Samsung LS27A600UUU (27" ViewFinity S60UA QHD, USB-C Monitor), to which my keyboard and mouse combo are connected via USB-A port, as well as a second 27" Samsung display via the DP-OUT port. I suspect that maybe this complexity could have something to do with the freezes and be the reason why they haven't been noticed and caught until now. I don't think it's a faulty hardware issue however, because I have used Pop!_OS 22.04 for several years now (it still resides on my second SSD disk), which *never* exhibited such behavior. Cheers!
Hi, 6.12.38-1 is not the most current kernel available in trixie, pliease do update to 6.12.48-1 and let us please know if the problem persist. If yes, then we would need (ideally a full) boot log, but if nothing get recorded in logs, then the netconsole[1] approach might help [1] https://docs.kernel.org/networking/netconsole.html On UEFI system pstore alterantively might help us as well. But first upgrade your kernel to the most current one in trixie, to determine if the problem persists. Regards, Salvatore
Hi, disregard the original subject line, I actually upgraded to 6.12.48 this morning and reported the bug with that kernel already in use, as indicated in the System Information block. I'll see about the logs. I don't tend to reboot often, and when I checked with `journalctl -b-1` (and other numbers) today, I didn't see anything weird at the end of these logs: they all indicated successful logouts. I suspect they aren't being saved for some reason. I'll look at them again the next time Trixie crashes on boot. Regards, Rimas 2025-10-21 21:45, Salvatore Bonaccorso rašė:
Hi Rimas, Thanks, I have updated the metadata. Okay let's see if we can get further information on the crashes. Regards, Salvatore
Sorry for keeping this unchecked for a while. I just don't reboot very often. I think this is still happening to me with linux-image-6.12.63+deb13-amd64. Attaching three journalctl logs from sessions which at least seemed to crash. - jctl-3 felt frozen after telling me that it was installing updates, - jctl-1 became unresponsive right after it informed me that my encrypted disk had been successfully set up, and - jctl-0 became unresponsive after a mouse click in GDM login screen. In both former cases, pressing Esc did nothing to take me away from the graphical boot screen, so I killed them by long-pressing the Power button, but I forgot to first check if CapsLock was blinking. In case of jctl-0, I can confirm that CapsLock was indeed blinking, and I killed the session by long-pressing Power too. I hope these logs can help figure out what is happening. Rimas
Hi, Unfortunately this won't help really, because we do not see information from the crash in this way. We really would need to gather logs via netconsole attached, as described in https://bugs.debian.org/1118508#14 Do you have the possibility to do so, and hopefully we get a netconsole log with some crash information from kernel. Regards, Salvatore