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). With 0.146 it gets beyond this point, just to be stuck in the long "waiting for root fs" loop. The passwort query is NOT showing up. It throws me eventually to the rescue prompt, and I did a quick investigation of the kernel state. And all my block devices are there. It feels like it silently aborts the cryptosetup init sequence here. Also I am pretty sure that it's not the compressor support (all relevant CONFIG_RD_... options are y). 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 it somehow misdetects the presense of a crypto-root now? Maybe because of some subtle change in the used tools?
initramfs-crypto-breakage.diff.xz
Description: application/xz
