Cloning of existing fedora install failing at switch root. Does systemd keep system state?
Hi, I'm trying to clone an existing Fedora install, just a / partition and a /boot partition, both ext4. I use rsync, # rsync -C -x -u -a -v -A -X /mnt/old/ /mnt/new to clone both partitions from a running Fedora. I then clean up the /etc/fstab and /boot/grub2/grub.cfg by changing the UUIDs of the / and boot partitions. Formerly, that would be enough. I would run mkconfig to find the new installs from an existing Fedora, and boot into them from the grub menu of that existing install.
That failed at switch root. Research found that the initramfs is now hostonly, so will not boot on a different root. I generated a new initramfs using dracut with --no-hostonly on the existing / old install, and copied it to the new /boot. Then altered the new grub.cfg to use that as the initramfs, ran mkconfig in the existing / old install to pick up the change, and rebooted.
Still not working, though it now fails because systemd kills itself after switch root. And hangs because it can't find /bin/bash. As near as I can tell, everything is there. /usr/sbin/init links to /usr/lib/systemd/systemd, and the initramfs has those links in it, so why is switch root failing? The only thing I can come up with is that systemd somehow keeps track of the system it was installed on, and is failing to find something from the old system because it isn't mounted.
Can anyone offer any insight?
Did you check the kernel command line in grub.cfg to see what root= is set to? That is the only place I know specifically references what to look for on the switch root.
On Tue, Jun 4, 2019 at 10:41 AM stan stanl-fedorauser@vfemail.net wrote:
Hi, I'm trying to clone an existing Fedora install, just a / partition and a /boot partition, both ext4. I use rsync, # rsync -C -x -u -a -v -A -X /mnt/old/ /mnt/new to clone both partitions from a running Fedora. I then clean up the /etc/fstab and /boot/grub2/grub.cfg by changing the UUIDs of the / and boot partitions. Formerly, that would be enough. I would run mkconfig to find the new installs from an existing Fedora, and boot into them from the grub menu of that existing install.
That failed at switch root. Research found that the initramfs is now hostonly, so will not boot on a different root. I generated a new initramfs using dracut with --no-hostonly on the existing / old install, and copied it to the new /boot. Then altered the new grub.cfg to use that as the initramfs, ran mkconfig in the existing / old install to pick up the change, and rebooted.
Still not working, though it now fails because systemd kills itself after switch root. And hangs because it can't find /bin/bash. As near as I can tell, everything is there. /usr/sbin/init links to /usr/lib/systemd/systemd, and the initramfs has those links in it, so why is switch root failing? The only thing I can come up with is that systemd somehow keeps track of the system it was installed on, and is failing to find something from the old system because it isn't mounted.
Can anyone offer any insight? _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
On Tue, 4 Jun 2019 12:37:04 -0500 Roger Heflin rogerheflin@gmail.com wrote:
Did you check the kernel command line in grub.cfg to see what root= is set to? That is the only place I know specifically references what to look for on the switch root.
Yep, converted all the old UUIDs for boot and root to the new UUIDs in grub.cfg, including that one.
I tried having systemd print out to the terminal any error messages by changing the configuration in /etc/systemd/system.conf. But it didn't add anything, only saying that there were 27 printk messages not shown because of ratelimiting. Not sure what that is, but they might shed some light on the situation.
Try adding the kernel configuration boot option "printk.devkmsg=on" and reboot your computer.
-----Original Message----- From: users@lists.fedoraproject.org Sent: Tue, 4 Jun 2019 11:08:25 -0700 To: 3603060030@txt.att.net Subject: Re: Cloning of existing fedora install failing at switch root. D
On Tue, 4 Jun 2019 12:37:04 -0500 Roger Heflin rogerheflin@gmail.com wrote:
Did you check the kernel command line in grub.cfg to see what root= is set to? That is th
================================================================== This mobile text message is brought to you by AT&T
I would check these modules in dracut: dracut --list-modules, some of them are rescue and debug and a few other modules may help.
The tools may allow you to get a prompt inside the boot when it fails and/or give you some tools to do some debugging.
On Tue, Jun 4, 2019 at 1:09 PM stan via users users@lists.fedoraproject.org wrote:
On Tue, 4 Jun 2019 12:37:04 -0500 Roger Heflin rogerheflin@gmail.com wrote:
Did you check the kernel command line in grub.cfg to see what root= is set to? That is the only place I know specifically references what to look for on the switch root.
Yep, converted all the old UUIDs for boot and root to the new UUIDs in grub.cfg, including that one.
I tried having systemd print out to the terminal any error messages by changing the configuration in /etc/systemd/system.conf. But it didn't add anything, only saying that there were 27 printk messages not shown because of ratelimiting. Not sure what that is, but they might shed some light on the situation. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
On Tue, 4 Jun 2019 18:49:29 -0500 Roger Heflin rogerheflin@gmail.com wrote:
I would check these modules in dracut: dracut --list-modules, some of them are rescue and debug and a few other modules may help.
The tools may allow you to get a prompt inside the boot when it fails and/or give you some tools to do some debugging.
I'm not sure that the issue is in dracut, since it is systemd that prints the final messages. But, this is still something I will implement, just in case.
On Tue, 4 Jun 2019 19:48:58 +0000 (UTC) 3603060030@txt.att.net wrote:
Try adding the kernel configuration boot option "printk.devkmsg=on" and reboot your computer.
When I tried that, dracut went to the next item in the menu for some reason. I also tried ignore_loglevel and early_printk=ttys0 with no effect. The message implies that it is systemd doing the ratelimiting, not the kernel. Something like ... systemd: printk: [25] messages were suppressed because of ratelimiting The number of messages seems to change, but is always in the 20s.
I'll see if I can find ratelimiting in the systemd documentation. There is nothing that sounds like that in system.conf; I've turned up everything for logging I could in there to no effect. That's /etc/systemd/system.conf
Since the original system boots and runs fine, I think it must be something simple. I'll keep looking.
Once upon a time, stan via users users@lists.fedoraproject.org said:
I'm not sure that the issue is in dracut, since it is systemd that prints the final messages. But, this is still something I will implement, just in case.
Check SELinux - rsync doesn't copy that IIRC, so you may need to force a relabel. You can either touch /.autorelabel or add autorelabel=1 to the kernel boot options.
On Tue, 4 Jun 2019 20:58:48 -0500 Chris Adams linux@cmadams.net wrote:
Once upon a time, stan via users users@lists.fedoraproject.org said:
I'm not sure that the issue is in dracut, since it is systemd that prints the final messages. But, this is still something I will implement, just in case.
Check SELinux - rsync doesn't copy that IIRC, so you may need to force a relabel. You can either touch /.autorelabel or add autorelabel=1 to the kernel boot options.
I think the -A and -X options to rsync ensure this. When I look at the system (ls -nZ), all files have the SELinux context and it is correct. But this is something easy to test by trying a boot in permissive mode to avoid the time to relabel. If that succeeds, then relabel it is.
On Tue, 4 Jun 2019 20:58:48 -0500 Chris Adams linux@cmadams.net wrote:
Once upon a time, stan via users users@lists.fedoraproject.org said:
I'm not sure that the issue is in dracut, since it is systemd that prints the final messages. But, this is still something I will implement, just in case.
Check SELinux - rsync doesn't copy that IIRC, so you may need to force a relabel. You can either touch /.autorelabel or add autorelabel=1 to the kernel boot options.
No cigar. I added enforcing=0 to the kernel command line, and nothing changed in the output of the boot.
On Tue, 4 Jun 2019 18:49:29 -0500 Roger Heflin rogerheflin@gmail.com wrote:
I would check these modules in dracut: dracut --list-modules, some of them are rescue and debug and a few other modules may help.
The tools may allow you to get a prompt inside the boot when it fails and/or give you some tools to do some debugging.
I added debug to the nohostonly initrd file, and there was no change in the output during a boot. I tried using the rescue that was copied over, but it just booted the original system (successfully). I've been thinking of taking apart the rescue initrd, editing the UUIDs of the drives, and putting it back together so it would rescue the new system. Getting closer to that.
Based on not finding bash, I would think that t may not be finding your rootlv.
That generally means either the driver for the disk controller/scsi, or a critical filesystem component, or something else is missing in the required pieces to find the rootlv. You said you aren't using LVM so that simplifies some things.
If you have a serial port and a serial crossover cable and/or enough scroll back if you remove quiet you should be able to see the disk controller init and other messages so you can confirm what is or is not getting found.
Ripping apart the initrd and/or using lsinitrd to check various components to see if all the pieces are there and/or all of the settings are right in the initrd files is probably a good idea.
I have had dracut get confused and not include critical parts because of system config issues when dracut was being run, but most of those should have went away when you did hostonly=no.
On Wed, Jun 5, 2019 at 12:35 AM stan upaitag@zoho.com wrote:
On Tue, 4 Jun 2019 18:49:29 -0500 Roger Heflin rogerheflin@gmail.com wrote:
I would check these modules in dracut: dracut --list-modules, some of them are rescue and debug and a few other modules may help.
The tools may allow you to get a prompt inside the boot when it fails and/or give you some tools to do some debugging.
I added debug to the nohostonly initrd file, and there was no change in the output during a boot. I tried using the rescue that was copied over, but it just booted the original system (successfully). I've been thinking of taking apart the rescue initrd, editing the UUIDs of the drives, and putting it back together so it would rescue the new system. Getting closer to that.
On Wed, 5 Jun 2019 07:31:46 -0500 Roger Heflin rogerheflin@gmail.com wrote:
Based on not finding bash, I would think that t may not be finding your rootlv.
That generally means either the driver for the disk controller/scsi, or a critical filesystem component, or something else is missing in the required pieces to find the rootlv. You said you aren't using LVM so that simplifies some things.
I can edit the partitions when I boot from another partition.
If you have a serial port and a serial crossover cable and/or enough scroll back if you remove quiet you should be able to see the disk controller init and other messages so you can confirm what is or is not getting found.
Don't have.
Ripping apart the initrd and/or using lsinitrd to check various components to see if all the pieces are there and/or all of the settings are right in the initrd files is probably a good idea.
I have had dracut get confused and not include critical parts because of system config issues when dracut was being run, but most of those should have went away when you did hostonly=no.
I used the protocol in the man page for dracut to modify the grub.cfg in the new clone and have all kernel output during initialization sent to the terminal. It made no difference to the final output.
Here is that output, that I finally wrote down.
""" Starting Switch Root systemd-journald received SIGTERM from PID1 (systemd). systemd[1] No /sbin/init, trying fallback Failed to execute /sbin/init systemd[1] Failed to execute /bin/sh, giving up: No such file or directory systemd[1] Freezing execution """
There were 15 suppressed messages with the kernel sending to the terminal in this case.
The messages make no sense. It looks like systemd is starting, which means that it found /usr/lib/systemd/systemd on the root filesystem in order to start it. But that is just a link from /sbin/init, a link that exists on the new filesystem. And once it is started, it has no access to the filesystem that it was just started from, because it then says /sbin/init failed even though it is running. What?
Existing system:
# ls -nZ /sbin/init lrwxrwxrwx. 1 0 0 system_u:object_r:bin_t:s0 22 Feb 20 10:06 /sbin/init -> ../lib/systemd/systemd # ls -nZ /usr/lib/systemd/systemd -rwxr-xr-x. 1 0 0 system_u:object_r:init_exec_t:s0 1793800 Feb 20 10:07 /usr/lib/systemd/systemd # ls -nZ /usr/bin/sh lrwxrwxrwx. 1 0 0 system_u:object_r:bin_t:s0 4 Jun 18 2018 /usr/bin/sh -> bash # ls -nZ /bin/sh lrwxrwxrwx. 1 0 0 system_u:object_r:bin_t:s0 4 Jun 18 2018 /bin/sh -> bash
New system:
# ls -nZ /mnt/s2r4/sbin/init lrwxrwxrwx. 1 0 0 system_u:object_r:bin_t:s0 22 Feb 20 10:06 /mnt/s2r4/sbin/init -> ../lib/systemd/systemd # ls -nZ /mnt/s2r4/usr/lib/systemd/systemd -rwxr-xr-x. 1 0 0 system_u:object_r:init_exec_t:s0 1793800 Feb 20 10:07 /mnt/s2r4/usr/lib/systemd/systemd # ls -nZ /mnt/s2r4/usr/bin/sh lrwxrwxrwx. 1 0 0 system_u:object_r:bin_t:s0 4 Jun 18 2018 /mnt/s2r4/usr/bin/sh -> bash # ls -nZ /mnt/s2r4/bin/sh lrwxrwxrwx. 1 0 0 system_u:object_r:bin_t:s0 4 Jun 18 2018 /mnt/s2r4/bin/sh -> bash
Could dracut be using some internal logic to start systemd from the existing system during switch root? And then passing the wrong root UUID (the old one) to that systemd, which then fails because it isn't mounted? How would it even do that when that partition isn't mounted? Unless it is keeping an internal copy, and that copy is somehow branded with the old system root. But that would contravene the nohostonly switch.
The man page says,
""" Specifying the root Device This is the only option dracut really needs to boot from your root partition. ...
Because device node names can change, dependent on the drive ordering, you are encouraged to use the filesystem identifier (UUID) or filesystem label (LABEL) to specify your root partition:
root=UUID=19e9dda3-5a38-484d-a9b0-fa6b067d0331 """
From the grub.cfg on the new system. root=UUID=0d9def12-bc96-4323-942f-fb9f4ba325bf From the grub.cfg on the old system. root=UUID=2fc9417a-303e-43d4-91af-ba8807a58ae1
And blkid confirms these are accurate.
Aaaarrrrggggghhhhh!
Is this a bug in dracut? i.e. nohostonly isn't nohostonly.
There is a systemd started in the initrd, after the switchroot it restarts/execs init and that is the real systemd on the real disk that will run the system.
If you have quiet removed you should see the kernel say it mounted a filesystem (it won't tell you what it mounted, but it will say it mounted one). I have yet to see this sort of issue be a systemd issue, it has generally been a failure to find and mount the rootlv. The only other
Mount up the new disks on someplaces like you did and cd into the / for the new image and chroot . and then do ls -lL against the files it is complaining about, it will show you the file at the end of the lin, and this should be exactly what is seen when it is booting. If the chroot . complains about started /bin/bash, either it is missing or some libraries are not all there.
On Wed, Jun 5, 2019 at 9:52 AM stan upaitag@zoho.com wrote:
On Wed, 5 Jun 2019 07:31:46 -0500 Roger Heflin rogerheflin@gmail.com wrote:
Based on not finding bash, I would think that t may not be finding your rootlv.
That generally means either the driver for the disk controller/scsi, or a critical filesystem component, or something else is missing in the required pieces to find the rootlv. You said you aren't using LVM so that simplifies some things.
I can edit the partitions when I boot from another partition.
If you have a serial port and a serial crossover cable and/or enough scroll back if you remove quiet you should be able to see the disk controller init and other messages so you can confirm what is or is not getting found.
Don't have.
Ripping apart the initrd and/or using lsinitrd to check various components to see if all the pieces are there and/or all of the settings are right in the initrd files is probably a good idea.
I have had dracut get confused and not include critical parts because of system config issues when dracut was being run, but most of those should have went away when you did hostonly=no.
I used the protocol in the man page for dracut to modify the grub.cfg in the new clone and have all kernel output during initialization sent to the terminal. It made no difference to the final output.
Here is that output, that I finally wrote down.
""" Starting Switch Root systemd-journald received SIGTERM from PID1 (systemd). systemd[1] No /sbin/init, trying fallback Failed to execute /sbin/init systemd[1] Failed to execute /bin/sh, giving up: No such file or directory systemd[1] Freezing execution """
There were 15 suppressed messages with the kernel sending to the terminal in this case.
The messages make no sense. It looks like systemd is starting, which means that it found /usr/lib/systemd/systemd on the root filesystem in order to start it. But that is just a link from /sbin/init, a link that exists on the new filesystem. And once it is started, it has no access to the filesystem that it was just started from, because it then says /sbin/init failed even though it is running. What?
Existing system:
# ls -nZ /sbin/init lrwxrwxrwx. 1 0 0 system_u:object_r:bin_t:s0 22 Feb 20 10:06 /sbin/init -> ../lib/systemd/systemd # ls -nZ /usr/lib/systemd/systemd -rwxr-xr-x. 1 0 0 system_u:object_r:init_exec_t:s0 1793800 Feb 20 10:07 /usr/lib/systemd/systemd # ls -nZ /usr/bin/sh lrwxrwxrwx. 1 0 0 system_u:object_r:bin_t:s0 4 Jun 18 2018 /usr/bin/sh -> bash # ls -nZ /bin/sh lrwxrwxrwx. 1 0 0 system_u:object_r:bin_t:s0 4 Jun 18 2018 /bin/sh -> bash
New system:
# ls -nZ /mnt/s2r4/sbin/init lrwxrwxrwx. 1 0 0 system_u:object_r:bin_t:s0 22 Feb 20 10:06 /mnt/s2r4/sbin/init -> ../lib/systemd/systemd # ls -nZ /mnt/s2r4/usr/lib/systemd/systemd -rwxr-xr-x. 1 0 0 system_u:object_r:init_exec_t:s0 1793800 Feb 20 10:07 /mnt/s2r4/usr/lib/systemd/systemd # ls -nZ /mnt/s2r4/usr/bin/sh lrwxrwxrwx. 1 0 0 system_u:object_r:bin_t:s0 4 Jun 18 2018 /mnt/s2r4/usr/bin/sh -> bash # ls -nZ /mnt/s2r4/bin/sh lrwxrwxrwx. 1 0 0 system_u:object_r:bin_t:s0 4 Jun 18 2018 /mnt/s2r4/bin/sh -> bash
Could dracut be using some internal logic to start systemd from the existing system during switch root? And then passing the wrong root UUID (the old one) to that systemd, which then fails because it isn't mounted? How would it even do that when that partition isn't mounted? Unless it is keeping an internal copy, and that copy is somehow branded with the old system root. But that would contravene the nohostonly switch.
The man page says,
""" Specifying the root Device This is the only option dracut really needs to boot from your root partition. ...
Because device node names can change, dependent on the drive ordering, you are encouraged to use the filesystem identifier (UUID) or filesystem label (LABEL) to specify your root partition:
root=UUID=19e9dda3-5a38-484d-a9b0-fa6b067d0331"""
From the grub.cfg on the new system. root=UUID=0d9def12-bc96-4323-942f-fb9f4ba325bf From the grub.cfg on the old system. root=UUID=2fc9417a-303e-43d4-91af-ba8807a58ae1
And blkid confirms these are accurate.
Aaaarrrrggggghhhhh!
Is this a bug in dracut? i.e. nohostonly isn't nohostonly.
On Wed, 5 Jun 2019 10:14:01 -0500 Roger Heflin rogerheflin@gmail.com wrote:
There is a systemd started in the initrd, after the switchroot it restarts/execs init and that is the real systemd on the real disk that will run the system.
That's what I'm seeing then.
If you have quiet removed you should see the kernel say it mounted a filesystem (it won't tell you what it mounted, but it will say it mounted one). I have yet to see this sort of issue be a systemd issue, it has generally been a failure to find and mount the rootlv.
It shows dracut mounting, and then unmounting before switch root, several filesystems, including /boot and /sysroot. That's with the dracut kernel printing to terminal turned on.
Mount up the new disks on someplaces like you did and cd into the / for the new image and chroot . and then do ls -lL against the files it is complaining about, it will show you the file at the end of the lin, and this should be exactly what is seen when it is booting. If the chroot . complains about started /bin/bash, either it is missing or some libraries are not all there.
It is as you say. When I do a chroot to the system that won't boot, it won't because it says it can't find /bin/sh. Yet they *are* there. It is like the path hasn't been set.
I unpacked the rescue image, expecting to find something which pointed to the old system, and there was nothing obvious. If it is there, I couldn't find it. Maybe it is created during initial boot before the switch root.
Anyway, the core issue seems to be that path is not set up on the new system, so once it switches root it can't find anything even though it is there.
No path is required when the full path is supplied like that.
I would verify in the new filesystem that execute is set on everything including the directories. I would also do a ldd bash outside of the new system and check to see if all of the right libraries exist in the "new" image in the right place with the right permissions and checksums. You might try executing the "new" system /bin/bash and see if it works and/or validate it has the same checksum as the one on the working system. The switchroot should not be setting noexec on that filesysetm and outside of the various executable bits on files and directories I don't think there is a way to prevent execute of something, though there may be things besides selinux that could block it. I have seen a script say no execute when the #! executable is not set but exists, but bash should be a compiled program so that should not be an issue. Effectively the first exec of bin bash is a simple exec and should only required the executable to be there and the library and/or library path to have the needed pieces in it (/etc/ld.so.conf and /etc/ld.so.conf.d defined the library path) and should have all of the right libraries with the right checksums that the ldd says it needed. It sounds like once you get the chroot . to work things may work right. Something odd happened with the rsync I would suspect.
On Wed, Jun 5, 2019 at 4:33 PM stan upaitag@zoho.com wrote:
On Wed, 5 Jun 2019 10:14:01 -0500 Roger Heflin rogerheflin@gmail.com wrote:
There is a systemd started in the initrd, after the switchroot it restarts/execs init and that is the real systemd on the real disk that will run the system.
That's what I'm seeing then.
If you have quiet removed you should see the kernel say it mounted a filesystem (it won't tell you what it mounted, but it will say it mounted one). I have yet to see this sort of issue be a systemd issue, it has generally been a failure to find and mount the rootlv.
It shows dracut mounting, and then unmounting before switch root, several filesystems, including /boot and /sysroot. That's with the dracut kernel printing to terminal turned on.
Mount up the new disks on someplaces like you did and cd into the / for the new image and chroot . and then do ls -lL against the files it is complaining about, it will show you the file at the end of the lin, and this should be exactly what is seen when it is booting. If the chroot . complains about started /bin/bash, either it is missing or some libraries are not all there.
It is as you say. When I do a chroot to the system that won't boot, it won't because it says it can't find /bin/sh. Yet they *are* there. It is like the path hasn't been set.
I unpacked the rescue image, expecting to find something which pointed to the old system, and there was nothing obvious. If it is there, I couldn't find it. Maybe it is created during initial boot before the switch root.
Anyway, the core issue seems to be that path is not set up on the new system, so once it switches root it can't find anything even though it is there.
On Wed, 5 Jun 2019 18:16:44 -0500 Roger Heflin rogerheflin@gmail.com 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.
You are welcome.
On Thu, Jun 6, 2019 at 10:42 AM stan upaitag@zoho.com wrote:
On Wed, 5 Jun 2019 18:16:44 -0500 Roger Heflin rogerheflin@gmail.com 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.
-
3603060030＠txt.att.net -
Chris Adams -
Roger Heflin -
stan -
stan