On Tue, 18 Mar 2025 18:15:06 +0100 Eduard Bloch <e...@gmx.de> wrote:
Hi,
On Thu, 06 Mar 2025 11:52:57 +0100 eric <eric.vale...@free.fr> wrote:
> After updating and generating a new initramfs, it does not find the nvme
> root fs. Booting previous kernel with previous generated initramfs (0.145)
> works. Downgrading to 0.145 and rebuilding initramfs makes system work again.
>
> Main disk is nvme disk.
Hi,
I would report something similar.
With the images built with 0.145 right now I get a pointless "Cannot open route
device". And that's it, I cannot see any life signs from initrd among the long
lines, at all. That means: one of my latest initrds was updated a couple of weeks ago,
and that one is not booting. Similarly to one which I was created today with 0.145 (as
far as I can tell).
For me 145 works while 146 does not without CONFIG_MODULE_DECOMPRESS
that is unneeded to load abcd.ko.xz when system is booted.
And that all confuses me. The last working initrds which I found are build
around mid of February. And I think this was already created with 0.145. So I
unmkinitramfsed/diffed the initrd images for the same kernel built mid-February
(with the environment from back then) and one built now (with 0.146). Looks
like all the crypto-setup scripts are not present in the new version.
So this is different from me : after using booting an older kernel with
and older initramfs I downgraded to 145 version as I remembered to see
the 146 update, Thus it did a rebuild of most recent kernel initrd and
it worked when booting the same kernel that was not booting with the 146
initrd. Just to be sure I reinstalled 146 and I was stuck again in
initrd shell.
So for me, independently of other changes in various packages that may
have occurred in the mean time, with same kernel binary and package set,
145 works and 146 fails. As the difference in initrd 145 vs 146 files I
have are only compressed modules (did not make a complete md5 for all
files just checked via the name), I added CONFIG_MODULE_DECOMPRESS and I
worked again.
*But this may be a side effect* : imagine something randomly corrupts a
binary or library the initramfs in memory, the effect can be different
when having a different initramfs layout. *If* this is the root cause,
probably, in my case, it touch something that should do module
decompression and in your case something that touch crypto setup.
Now, I have no clue how to verify this hypothesis!
--
Eric Valette
