Rsync to clone root sda3 to sdb3 can boot to backup but can't ssh-no IP

I have dual Samsung 860 512GB SSD

sda is main SSD root being on dev/sda3

sdb is the second backup SSD

I run command:

sudo mount /dev/sdb3 /mnt

run rsync command:

sudo rsync -ahPHAXx --delete --exclude={/mnt/,/media/,lost+found} / /mnt

It copies everything from sda3 to the second sdb3 root partition.

Switching boot device to the second SSD I boot and login directly with local KVM, however I cannot ssh into it from another machine because apparently the IP address on the copy is not the same supplied DHCP IP.

it didn’t display a local IP like was supposed to be 192.168.1.8

So seems there’s some network file or config that rsync is either not copying or some other issue preventing the copy to resolve ip address.

I ran /sbin/ifconfig and

it didn’t display a local IP like was supposed to be 192.168.1.8

Anyone have any ideas and experience with Clear Linux rsync’n root to root partitions?

It looks like your NIC isn’t even being detected at all, unless the screenshot is just cutoff too early. You can checkthe output of networkctl list, nmcli device, or ip link to corroborate.

Check sudo dmesg for any output that might indicate why it isn’t not being loaded.

Looks like you figured this out on GitHub. Reference: lost network interfaces on backup using rsync /dev/sda3 root to sdb3 · Issue #1183 · clearlinux/distribution · GitHub

1 Like

The below rsync command work for me.

rsync -ahPHAXx --delete --exclude={/dev/*,/proc/*,/sys/*,/tmp/*,/run/*,/mnt/*,/media/*,/lost+found} $source $target

Thanks for confirming Hong.

This may have been the result of previously creating an fstab file in /etc of sda3 (to mount sdb3 on restart) then running rsync after.

# [device-spec] [mount-point] [fs-type] [options] [dump] [pass]
/dev/sdb3 /mnt ext4 defaults 0 0

I’ve since reinstalled Clear Linux (an older version) to sdb3 with the clr-installer, destructively. The ran rsync command:

sudo rsync -axHAWXS --numeric-ids --info=progress2 --delete --exclude={/mnt/*,/media/*,/lost+found} / /mnt

to sdb3 and i’ve not seen the same issues.

I assume fstab caused some issues deeper in the system than anticipated.
I guess also that once trying to boot the second SSD sdb with a copied fstab which telling it to mount sdb3 to /mnt is the heart of the problem, perhaps as a guess it gave the kernel faulty instructions.