0

Attempted this three times now and not bee successful, so was hoping someone here could point me in the right direction?

I am trying to move my Ubuntu 14.04 Server from one physical machine, to another. I am using the following rsync command to achieve this:

rsync -aAXvP --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} root@iphere:/* /

rsync is moving the files correctly, and without rebooting I am able to run some of the services from the original server, however, upon reboot (to start the other services) I am now getting an infinite “Ubuntu loading” screen. You know the one with the dot moving to the right every second.

Originally the issue was the boot device not being found, so after rysnc, I changed the UUID to the one from my previous server. This has then led into Ubuntu not booting; so a step further. I am a little lost now however as there are no error messages, and I am unable to do anything physically with the machine as it is a VPS by Vultr.

And now thinking about it, when I do finally get things going the Networking is going to be all out of whack.

I am very new to Linux and the command line, so any help would be vastly appreciated.

It’s also worth noting that I have taken this approach because I want to keep the new server exactly as my old/current is, rebuilding the server is out of the question. I simply don’t have the time.

5
  • What do you mean by this, “…without rebooting I am able to have the server running in the same fashion as the one I copy from.” Without a reboot, how can the system be actively working as you wish? Dec 6, 2014 at 23:23
  • @JakeGould, after the rsync was complete, I was able to enable services that were running from the original server - TeamSpeak for example. I then attempted to reboot the server, to start other services... which then resulted in the problems. Sorry I wasn't super clear with that statement - I have also made an edit to the question to make that clearer
    – Jake Ball
    Dec 6, 2014 at 23:27
  • Fair enough. When you changed the UUID, I assume you followed instructions like this? Dec 6, 2014 at 23:32
  • Hey Jake, turns out the Ubuntu machine did boot - just took a long time. Rebooted again, once again - taking a very long time. I did not follow instructions like that, I simply got the UUID from the originating machine and used tune2fs /dev/vda1 -U UUID to change the UUID of the disk on the destination server. When the new server booted, I tried pinging it with no response - so I assume the network is still linked to the older IP Address? Thanks for the help!
    – Jake Ball
    Dec 6, 2014 at 23:38
  • ip addr (or the obsolete, but well loved ifconfig) would tell you that.
    – Journeyman Geek
    Dec 6, 2014 at 23:41

2 Answers 2

2

It’s not the methodology you used—and I consider this technique ‘naive’—but this has worked reliably for me. You may need to tweak things with some understanding of how Linux works of course. I’ve adapted this from an SF answer with minor tweaks

The problem with this method is that certain config files are better off not duplicated - there’s no practical reason for copying over grub’s config, or /etc/networks.

What I consider to be the right way of doing this is to use dpkg --get-selections to dump out a list of installed packages, and install them with dpkg --set-selections. Create the same users as the source system if necessary - cat /etc/passwd should list them out, and you can check with diff to see if the two lists are identical. Then use rsync to duplicate your /etc/ folder for settings(though if you use a static IP check or leave out /etc/networks), various /home/ folders for users (and check permissions here) and other folders like /var/www/.

I recommend staging /etc/ then copying config files into place especially since that's a possible point of breakage.

Test, make sure everything's there, and you're done. Takes me less time than to set up a fresh server.

There's a few 'nice' things here. You ensure that things that aren’t meant to be done manually aren’t - package management, and stuff like grub are kept consistent. It allows you to move a minimum of files - be exclusive not inclusive of what you move.

1
  • +1 for this: “The problem with this method is that certain config files are better off not duplicated…” Dec 6, 2014 at 23:55
1

Changing the UUID is a good plan. But the thing is while the system might be technically usable now, you need to make sure of a few things. All of these notes are based on my notes for server setup using Ubuntu 12.04:

Networking Adjustments: Unsure what the older setup’s networking settings were compared what they should be on Vultr, but chances are high that should be adjusted. If you can login to the machine, I would recommend running ifconfig to get a raw readout of interface data. As far as networking adjustments go, that would happen in /etc/network/interfaces which can be viewed/edited like this:

sudo nano /etc/network/interfaces

That said, if you can reach the machine, chances are that there is a DHCP setting? Regardless I would look in there to change things and if you are unsure how to do that, contact Vultr support, tell them exactly what you did and what you need to change. Pretty confident they will write back right away with a small list of networking settings you should adjust.

Update Grub: This may or may not be an issue, but you should login and run the following command:

sudo update-grub2

That will force the system to update the Grub boot loader settings. But if you notice a delay it might be a timeout on the Grub boot loader setup itself. Sometimes—and honestly it}s been hard for me to determine when or how—Grub will hang seemingly forever waiting for user interaction in selecting a boot device. If you are 100% sure you do not have to boot into anything other than the Ubuntu kernel you have in place, I would recommend adjusting the default Grub settings in this file:

sudo nano /etc/default/grub

Find this line:

GRUB_TIMEOUT=2

Now comment that out—or remove it—and then replace it with this new setting as well as an additional setting for GRUB_RECORDFAIL_TIMEOUT like this:

GRUB_TIMEOUT=0
GRUB_RECORDFAIL_TIMEOUT=$GRUB_TIMEOUT

Now run the Grub update command again:

sudo update-grub2

And see what happens on reboot. If this was this issue, reboot should be fairly quick in comparison to previous.

And past any of this you state:

It’s also worth noting that I have taken this approach because I want to keep the new server exactly as my old/current is, rebuilding the server is out of the question. I simply don’t have the time.

Well, how much time have you actually saved between migrating, being confused about settings and now hashing it out here? Is this a perceived savings of time issue that actually does not actually add up to time actually being saved?

Don’t get me wrong; I am happy to help. But in general the way I setup Linux servers—and I mainly deal in Ubuntu—is I have a very well tested formula for creating a solid base server from scratch. It now takes me about 1 hour to do this; might take longer depending on system speed and such. But once I have that solid foundation down, the configuration of applications and users becomes almost a rote afterthought.

So perceptions of time saved might have the face the unknown realities of pure clone copying like this: By installing from a clean Linux distro to start with and then building a solid foundation on top of that, you basically make all of your Linux systems more portable without the unforeseen “gotchas” of a cloning process like this.

3
  • I am going to be deploying to Vultr again, the reason for this whole process is because vultr don't allow downgrading, so they seem to make it as awkward as possible to achieve, or rather - don't give users to the tools to do it at ease. I was thinking, could I not just grab the default network/interfaces data when I first spin up the server, and copy them over?
    – Jake Ball
    Dec 6, 2014 at 23:49
  • “I was thinking, could I not just grab the default network/interfaces data when I first spin up the server, and copy them over?” Sure. Those are not deep dark secrets. When a clean server boots up again, make sure to login and copy the output of ifconfig for reference and then copy the content of /etc/network/interfaces to use when cloning again. Best of luck! Dec 6, 2014 at 23:53
  • ifconfig is supposed to be obsolete - ip addr is probably a better choice for futureproofing. I'm still trying to switch to useing ip addr, but its worth mentioning both commands.
    – Journeyman Geek
    Dec 7, 2014 at 0:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.