Replacing a drive the right way (Before I make a real mess)

My system:
openSUSE Leap is installed and running on sdb which is a 1 T drive
sdb1 is the UEFI partition
sdb2 is the swap partition
sdb3 is the root partition
sdb4 is /home

I installed a 2 T NVMe drive in my machine and want to move Leap 15.3 to it.
It is shown as nvme0n1 in the device viewer.
I created a GPT table in it
I created 4 partitions that were the same sizes as sdb and tried using rsync, but the directories /dev and /sys did not come over on the nvme. I tried cp with the same results.
I am not sure how to copy the UEFI partition either.

I think I should use dd, but have some questions:
Should I start the computer using a live version and make sure that the ssd is still sdb and the nvme is still the same?
Should I remove the partitions from the nvme first?
Will dd leave the nvme with unused space when finished?
Can I resize the /home partition, using gparted, to use the extra space on the nvme?
And, most important, will

ASU-X99:~ # dd if=/dev/sdb of=/dev/nvme0n1 conv=noerror,sync

be the correct command?

Bart

Experience has shown creating a default installation on the new drive and rsyncing the data works best:

"Installing Tumbleweed first and rsyncing has some advantages.

  1. thorough testing of the drive using a pristine system with default partitioning
  2. fast update through rsync; less than one minute real time"

https://forums.opensuse.org/showthread.php/541321-Upgrading-the-Hardware?p=3086058#post3086058

As /dev and /sys are temporary file systems created at boot and maintained by the kernel during the running of the system, there is no need to copy them. It can even be harmful when you change things there.

You should use a LIVE-system to copy the existing files.

If your partitions on /dev/sdb are smaller as the ones you would like to have on nvme0n1 then using dd is not ideal: You will have to resize and shuffle partitions on nvme0n1.

I would pre-partition nvme0n1 (as you already did), boot a live system and copy (with rsync) the content from every partition on /dev/sdb to the corresponding partition on /dev/nvme0n1.

Regards

susejunky

You can “prepartition”. However it makes no sense and can cause trouble, in my opinion of course.
Go with defaults for an empty disk as follows:

**erlangen:~ #** fdisk -l /dev/nvme0n1 
**Disk /dev/nvme0n1: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors**
Disk model: Samsung SSD 970 EVO Plus 2TB             
Units: sectors of 1 * 512 = 512 bytes 
Sector size (logical/physical): 512 bytes / 512 bytes 
I/O size (minimum/optimal): 512 bytes / 512 bytes 
Disklabel type: gpt 
Disk identifier: F5B232D0-7A67-461D-8E7D-B86A5B4C6C10 

**Device        ****  Start****       End****   Sectors**** Size****Type**
/dev/nvme0n1p1    2048    1050623    1048576  512M EFI System 
/dev/nvme0n1p2 1050624 3907029134 3905978511  1.8T Linux filesystem 
**erlangen:~ #**

That’s all users need to do.

**erlangen:~ #** lsblk -f /dev/nvme0n1 
NAME        FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS 
nvme0n1                                                                             
├─nvme0n1p1 vfat   FAT32       19CF-0B54                             510.7M     0% /boot/efi 
└─nvme0n1p2 btrfs              0e58bbe5-eff7-4884-bb5d-a0aac3d8a344    1.4T    21% /var 
                                                                                   /usr/local 
                                                                                   /srv 
                                                                                   /root 
                                                                                   /opt 
                                                                                   /home 
                                                                                   /boot/grub2/x86_64-efi 
                                                                                   /boot/grub2/i386-pc 
                                                                                   /.snapshots 
                                                                                   / 
**erlangen:~ #**

Important information

Read this section carefully before continuing: Installation steps | Start-Up | openSUSE Leap 15.5

Aha! Thanks for that! I learned something!

Bart

Alright, I did all that. I made all the partitions the same size except I for /home which I used all the available space left. All the files seem to have copied over. But! The system doesn’t recognize the new (nvme) drive at boot. I was expecting to see two entries for Leap 15.3 in the grub menu. Could it be because both the nvme and sdb have the same entries? Or is it because I didn’t do an install and the bios doesn’t recognize the nvme as bootable? The nvme isn’t shown as a bootable device in the bios boot selection menu.

I looked at os=prober but although it shows the installation of Windows and arch, it doesn’t show either installations of Leap. ???

All this seems too much as I’m going to remove sdb as soon as the nvme is working.

Bart

Bart

What did you do to make you think it should?

Could it be because both the nvme and sdb have the same entries?
That’s certainly part of it. For years openSUSE fstabs have been using UUIDs for mounting. Until you adapt fstab, generate a grub.cfg for the NVME, and create a new entry in the BIOS for the new ESP’s Leap, you can’t expect anything to work right.

Or is it because I didn’t do an install and the bios doesn’t recognize the nvme as bootable? The nvme isn’t shown as a bootable device in the bios boot selection menu.
Try creating one using efibootmgr, after grub.cfg and fstab have been appropriately adjusted to the new UUIDs and device names. Here’s one I have used in the past you can use as a template:

efibootmgr -c -L "opensuse153" -l '\EFI\opensuse153\grubx64.efi'

You’ll want to follow that up by using efibootmgr to reset the boot device order to put the NVME’s ESP entry for Leap first. Or, use YaST to reconfigure these. Note that “opensuse153” here is a match to my /etc/default/grub’s GRUB_DISTRIBUTOR=, which by default is null, and causes additional openSUSE installations beyond the first to overwrite each other’s boot entries on the ESP.