Fedora 39 initramfs can't find nvme drive

So I had an M.2 SATA drive for my main boot and root drive. This was encrypted via luks, and the root partition itself was behind an LVM. I was running fedora 39 with kernel 6.7.3-200 with nvidia drivers. This drive was rather small and was running out of space, so I got a new, much larger M.2 NVMe drive to replace it with. There is another encrypted drive, a normal SATA disc, that is also in the LVM for root.

I booted the system using a live usb for fedora 39, and from that state I cloned the M.2 SATA disc to an img file on another sata ssd in the system, using dd. Once that had finished, I replaced the M.2 SATA with the new NVMe, booted back into the live usb. It saw the new /dev/nvme0 device and I used dd to write the img file to the new M.2 NVMe drive.

Once that was finished, I used a serious of parted, cryptsetup resize, pvresize, and lvresize to resize the root partition to take up all the new free space. I checked the uuids of the partitions and they were the same.

vgscan, pvscan, lvscan all worked fine, and I was able to mount the root partition using the live usb and even chroot to it. from there I cleared out my old /lib/modules from kernels 3,4, and 5, and did a dracut --regenerate-al to rebuilt the initramfs.

I checked the kernel params in grub, as they were passing both in as params both the root partition (using the lvm name, so /dev/fedora/root) and the uuid for the luks paritions. they matched what was on the new drive (no uuid had changed after writing with dd. I assume if they did then the live usb would have had trouble mounting anything on the lvm anyhow…) Both the luks partitions (from the new nvme disc and from the sata disc that hadn’t changed) were being passed in.

I rebooted without the usb, so from the new M.2 NVMe disc, and grub worked fine and tried booting the kernel. It prompted me for the luks password for the sata disc, but complained that it could not find the device with the uuids from the new NVMe disc.

It dropped me into the dracut emergency shell. There were no nvme devices in /dev/.

Yet if I boot back into the live usb, I get my new /dev/nvme0 device, and am able to mount the whole lvm again, and even (after mount -Bing /sys, /proc and /dev) can chroot it for another dracut…

Any ideas why it cannot see the new nvme disc when I boot from it? Did I miss something in grub config ?

Welcome to Fedora @mebassett

You probably just miss the new nvme driver on the new drive, so that on dracut you can see the device.

This might point you in the right directions:

And of course a link to the Fedora Discussion:

Nothing missed in grub, but you seem to have failed in final config to run dracut and create the new updated initramfs image to provide the nvme driver for the kernel/file system image.

I suggest that you boot back to the live usb with only the new M.2 nvme drive attached and mount the installed file systems on the /mnt mount point. Then use a chroot environment and dracut to create the initramfs image supporting the nvme drive. Normally the initramfs image only provides drivers for hardware installed at the time the image was created.

There seem several ways to do so. I really suggest that you use the latest respin iso of fedora from Index of /pub/alt/live-respins since the original install media uses an older kernel (6.5.9 ?) that probably is no longer on your installed system and you may encounter a problem using dracut when booted with a kernel and supporting packages that are not currently installed in the chroot environment system.

Curiosity is getting the best of me here.

dd’ing to /dev/nvme0 is not a valid operation, the data would have to be written to a namespace (e.g. nvme0n1).

Another difficulty comes with physical block size. So dd’ing from a 512 byte block device to a 4096 byte block device would not be desirable.

Do you have the nvme-cli package installed? It supplies the nvme command.

1 Like

thank you all - you were able to set me in the write direction. I was able to fix this with a another dracut + grub-config, but I had not mounted everything before chroot - my /boot partition was never chrooted, but I fixed that the second time around.

just to be clear, I used dd of=/dev/nvme0n1 - I was writing too briefly and left out those last two final characters. however, I do not seem to be suffering from any degradation from the differing block sizes. (I did dd if=/dev/sda1 of=./disc.img and then dd if=/path/to/disk.img of=/dev/nvme0n1)

1 Like