Booting into kernel panic on Lenovo T14 AMD gen 3 - Ryzen 6650U

[givtrah]

I tried installing spirallinux, but I boot into a kernel panic, see attached images for both kernels.

Using spirallinux version: SpiralLinux_Plasma_11.220628_x86-64.iso

5.18.0-0.bpo.1 kernel safemode

5.10.0-15 kernel safemode

I have no idea what's going on.

[geckolinux]

Yikes, that's ugly. This is what I found by searching for "fatal exception in interrupt", also on a Lenovo laptop:
https://bbs.archlinux.org/viewtopic.php?pid=1965927#p1965927
So could you please try booting it with that additional kernel parameter rcutree.use_softirq=0 ?

[givtrah]

I successfully ran the spiral linux install on another computer earlier today.

I used Balena Etcher (windows..) to write the ISO.

I have to admit I did not check the MD5sum yet as I was just testing things... I'll do that later but as it booted on another computer it should be fine.

I'll check the candidate releases this evening and report.

Thanks for following up!

[geckolinux]

OK, thanks for the reply, assuming that it was the same USB key on both machines then we can discard that as the source of the problem.
Appreciate the additional testing!

[givtrah]

I managed to boot into the debian stable live cd and into the 5.10.0 kernel on the candidate spirallinux release.

However, in order to do so I had to delete most of the boot parameters which would cause a boot failure and then once the machine was fully booted I could switch TTY and startx as root.

Something is not right!

What do you need from me to fix this (note: This may be an upstream Debian problem in which case I have no idea how to proceed...)

[givtrah]

Final note: I got it installed, but only kernel 5.10.0 worked and with the caveat that booting didn't start SDDM, but I could switch TTY and run startx.

Kernel 5.18.x and 5.19.x both refused to boot giving me stalling at amdgpu - which after some searching around seem to be due to some firmware missing from those kernels despite the package being installed.

[geckolinux]

Really appreciate the details and additional testing. I'm sorry I can't be of more help, as it is indeed an upstream Debian issue. That was confirmed by your test with the Debian Stable live image, which you say behaves the same as SpiralLinux if I understood correctly? So in that case I imagine it's probably due to the inclusion of some firmware or driver package that gets probed in the live system and causes a kernel fault on your hardware. The Debian installer loads a much more minimal image to bootstrap the system and only installs packages that are specific to your hardware, whereas the live image contains support for all possible hardware. You could definitely try filing a Debian bug report, but it might not be handled given that the live ISO even for vanilla Debian is labelled as "unofficial". Sorry again I couldn't be of more help.