linux-kernel - Re: Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 25 Feb 2023 13:28:33 +0100
From:   Valerio Vanni <valerio.vanni@...ind.it>
To:     Slade Watkins <srw@...dewatkins.net>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: Kernel panic - not syncing: Attempted to kill init!
 exitcode=0x00007f00

Il 24/02/2023 19:06, Slade Watkins ha scritto:

>> https://bugzilla.kernel.org/show_bug.cgi?id=217083
>>
>> I got this error after upgrading a Debian machine (x86-64) from Stretch
>> to Buster. Upgrade is successful, but the next boot it crashes.
> 
> Thanks for the details. What was the last known good kernel version
> that did not exhibit this issue on your system?

There isn't a last known good version. As I said, the issue appeared 
after an OS upgrade, not after a kernel one.
4.20.17 on Stretch was [1] working. After upgrade to Buster, kernel 
panic came out and I decided to try with other kernel versions.

>> The machine is an Asus B360M-A with an Intel i7-8700 CPU and 16GB DDR4.
>> My kernel is 4.20.17 (from kernel.org, not a distribution kernel), but I
>> tried with 4.19.273 and 5.10.169 with the same .config.
> 
> Also just a quick note, since I noticed you mention it here: 4.20.y is
> not supported (see kernel.org for a list of supported releases).
> 4.19.y and 5.10.y, however, are.

I know, it's the reason why I downloaded and tried 4.19.273 and 5.10.169 
before opening the bug report. I wanted to report on a supported version.
Yesterday I tried also 6.2, with the same result.

[1] And *is* working in the original place. I always test OS upgrades on 
a cloned drive. I can restore from image the screwed copy, retry upgrade 
etc. Also dangerous things.