I recently purchased a new computer. My old computer had Fedora 31 installed on an M.SATA drive. My new computer did not have an M.SATA slot. I could have added one via a PCIe card, but decided against it.
I've been using Linux since RH8 days as my sole workstation. I've migrated OSes from hard drive to hard drive many times. In the old days I'd do a fresh install and then copy /home and try to reinstall all the apps I had installed. It was a big PITA.
Even updates used to be problematic in the early days of Fedora... ;)
I hate migrating to a new computer. It can take a long time to get everything set up just the way you want it. I've done migrations with dd before, but there are always little issues with getting the new drive to boot properly, copying directories that shouldn't be, etc. It works, but it takes a bit of tweaking to make it work.
Today I had my best OS migration ever. It appears that everything came across to the new drive perfectly, with just about zero hassle. In fact, tonight I am forgetting that I'm operating on a new machine, except it is twice as fast... :)
Here is how I did the migration:
Step #1 Create a Live USB of the same version as the old (source) machine.
Step #2 Boot the Live USB on the new (target) machine and install Fedora.
Step #3 Boot the newly installed OS on the target machine and run dnf update. If you install a user, make it different from any on the source machine.
Step #4 Run dnf update on the old (source) machine.
Both machines should now have the same OS vintage. You can double check this by making sure both are running the same kernel.
Step #5 cp /etc/fstab on the target machine to somewhere safe, just in case.
Step #6 Reboot the target machine with the Live USB.
Step #7 The target machine is now running the LiveUSB OS. Find the drive partitions for swap, root (/), boot (/boot) and home (/home) for the new drive on the new machine. Nautilus displays them as "Other locations..." or something like that. They probably won't be mounted.
You'll need device handles for each partition on the new drive so that they can be mounted. Ie /dev/sda1, etc.
The new OS drive on my new machine was an M.2 NVMe drive. It was formatted into 4 partitions /dev/dm-0 (swap), /dev/dm-1 (home), /dev/dm-2 (root) and /dev/dm-3 (boot) by the live install process.
Step #8 create a mount point and mount the root partition on the new machine
#cd /mnt
#mkdir drive
# mount /dev/<root partition device>... drive
Step #9 mount the home partition to drive/home so that it looks like it does on a regular Linux system.
#cd /mnt/drive
mount /dev/<home partition> home
At this point /mnt/drive should look like the root of a regular Linux system, ie home, usr, bin, var... etc. The home partition on the new drive will be mounted to /mnt/drive/home. You should cd into it just to make sure.
DO NOT MOUNT THE ROOT PARTITION !
Step #9 use rsync to copy all the relevant files from the source computer to the mounted directory structure.
From /mnt/drive, issue the following command:
sudo rsync -aHxv --numeric-ids --progress root@<sourceComputerIP>:/* /mnt/drive --exclude=/dev --exclude=/proc --exclude=/sys --exclude=/tmp --exclude=/boot --exclude=/etc/fstab
This command will copy all the relevant files from the source machine to the directory structure we just made on the target hard drive.
Depending on how much you have installed on the source computer, this will take a while. Make sure that both the network interfaces are operating as fast as they can.
I saw file transfer speeds of 100 MB/sec for large files on 2 machines networked with 1000 Mb/sec NICs. Small files don't reach that speed. The CPU usage on the source machine ran at 25-30% on a quad core i7.
BTW, the source machine must be set up to allow root logins to ssh for this to work. The commands on the source machine to enable this are:
#nano /etc/ssh/sshd_config
Find the commented like for PermitRoot and set it to: PermitRootLogin yes#systemctl restart sshd.service
If you forget to run rsync from /mnt/drive and do it from / or specify the target directory as /, you'll install the files on the Live USB file structure instead of the target drive, thus messing it up ! No biggie, just rebuild the Live USB and do this step over.
Step #10 Verify that /mnt/drive/etc/fstab is still in tact and the same as what it was prior to the rsync operation. If not, replace /mnt/drive/etc/fstab with the fstab file that was set aside. Do not copy the backup fstab file to /etc/fstab as that points to the Live USB OS ! It must be copied to /mnt/drive/etc/fstab.
(It took me several times to complete my clone drive because I kept forgetting that the root of my target fs was /mnt/drive and thus I messed up my Live USB drive a couple times.)
Step #11. Reboot the target computer using the new drive OS. We didn't touch the /boot partition, so it should boot right up. However, the drive partitions got written to outside of the OS, so they will be checked. This can take a bit of time. Press ESC to watch this go on.
Once the boot process is complete, SELinux won't be happy and some of the partitions will probably mount as read only.
To fix this problem, open a console session and issue the following statement and reboot the computer.
#fixfiles onboot
#shutdown -r now
When the target computer reboots, a message will appear:
"Warning - SELinux targeted policy relabel is required....
It will start relabelling things. When it is done you should have an exact clone of the install you had on the source computer.
The only potential issue I know of with this method is that the grub kernel list doesn't match the kernels installed. Thus if you look in /boot there will only be the kernels that were installed during the live install process. But if you use dnf list kernel, you'll see the kernels that were installed on the source machine. If this bothers you, use dnf to uninstall and reinstall the kernels you want. Reinstalling the kernels will enter them into grub properly. This problem will also take care of itself over time as new kernels are installed via dnf update.
The only thing that didn't work exactly as it did on my source computer was Eclipse and I"m not sure that had anything to do with the cloning.
I hope this helps someone.
_______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
