I’m documenting this here mostly for my own purposes. This is the process I followed (eventually) to replace my aging Linux box. First with a 4TB hard drive then adding an SSD (while retaining the HD).
I won’t go into detail about the system hardware. It’s not state of the art, it’s not even recent. It’s just a huge step up from the previous box. It’s also smaller and quieter.
The first step was to clone my existing hard drive to the new 4TB drive. This was a relatively simple process as I wasn’t planning to use the old drive on the new system. So I just installed the new drive in the old system and used dd to copy one drive to the other.
Something like: dd if=/dev/sda of=/dev/sdb bs=100M status=progress
Many hours later, I had a clone of the original drive.
But when I tried to boot the new drive on the new system, I discovered another step I needed: I had to regenerate grub and initramfs.
For this I needed a bootable USB flash drive with the OS on it. I won’t go into details, that’s covered in lots of other places.
I booted the flash drive, logged in as root, and gained superuser priveleges.
Then I mounted the hard drive:
mount /dev/sda1 /mnt
Added the efi partition:
mount /dev/sda4 /mnt/boot/efi
Added some local resources:
mount –bind /dev /mnt/dev
mount –bind /proc /mnt/proc
mount –bind /sys /mnt/sys
Made /mnt my root:
grub2-mkconfig -o /boot/grub2/grub.cfg
Created initramfs (on OpenSUSe):
Rebooted and the OS ran succesfully on the new hardware.
Sometime later, I elected to add an NVMe SSD. This was going to be the boot/OS/application drive and I planned to retain the 4TB drive for /home and media storage. A 7200 RPM hard drive is plenty fast enough for streaming media and an equivalent SSD is prohitively expensive.
So once again I added the second drive to the system and booted the OS. My first discovery was that there wasn’t a /dev/sdb. After some searching and digging I found that it was showing as /dev/nvme0n1 instead. If it had been a SATA drive it would have shown as /dev/sdb, but NVMe drives have their own nomeclature.
So first I set up the drive with 2 partitions using fdisk (boot (/) and efi). Then I again used dd to copy the HD partitions to the SSD.
Because the SSD was larger than the original HD partition, I had to resize the filesystem after copying. For this I used:
Then I followed the steps above to recreate grub and initramfs.
But this time when I rebooted, it wouldn’t boot the SSD. It appeared to, but when I checked the mount points, they were all pointing to the HD.
It took a while and much searching before I finally found the answer. When I used dd to copy everything, it also gave the filesystem on the SSD partition the same UUID as the filesystem on the HD partition. This confused grub and caused it to load the HD instead.
Running lsblk -f with both drives attached, clearly showed that both filesystems had the same UUID.
This was easily solved with:
tune2fs -U random /dev/nvme0n1p1
Then I repeated the steps to update grub and initramfs and when I rebooted, it worked as expected. In fact it’s serving this blog.