I have a ThinkPad-T14-Gen-3-AMD running Debian Trixie. It has a recurring problem with what I believe to be a kernel panic (capslock is blinking moderately fast) on wake-from-sleep. This happened once last night; I rebooted once after it.

I want to get this inserted into the Debian bug tracking system such that either a bug is filed, or I know which known bug it corresponds to. How would I go about this? Would my computer have a log of last night's panic? Can I make it start collecting them?

@mcc blinking caps lock is a kernel panic. You can look at the end of the log of the last boot with `journalctl -e --boot=-1`

@mcc what you can check is the log from the last boot, using "journalctl -b -1"

@mcc I think there is some fancy EFI thing now where panics are logged into the EFI storage and then dumped to the journal on next boot. Certainly look in journalctl and see how much is there for the time in question.

@mcc You can run `journalctl --list-boots` (as root or via sudo) to get a list of available logs separated on any reboot. Note the "BOOT ID" column for what looks like the interesting boot. Then run `journalctl --boot <BOOT ID>` to get the logs for that particular boot (again as root or via sudo).

You can look at that for any relevant messages. There may be some messages missing around the panic though, depending on whether the kernel was still able to write to the filesystem or not.

@mcc lookup Magic SysReq keys, you want the keysequence to force flush all file buffers to you'll have complete logfiles for any log messages.

@mcc if it's not in the journal, or not clear cut panic -- when i was looking into my nuc's wake-from-sleep issues this guide was helpful (re logging etc) https://web.archive.org/web/20230502010825/https://01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/hibernate-issues (although i had to give up because the pain was too huge lol)

@hyc I don't think I have a SysRq button

@4censord @elomatreb would you expect -b -2 to work if i want two boots back?

@mcc @4censord yes, boot #0 is the current boot and negative indices go backwards from there

@mcc @elomatreb yes, unless you dont keep logs around long enough (no idea what the defaults are on debian)

@mcc testing or unstable?

@spv Trixie. So, unstable.

@mcc i thought testing was trixie too now? hmm

@spv If that's true then I don't understand how debian branch naming works.

@mcc

The Debian community forums would love to see your bug. Good luck, however you search.

#debian #kernel #ReturnFromSleep #linux

@kbm0 These boot logs are like 3000 lines long each… what string should I be looking for? The word "panic"?

@mcc maybe not as an unshifted key, no. http://unix.stackexchange.com/questions/225929/ddg#225982 you can assign it to a key.

@mcc `apt show dpkg | grep -i sources | cut -d' ' -f3 | cut -d'/' -f1` should tell you

@spv it says "trixie"

@kevinrns I've been asking the irc channel for the last day or so without much luck. do you mean https://forums.debian.net/ ?

@mcc do you have a /etc/apt/sources.list, or sources.list.d/*.sources?

if the latter, check suites: i'm on unstable, so that's what it says

i think you're on testing -- iirc that's what `trixie` is atm

@mcc

I use a different distro. So I haven't used theirs. Reddit has linux discussions.

@mcc The mechanism I was rambling about is called pstore.
https://mjg59.dreamwidth.org/23554.html
There is a systemd service which can clear the crashdumps so they may be in the journal or in /var/lib/systemd/pstore. https://manpages.debian.org/testing/systemd/systemd-pstore.service.8.en.html
Sorry this is vague, I only ever saw one of these once and it was 3 years ago, caused by an outdated amdgpu driver.

@spv yes. /etc/apt/sources.list says i am on trixie. that is an option. you don't have to say stable/unstable/testing you can give a specific release. according to the debian oftc irc, now that we are in freeze trixie will have slightly older/more stable packages than unstable.

@mcc ye, trixie should be equivalent to testing i think

@mcc often upstream was more useful for deep technical issues. I used to hunt these on Debian. Upstream used to want to have people do things like use a vanilla kernel and bisect to find the problematic patch (presuming there was a working point). I’ve long since forgotten how to package a vanilla kernel, but I remember there were multiple ways to run one.

@drewdaniels That sounds hard :(

@mcc there are instructions and pre-packaged vanilla kernels now. Maybe there are better reporting processes now.