Booting gets stuck if the drive is plugged in the motherboard.

I bought a new NVME ssd (1T) to replace the old Western Data NVME ssd (500G). Instead of replacing the drive in the slot and install opensuse leap 15.3 on it, I installed the OS in a virtualbox machine, which used the new drive (put in a portable nvme hardrive case connect via USB to the host machine) as the virtual machine’s hard drive, in order to prepare the new drive in advance before plugging it in the motherboard.

The installation in the virtualbox went well, and the OS got all the updates and preparation I need. Then I first tried booting the drive still in the portable nvme case connected via USB to the machine, and it boot smoothly without any problem.

But when I replace the old drive with the new drive, plugging the new drive in the motherboard slot, boot gets stuck immediately after the grub screen. I was brought to the maintenance console. There’s no useful log in “journalctl -b -p err”. And not so much either in the “/run/initramfs/rdsosreport.txt” as suggeted, in which all I could see was that after 3.9 secs into the booting sequence it got stuck.

The old drive set up has Leap 15.2, with windows installed on another drive.
The new drive has Leap 15.3 installed.

My first thoughts were about UEFI and secure boot thing. But they seem not to be the problem because the new drive (Leap 15.3) installation also enabled UEFI and they boot well when booting with UEFI and secure boot enabled in BIOS, if only plugged in via USB.

I don’t know the difference of a drive plugging in via USB and a drive plugging in on the motherboard slot.

Edit: I also tried the recovery mode and it seemed to get stuck all the same.

For the old WDC did you have any options set in grub? On my old system with a WDC WDS250G1B0C-00S6U0 I have to use;


Likewise in my setup (old intel M/B) it doesn’t support nvme boot…

What is the new nvme?

Is the efi entry updated for the nvme in the system, rather than via USB?

When you use a USB drive in a machine it sees the nvme drive as /dev/sd[a-z]

When you plug it into the motherboard slot - it becomes /dev/nvmen0 - so linux cannot find any drives it installed on.

That is your problem - I know because I did the same thing. No choice - you have to install on the motherboard for any nvme install to work.

SSD’s are /dev/sd[a-z] even on the motherboard.

I checked and did find some boot options I had added days back to solve some booting issues from the old OS. I added them all to the new drive and it did not make a difference. It’s a samsung evo drive.

No I did not make any change to the efi entry. Can you direct me on what type of change I need to make there?

:open_mouth: but true…However I have the fuzziest understanding of drive searching mechanism during boot. Don’t they use UUIDs which doesn’t change for a partition?
Are you referring to the same thing malcolmlewis mentioned about the efi entry modification?
I mean I don’t care if it can boot in a virtual machine or via usb connection anymore, if there’s some changes I can make it work to let the drive boot when plugged in on the motherboard!

When linux was installed to your nvme drive, it installed everything to /dev/sdX - the uefi boot is not UUID at this point - the grubinstall was to /dev/sdX not /dev/nvmen0 so it is looking for /dev/sdX to continue booting.

Stupid design, I agree, Linux should have keep nvme drives names /dev/sdX also.

Have you an example on which files appear to be using /dev/sdX that affect booting?

I checked in /boot/grub.cfg etc, they are not strings like “dev/sdX” but “resume=/dev/disk/by-uuid/***”.

Even if there are files using “/dev/sdX”, why can’t I change them manually to “dev/nvme*” to make it work?

Sometimes it gets stuck during boot because it is looking for a drive that was mounted
but the drive was changed and the os can’t find. Have seen this many times.
You need to manually delete it in your /etc/fstab entry.

You can run yast in init 3 to mount your new drive if permitted.

When you boot from the portable nvme case connected via USB and do

# lsinitrd | grep nvme
drwxr-xr-x   3 root     root            0 Nov 25 00:02 usr/lib/modules/5.15.6-1-default/kernel/drivers/nvme
drwxr-xr-x   2 root     root            0 Nov 25 00:02 usr/lib/modules/5.15.6-1-default/kernel/drivers/nvme/host
-rw-r--r--   1 root     root        93351 Nov 25 00:02 usr/lib/modules/5.15.6-1-default/kernel/drivers/nvme/host/nvme-core.ko.zst
-rw-r--r--   1 root     root        38091 Nov 25 00:02 usr/lib/modules/5.15.6-1-default/kernel/drivers/nvme/host/nvme.ko.zst

do you get a similar result?

If those modules are missing in your initrd you probably have to add them manually.



I went through this upon cloning from SSD to NVME. The way I remember it, I had to boot rescue media, chroot to the system installed on NVME, when rebuild the initrds with NVME support, which with the installed system running with NVME support already loaded when chroot started, will automatically get added to the new initrds - no manual setup or reconfiguration of anything required - just rebuild.

The kernel driver files for nvme are all there under /lib/…/drivers/nvme…

I seem to find the problem but don’t know how to solve it yet.

Under virtualbox “storage devices”, “controller” defaults to “SATA”, and I installed the OS just like that. I then find I can add a controller type “NVMe” (that requires also virtualbox extentions packages to be installed).

Now if I boot the virtual machine when the drive is connected via USB under the “NVMe” controller, I get exactly the same booting issue I had when plugging the drive on the motherboard PCIe slot.

I think I can get some use of chroot. May I have more details?

Chroot instructions can be found all over the internet. The basics:

  1. boot some Linux, another partition or live media or installation media
  2. login as root
  3. mount the NVME target root filesystem; e.g. to /mnt
  4. mount -o bind /dev /mnt/dev
  5. mount -o bind /sys /mnt/sys
  6. mount -o bind /proc /mnt/proc
  7. chroot /mnt
  8. mount -a
    *]run the commands needed to perform needed repairs; e.g. dracut

Working great !! Many thanks, although I have tried a few more times to fix the grub. Now I have a working drive pre-installed from inside a virtualbox.

So you just need to choose the according controller type in VB when building the machine, especially if it’s an NVMe.