migrating complete OS to another machine

[jratliff]

We have a CentOS 7 physical host that we want to migrate to another host.

In the past, I have been able to do this by rsync'ing all the files to the new machine, fixing /etc/fstab (e.g. UUID entries), and reinstalling grub (regen grub.cfg and initramfs).

When I tried it this time, I get problems with systemd. It won't start systemd-logind anymore, and many systemctl commands fail.

If I look at the logs for dbus, it says it failed to activate service org.freedesktop.systemd1 and org.freedesktop.PolicyKit1. They timed out. If I try to restart dbus, it says "Error getting authority: Error initializing authority: Could not connect: No such file or directory (g-io-error-quark, 1)" This feels like a problem from failing to launch PolicyKit.

Suggestions on what I'm missing, or why parts of systemd won't start on the new host? The boxes aren't entirely identical, but they're really close. They're both Sandy Bridge family Xeon CPUs. There's 64 GB of RAM in the old system but only 32 GB in the new one, but it never uses much RAM, so I didn't think that would matter. The built-in network card is the same. They both have an LSI MegaRAID controller. One has an extra ethernet 4 port NIC, and the other has a qlogic fibre channel card, but neither of those things are used by the system. I even deleted all references to the network card in /etc/sysconfig/network-scripts.

Thanks.

[TrevorH]

I would suspect that rsync is not preserving your selinux contexts on all the data so everything is mislabeled. Why rsync and not a filesystem clone?

[jratliff]

I considered selinux contexts. If selinux is disabled, will they matter? I did some spot checking, and many files are missing their context, but this is similarly true on the old host with seemingly no ill effect. I tried to run a recursive restorecon -v -R /, but it didn't seem to do anything. Wasn't sure if there was another way to fix the selinux contexts.

By filesystem clone, do you mean dd? The partition sizes are not identical. The drive is slightly smaller on the new host. Let me know if there was something else you were suggesting. I used rsync -avHAX --numeric-ids for the clone.

[TrevorH]

If selinux is disabled then it won't be the problem. If it isn't then perhaps booting and appending 'selinux=0' to the kernel command line might let you boot, then set it to permissive in the config file and `touch /.autorelabel` and reboot and get it to relabel the entire filesystem.

There's nothing about your hardware that would cause the errors that you describe. In general if there's a difference in hardware then it'll either not boot at all (or only with the 'rescue' kernel) or it'll boot and bits of the hardware will be unavailable. The errors you are getting sound more like something wasn't copied correctly or copied to the wrong place or is otherwise inaccessible.

[jratliff]

I did a new and complete rsync without first syncing when the old machine was running. I also changed it from SELINUX=disabled to SELINUX=permissive. When it first booted, it forced a relabel of the filesystem even though I hadn't made the autorelabel file. After it rebooted, everything was working fine.

So I'm not sure if the original rsync didn't go properly (not sure how, but it seems reasonable) or if the relabel fixed something even though the original system seemed to have similar labeling problems.

It seems to be working now.

Thanks.

[desertcat]

I did a new and complete rsync without first syncing when the old machine was running. I also changed it from SELINUX=disabled to SELINUX=permissive. When it first booted, it forced a relabel of the filesystem even though I hadn't made the autorelabel file. After it rebooted, everything was working fine.

So I'm not sure if the original rsync didn't go properly (not sure how, but it seems reasonable) or if the relabel fixed something even though the original system seemed to have similar labeling problems.

It seems to be working now.

Thanks.

Don't forget to reactivate SELINUX=enforcing