For the past week, I’ve been experiencing strange behavior on both my machines, a desktop and a notebook:
sometimes, but not always, whether it’s the first boot or a restart, both PCs will crash.
This can happen randomly right after the GRUB menu or while the “Tumbleweed” screen is on, on both PCs I switch off by holding the power button and then the systems will (usually) boot up correctly.
The notebook also has a blinking CAPS LOCK led while those crashes occur so at first I thought this could have been a hardware issue, I decide to install a new SSD and a fresh OS but the problem persists.
I keep both my machines up to date and the problem started at the same time on both. If this can be important in any way, they’re both AMD Ryzen.
Blinking CAPS LOCK means kernel panic (is SCROLL LOCK also blinking?). You could try booting with plymouth.enable=0 and without quiet on kernel command line, this should print panic messages on your screen. Post photo of these messages.
I attempted the “live” boot parameters but all I get is a black screen.
I’m going through all the logs as you suggested, not sure what I should be focusing on, some of the errors are in red and refer to a “systemd-coredump”, while a lot of frequent ones are in yellow, and are related to org.gnome.NautilusPreviewer and an “unsatisfied dependency: GtkSouce”… this on the brand new install that crashed “only” 3 times in two days.
I meant you should remove the boot parameters that prevent you from seeing the boot process. So, essentially what arvidjaar wrote here:
Red are usually errors and yellow warnings. Warnings can be ignored on this matter, I think. You need to know when the crash happened and check the log for the relevant time frame.
E.g. when you have a crash and reboot you should check the log for the last boot process. In this log it should be one of the last errors.
Thank you. I did what arvidjaar wrote, and now I wait, brooding over the city
I was also trying to parse old logs on the new install, to see if I could spot the problem but I don’t remember the correct times previous crashes occurred so it’s just a bit futile.
It confirms kernel panic, but it looks like all useful information scrolled away. Ideally one would connect serial console to capture full output. Netconsole may work too.
In any case, this needs kernel developer to look at. You may try to open bug report attaching available screenshot.
