I cloned my old 128GB Sandisk SSD to a 1TB NVME SSD and while it does start the Fedora boot process it gets stuck at Basic Boot Target and eventually complains that not all partitions care present. I assumed it was an issue with UUID but I checked and all 4 partitions (boor, root, efi, swap) have identical UUIDs to the ones on the old drive. I can boot from the old drive even with the cloned NVME disk present but if I unplug the old SATA drive it will not finish booting. I don’t get what is causing this. Everything seems identical so why is it not booting? I must be missing something simple…
Does the drive have the boot flag? Happened to me I cloned a drive attempted boot failed added flag system knew what to do then and worked
It looks like boot flag is for MBR partitions and I use GPT so I don’t think it applies here. It also attempts to boot so at least one partition is working.
Big think I will read more
Only thing I can think of is the
fstab not using the UUID for some reason, but the identifier (
nvmeX) instead. It shouldn’t by default, but I can’t think of anything else right now.
Maybe also NVMe driver? But that should be in the kernel regardless.
I had a drive that refused to work after clone that I never got to sort what was wrong. I ended up just using DD to clone the entire drive, it booted fine, and I expanded the root partition. I’m assuming you are starting the init but failing to mount root however? I’m on Gentoo with grub2 EFI booting, so I’m not very familiar with fedora’s bootloader on EFI unfortunately.
I wonder if the efi shell calls nvm drives a different scheme to ata drives? So instead of the bootable image being on hd0,2 maybe something like nv0,2 or something? Not sure where OP got stuck. Obvs it should be looking for uuid, but OP wouldn’t be here if that was the case?
Or once loaded, the root partition might have been /dev/sda1 before, and now enumerates to /dev/nvap01 or whatever?
I think you’re on to it, Trooper_ish. On at least some versions of Grub 2, the Grub boot directory, something like (hd0,gpt1)/boot, is baked into the EFI image. I used to be able to see it with the strings utility.
dominicm you might try booting into the SSD, mounting the NVME’s root somewhere (say, /mnt/newroot), then running
grub_install --boot-directory=/mnt/newroot/boot /dev/whatever
If that doesn’t work, you could try chrooting in to the NVMe root, then run just a plain grub-install.
Those cloned UUIDs will bite hard if they haven’t already. I’d label the file systems and edit /etc/fstab to use them, f.ex.
LABEL=main / btrfs defaults,[email protected],noatime 0 1
Editing /etc/fstab is not so error-prone without the UUIDs making them unreadable.
Yeah I checked and it was using UUIDs and they matched. I did clone it with Macrium Reflect so maybe it wasn’t a perfect clone. I also used USB to NVME adapter so that may have caused the issue as well. Will try to clove via Ubuntu Live USB on the system itself and see if it works then.
Is it possible to boot a live USB, then “chroot “ into the NVMe’s drive and run update-grub or grub-update?
Never tried it myself, but maybe worth a google search? I think it is chroot like CHange ROOT kinda thing
Yeah it is, I did that many time on Arch Linux, will try that if cloning again fails.
DD didn’t work so it seem that @Trooper_Ish is on to something. Will try @jlittle suggestion next. Its also failing just before root is mounted so root must the at issue. So annoying that even cloning doesn’t work anymore…
I am getting an error when trying to run grub2-install:
grub2-install: error: /usr/lib/grub/x86_64-efi/modinfo.sh doesn't exist. Please specify --target or --directory.
Anyone know what --target or --directory should be? It’s not at all clear from the manual what value it should actually be.
It’s normally /boot or /boot/EFI. Check your /etc/fstab most likely to get that info.
As a tip, highlight the text you want to respond to, and a “Quote” will pop up. It’s a lot easier to keep track of conversation and will send notifications to people you are replying to.
Finally got it to work. From Fedora Rescue mode I regenerated initramfs and it fixed the issue.
dracut --regenerate-all -f
From emergency mode the nvme drive was not even appearing in blkid output so no surprise it would not mount with UUID or label.
So annoying that even cloning doesn’t work anymore…
Cloning isn’t necessary with Linux itself, a copy of the files will do. Boot loaders like grub need something, but it’s only a little with EFI, and /etc/fstab may need to be fixed up. (Linux needs to be told where root is, at least on the distros I’ve used, but grub-install sorts that out normally.)
Yes I understand it’s only EFI but still annoying, you would think an exact copy would work as it is identical. I wonder if UEFI just uses the drive model name and as such same drive model would work or if it uses serial number or something else unique and no drive would work without EFI update. fstab did not need to be updated as UUID was cloned.
maybe late reply, but fedora doesn’t include ‘nvme’ module inside the initrd, and cause boot issue when moving from sata ssd to nvme, in my case i add module nvme , generate initrd again, then clone entire disk again.
I did regenerate initramfs but nothing else to get it to work so not sure if that could be the issue.