Moving /boot and MBR to a new drive

Question

I have a CentOS 6 server with two hard drives in it. My old 3TB drive has been giving me some issues so I'm moving things over to a new drive. Because my / and /home partition are managed by a LVM it was easy to migrate those to the new drive. Now I want to move over my /boot partition and the MBR that makes it all start up.

I loaded up a live CD and rsynced over my /boot partition to the same size partition on my new drive. I also tried to copy over my MBR with the following commands:

dd if=/dev/sda of=mbrbackup bs=512 count=1
dd if=mbrbackup of=/dev/sdb bs=446 count=1

After doing this I rebooted, told my BIOS not to look at the old hard drive during the boot cycle and only look at the new drive but all I ended up with was a blinking cursor.

Did I miss a step here? Or is there something else I need to do to make things boot so I can completely remove my old drive?

EDIT: I'm starting to think rsync was not the way to copy the /boot partition from one drive to another. Based on this guide, I tried using the dump command instead. In this command I copied my old, unmounted boot partition to my new, empty, mounted boot partition.

dump -0f - /dev/sdaX | (cd /mnt/boot; restore -rf -) 

I'm getting a grub error 15 on boot which is better than a blinking cursor but I don't know if that is any closer to a solution.

Solution 1

If the two hard-disks are of the same size (or the new one is bigger), why didn’t you just copy the old disk to the new disk? I.e.

dd if=/dev/sda of=/dev/sdb

Now, if the new hard-disk is bigger, change the partition sizes with parted or gparted. All this done booting from a live CD/USB-stick.

Solution 2

It turns out that using rsync or dump to copy the /boot partition was causing the problem. Based on erick's answer above, I booted a live CD into rescue mode and ran the following dd commands.

dd if=/dev/sda of=mbrbackup bs=512 count=1
dd if=mbrbackup of=/dev/sdb bs=446 count=1
dd if=/dev/sda1 of=/dev/sdb1

I ran the first two dd's again just to make sure everything was copied correctly and not corrupted with all the testing I've been doing. Then I ran the third dd to copy the boot partition from my old drive to my new one. After that I shut down, pulled out my old drive and booted without issue into my CentOS.

There must have been some issue caused by using dump on a mounted drive that caused the copy to not work correctly. Regardless, dd did the trick. Thanks for your help everyone.

Solution 3

Rather than dd, I built a new volume. More steps, but might fix problems rather than copy them over. I had a too small /boot that got corrupted. I also was using cento7 with grub2. So my instructions would require some adjustments or upgrade to grub2 as psusi suggested. I tried to note the changes.

NOTE: When I use "/dev/sdx", I am assuming that your know that the "sdx" needs to be changed to whatever the name of the disk/volume that you want to be /boot.

• Use fdisk (not cfdisk) to Partition with type 83 (normal linux part), and mark as bootable.
  • Reason for fdisk: cfdisk starts the partition too soon, with no room for the boot loader. Remember, the boot loader needs to fit before the partition.
• Make file system on partition. Ext[234], xfs. others?.
• Mount at /boot
• Copy *.img files from old /boot over into /boot… at least the ones you want to keep.
• I also copied vmlinuz-* files from old /boot over into /boot… not sure if that is needed.
• Run grub2-install /dev/sdx
  • Note 1: If you are using grub (rather than grub2), I believe the correct command is grub-install /dev/sdx
  • Note 2: This installs before the partition that we just formatted, so to NOT point it at /dev/sdx1!
• Run grub2-mkconfig -o /boot/grub2/grub.cfg
  • Note: If you are using grub (rather than grub2), this is different. This might help, not sure: http://www.linuxandubuntu.com/home/how-to-change-boot-order-set-default-boot-os-in-ubuntu-14-10-15-04-linux-mint-or-other-derivatives
• Don’t forget to update /etc/fstab for /boot

references: http://www.ocztechnologyforum.com/fo...226#post373226 http://www.patriotmemory.com/forums/...ead.php?t=3696 http://thunk.org/tytso/blog/2009/02/...se-block-size/ https://ubuntuforums.org/showthread.php?t=1528529 https://wiki.centos.org/HowTos/Grub2

Solution 4

The problem is that you should not be using dd to copy the MBR like that. You simply need to reinstall grub on the new drive to get a correctly updated MBR. The MBR contains the location of the grub stage 2 file, which changed when you restored the dump.

Also you should upgrade to grub2 since grub legacy has not been maintained for years, and grub2 doesn't require a non lvm /boot partition.

View more solutions

Comments

[frostschutz]

Why not grub-install on the new drive?

[user3189506]

I am using grub2, it is what the CentOS 6 installer put on my disk. In addition, the non lvm /boot partition was also the default setup provided by CentOS. I attempted to reinstall grub2 many times on the drive but getting it to work was something that eluded me.

[ron]

using dd which is doing a bit for bit copy is an ancient way of doing a data migration especially when disk sizes are now in the terabyte range and more often than not the amount of actual data is less then 10gb on the disk; a clean fresh install of SUSE with a lot of libraries installed runs me around 5GB on the disk which I tar into one file and use an 8gb memory stick to move that tar file around, the boot parition whether it's EFI or MBR only runs a few MB.

[ron]

if you can use EFI or UEFI rather than BIOS, and have an EFI boot partition via GPT rather than a MBR & dos boot partition it makes things easy basically just format the EFI parition as fat32 and copy over those few MB of related files; otherwise for MBR you have to unsterstand how it works, correct the addresses within it with regards to the new disk, then install the new MBR on the new disk in the first sector so the BIOS can properly access it; EFI is so much better if your hardware is EFI capable

[ron]

and ELILO is better than GRUB/GRUB2, too much stuff in grub that i never make use of and just complicates things; one elilo.conf file and you're done! if it doesn't boot just that one file to look in to and correct

[ron]

this is a good example of ignorance is bliss since it worked. Ask yourself what the rescue CD did for you to correct the problem in the MBR? Having two disks in the system at the same time, which one is sda and which is sdb, and when you remove the old disk and have just the new disk, is does that change and then become sda or sdb?

[ron]

depending on what you are doing it may not matter, but it is generally better to boot by or identify disks by some unique method such as by device-id or by UUID.

[ron]

using dd and MBR is like using points and condenser on an engine rather than electronic ignition with electronic fuel injection (EFI)... pun intended... and not using EFI because it's not fully understood.