Fixing grub after MBR to GPT migration
Hey lazyplus! I am helping out upgrading a system with a couple of 2TB drives in it, CentOS 7 installed, with three partitions on each drive, with three RAID1s across those three RAID1 partitions. /, swap, and /home.
The goal is to change to 3 4TB driives. This requires changing from MBR to GPT, of course. I added one 4TB drive to the system (yay, USB3 SATA adapter) and created a GPT partition table that looks remarkably like the MBR partition table on the 2TB drives, except that the partition for the large /home filesystem is much larger, and sectors 34-2047 are used for a BIOS boot partition (EF02). Added the devices to the RAID arrays and they are all in sync.
However, now I don’t know how to convince grub to install itself so that when I connect the drive currently at /dev/sdc to a SATA cable that will make it /dev/sda, the system will boot. I understand that I’ll have to change the BIOS from Legacy to UEFI when I reboot. But I don’t know what steps to take to make the drive bootable.
Every other time I’ve dealt with drives larger than 2TB, Anaconda has been doing an install and I haven’t needed to know the details. This is my first attempt to migrate an existing system from MBR to GPT without a reinstall.
Is it feasible to do this without using rescue media?
Eugene Crosser July 31, 2015 03:31
grub-install /dev/sdX
for all new disks.
(Only the one from the actual boot disk will be used, but you want boot loader on both in case one breaks.)
Edit: grub is nice. Even if it’s completely misconfigured (e.g. disk numbers changed in BIOS, or the name of the kernel image) and cannot boot linux automatically, you can always specify the kernel and initramfs images my hand, because it knows about filesystems. And yes, it has tab completion for file names!
Michael K Johnson July 31, 2015 09:00
I guess I have old memories of grub installation to MD RAID1 not being covered correctly by grub-install in the bad old days.
grub2-install /dev/sdc
Installing for i386-pc platform.
Installation finished. No error reported.
That made me worry, because I vaguely thought that the platform was supposed to say something about “efi” when using GPT. I installed grub2-efi and grub2-efi-modules, then:
grub2-install –target=x86_64-efi /dev/sdc
Installing for x86_64-efi platform.
grub2-install: error: cannot find EFI directory.
But with that error message, I found https://wiki.gentoo.org/wiki/GRUB2#BIOS_with_GPT and I finally understand that GPT doesn’t actually require EFI, so now I can relax and not try to switch to EFI. Whew!
Thanks! Also thanks to the wonderful Gentoo folks who write so much useful documentation.
Michael K Johnson August 02, 2015 14:57
Postscript: the only problem I had was forgetting to mdadm –remove one of the partitions on one of the old drives after marking it as failed with mdadm –fail, which caused mdadm to decide that all three out of three remaining partitions making up the RAID1 for /home were spare. (Huh‽)
Of course this happened right before I had to catch my plane home, so I had some frantic googling to do before I found that I could make the /home device accessible again:
mdadm /dev/md127 –assemble –force /dev/sda3 /dev/sdb3 /dev/sdc3
For some reason it decided that one of the partitions was not up to date with the others (even though they had all been synced before) so it took another few hours while I was on the plane for the whole array to get back into sync. But I left a working computer behind me.
Whew.
Imported from Google+ — content and formatting may not be reliable