Kernel panic - not syncing: Attempted to kill init! Should I be worried?

I am running TW on a laptop which is used every day. For the last couple of days shut down has been paused for 90 seconds and there has been a significant number of lines of text on screen which I do not recognise, including the captioned “Kernel panic” line.

The problem is only on shutdown and nothing appears to be wrong when booting.

Does this mean my SSD is dying or is it something else?

Please could somebody help me diagnose the problem.

Budge

Almost impossible to say anything useful based on what you write.

Please post the shutdown part of the log using susepaste.

You can get the shutdown part of the log using “journalctl -b -1” next boot.

There was thread today on the factory mailing list about this. Seems to be a kernel issue. A fix should already be available in the Kernel:stable repo. Otherwise you could use an older kernel (5.13.*), if you keep older kernels on your system.

Hi hendwolt,
Many thanks for this info. I have meanwhile been trying to get susepaste to work but this fails.
Will wait till morning and then use another box.
Regards,
Budge.

Yes, I am seeing this on my desktop after I updated Tumbleweed today. It seems to be a kernel issue.

It looks as if file systems are properly unmounted (or at least remounted as read-only) before the kernel panic. So I don’t see it as much of a problem, apart from that 90 second delay.

I had the same behaviour on my machine as well after updating to kernel 5.14 the other day.
As this happens well after unmounting everything, no traces in the log.
The on-screen stacktrace pointed towards an issue when unloading mei_wdt, so blacklisting mei, mei_wdt and mei_me fixed the issue for me after a reboot.
Good to hear that this is already worked on…

Glad I read this thread because for whatever reason I couldn’t get susepaste to work to send the journalctl shutdown data. I then learned that what I saw was not in the logs anyhow so my efforts to get susepaste to run would have been in vain.

Returning to the subject thread, the 90 second delay is a nuisance with a laptop so I would very much like to blacklist the cited

mei, mei_wdt and mei_me

I know that zypper can do this but how exactly please?

For now, just boot the previous kernel (the 5.13 kernel) until there is a fix out.

The 5.14 kernel has been working fine for me in VMs. But I see the crash on the physical machine. Since they test updates on VMs, that’s probably why this was not noticed in the openQA testing.