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]
Message-ID: <5fa13893-c26f-110a-d3db-220fcedd0c87@inwind.it>
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ