You are welcome. On Thu, Jun 6, 2019 at 10:42 AM stan <upaitag@xxxxxxxx> wrote: > > 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
