On Wed, 5 Jun 2019 18:16:44 -0500 Roger Heflin <rogerheflin@xxxxxxxxx> wrote: > It sounds like once you get the chroot . to > work things may work right. Something odd happened with the rsync I > would suspect. You were exactly right. When I started comparing the /usr directories, I noticed discrepancies. I re-examined my options to rsync and found they were improper for cloning as they didn't handle links properly. I originally developed them for backing up home and important data. When I fixed the rsync, the clone would chroot properly. I then just booted into the rescue image from the original system, and from there I had a running system, and made it bootable. Thanks for your help. I don't think I would have solved this without it. For future searchers wanting to do this, I give a procedure below. Certainly not global, but provides a good basis. In the running system, make sure the rescue image is up to date. As root, in /boot, remove the rescue image and rescue initramfs. Then run /etc/kernel/postinst.d/51-dracut-rescue-postinst.sh 5.1.0-300.20190511.fc28.x86_64 /boot/vmlinuz-5.1.0-300.20190511.fc28.x86_64 substituting the kernel you want the rescue for. Then edit grub2/grub.cfg or run a grub2-mkconfig to pick up the new rescue image. Clone the system using rsync, rsync --delete -a -l -u -x -A -H -X /mnt/s2r1/ /mnt/s2r2 The first mount is the source and the second mount is the destination. The / on the first mount is important, as is the lack of one on the second. See man rsync. You can throw in a -v to see the files scroll by, or a --progress to get progress updates. This can take a long time, depending on disk speed. Once the system is cloned, check that it is coherent by running chroot /mnt/s2r2 It should successfully bring up a shell. exit to get out of the chroot. Edit the /etc/fstab and /boot/grub2/grub.cfg on the new system to reflect the UUIDs (or labels) of the new root, and /boot if you have separate boot. If changing to a different type of disk, msdos to gpt, also edit the hinting for the boot drive in grub terms. e.g. (hd0,msdos6) or (hd1,gpt2) Run a grub2-mkconfig in the existing system to pick up altered new grub.cfg from the newly installed system. Reboot the existing install, and from it's menu select the rescue stanza of the new install. It should successfully boot, and you can regenerate the grub.cfg so it can boot independently, and without the rescue. _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
