Cloning Rocky 9 system drive

I’ve tried cloning my system drive (Rocky 9) to a NVME hard drive. I used dd if-/dev/old to of=/dev/new bs=4M. The dd run completed without error. But the new hard drive failed to load up the kernel.

Warning: /dev/mapper/rl-root does not exist

Warning: /dev/mapped/rl/root does not exist

Warning:/dev/rl/swap/ does not exist

I used a USB live linux and checked the new hard drive. They seems to be all exist.
Not sure what exactly wrong with the cloning procedure. Do I need to mod /etc/fstab?

You will need to boot into rescue mode and rebuild the initramfs. I would boot into a Rocky Linux 9 boot ISO and do so.

Sounds complicated. I know nothing about initramfs. no clue how to do that. Is there a cloning method that is simpier?

It’s not complicated. Read the documentation above - It explains how to regenerate the initramfs when you have the ability to do so. You simply have to go into rescue mode or into any bootable Rocky Linux 9 environment (boot or DVD iso are most common) and run the commands.

There really isn’t and this is a common pitfall. This is why you need to go into rescue mode and regenerate the initramfs yourself.

If you have a rescue mode option in your grub menu

Select the rescue option.

If it successfully boots, you should be able to login.

Login, open a terminal, become root and head to the /boot directory. Determine the latest kernel that you had installed.

In my case, the latest kernel is 5.14.0-611.20.1.el9_7. So I’ll take a backup of it.

image

Now I’ll run dracut to regenerate the initramfs. Since I identified my kernel already, the command is: dracut -f <initramfs_file> <kernel_version>

image

And that’s it. Reboot the system and verify that your system now comes up.

If you cannot get the grub menu and have an ISO

Boot the iso from a bootable media (USB for example). It can be the boot.iso, DVD, or any Rocky Linux 9 live image. I’ll use the boot.iso as an example.

Boot the iso and select troubleshooting, select rescue a rocky linux system.

It will tell you it will attempt to find your installation. Press 1 to continue. It will give you a shell once it says everything is mounted in /mnt/sysroot

chroot into your system, identify your latest kernel, back it up, and regenerate. Exit the chroot and then reboot.

% chroot /mnt/sysroot
% cd /boot
% ls
. . .
% cp initramfs-5.14.0-611.20.1.el9_7.aarch64.img initramfs-5.14.0-611.20.1.el9_7.aarch64.img.backup
% dracut -f initramfs-5.14.0-611.20.1.el9_7.aarch64.img 5.14.0-611.20.1.el9_7.aarch64
% exit
% reboot

tried going into rescue mode. I couldn’t get a prompt to do anything. I got this screen:

Failed to start D-Bus system Message Bus

See ‘systemctl status dbus-bus-broker.service’ for details

(1 of 2) A start job is running for Hold until boot process finishes up (xx / no lim)

The message went on for 3 hrs…

If it works, then it works. This is why I stated if rescue mode boots. You will need to boot a Rocky Linux 9.7 boot ISO and go to rescue mode that way.

You did remove the former drive before rebooting?
If not you have two devices with the same partition uuid’s. This won’t work.

In the contrary, the system boots up just fine with both drives in the machine. I think the system sees the partition exist and is happy with the configuration. It’s just a problem when I tried to boot into the cloned hard drive. I’ll try to boot to the ISO.

All partitions should have different UUID’s, otherwise it is going to get confused and not know from which disk to boot. Maybe one time it will boot from the original disk, maybe from the cloned one, and maybe not at all.

There are tools you can use to change the UUID’s. But if you cloned it, then the question is why are you trying to use both in the same machine? Usually you clone for a backup and keep the disk offline and unmounted.

If you want to test booting from the cloned drive, disconnect the original disk so that there are no conflicts with UUID’s.

The other problem is that the cloned system needs to be registered with the efibootmgr, for example:

efibootmgr -d /dev/sdb -p 6 -c -L Rocky9 -l '\EFI\rocky\shimx64.efi'

where -d would be something like “/dev/nvme0n1” and -p would likely be “1” and -L would be “rocky”.

lsblk would provide the correct field ID’s for -d and -p

the reason I wanted to clone my drive is to move the system to a faster nvme device. I wanted to find out about cloning on a linux system. The worst case scenario is to rebuild the system on the nvme drive from scratch.
you’re right about both original and the clone drives having identical uuid partitions. during boot if only the clone drive was attached. the system will hang after loading the base system. It error on unable to find the root partition. Of cause there is no issue on booting the original drive. the interesting thing get when both original and the clone drives are attached. the system boots up just fine. when I do lsblk the system report information on both drives. however, the system report only blkid some partitions (not all)

word about booting up on the ISO rescue mode. It says '“ You don’t have any Linux partition”

I suspect the reasons are the LVM partition installed by rocky 9.

I downloaded a thing call systemrescue live ISO. it’s able to display the lvm partition on the drive. Clearly the partitions exist. How can I make the system to recognize the partitions in the cloned drive?

You really should be using a Rocky Linux 9 ISO, such as the boot.iso. It would automatically detect and mount your system.

LVM is used default by Rocky. The troubleshoot/rescue mode of the ISO can definitely regognize normal Rocky install. Even if it fails (say due to case of filesystem corruption), it does still give a shell.

If Rocky install is spotted, then mount of its volumes is offered as convenience so that you can easily chroot “into” that system and do recovery operations “in” it. However, if you get only the shell, you can still manually mount the volumes. It just gets more involved as you have to know what to mount where before the chroot is possible.

For that you have an opportunity to practice. Connect only the original drive and boot ISO to rescue. Then in shell, rather than chroot, just check what was mounted. Memorize that. Then you can reproduce the mounts with the new drive (and chroot).

You’re right about the ISO spotting the mount volumes with the original drive. When I plug-in the cloned drive the ISO can’t see any volumes.

How does one mount the volumes on the clone drive manually?

Looking at the images in posts #14 and #17 displaying the lsblk output I can see that the original disc uses the msdos partition table and thus there is no UEFI functionality and this partition schema was cloned to the nvme device. So once the OP can actually mount the device in the chroot environment they will have to run:
grub2-install /dev/nvme0n1 or some variation. The problem with the msdos partition table is it has a disk size limitation which may be exceeded by the new device.
I would start with a fresh install of rocky on the new nvme device after first enabling the UEFI featurs in the bios so that the device gets the newer GPT partition schema and the flexibility that provides in disk management. Unfortunately the old drive would become unbootable on this system. A conundrum I’m not able to unravel for the OP.

The msdos is the usb drive. It’s how the ISO was built. The nvme and the sata drives are the clone and the original respectively. The issue here is the rescue session not seeing the clonned volume. It does know how to open (access) the boot partition.

When you connect the cloned drive, did you disconnect the original drive? You cannot have both connected at the same time - they are copies, so are identical. Only one can be connected at any one time, unless the UUID’s are changed on one of the disks. Otherwise they will conflict with each other.

So far, it’s not clear if you have done that or not?