9

I have a virtual box running with CentOS.

I have attached a new virtual disk to the existing CentOS VM and I'm now trying to install GRUB on this newly attached disk.

Later, I will bring up a second VM with a newly prepared bootable hard disk with a custom root filesystem and kernel.

I have tried the following steps:

  • Attached a new virtual disk to the existing working CentOS machine.
  • Created a new partition with fdisk /dev/sdb. While partitioning, I chose the options primary partition, partition number 1 and other default options.
  • Formatted the disk with mkfs.ext3 /dev/sdb1.
  • Mounted the disk to /media/new_drive.
  • Installed GRUB grub-install /dev/sdb1 --root-directory=/media/new_drive/.

After this, the second VM with the newly prepared hard disk didn't boot; I got the error: could not read from the boot medium. It seems the MBR is not updated after grub-install, but I can see GRUB installed under /boot/grub on the new drive.

But the worst thing is, it has corrupted my existing CentOS GRUB: The CentOS VM hangs showing a black screen with the only text being GRUB.

Why does grub-install /dev/sdb1 not modify the MBR of sdb1? Is this not the right way to install GRUB on new drive?

Matthias Braun
  • 8,239
Renjith
  • 241
  • 3
    /dev/sdb1 is not where the BIOS looks for MBR, it's in /dev/sdb i.e. the very first sector of the disk. – wurtel Mar 19 '15 at 13:49
  • do you mean I have to use grub-install /dev/sdb --root-directory=/media/new_drive/ instead sdb1 – Renjith Mar 19 '15 at 13:53
  • yes, that is exactly what @wurtel means – gogoud Mar 19 '15 at 13:56
  • Yes. Assuming that you've put a suitable root filesystem on that location (I don't see that step mentionen between the mounting and running grub-install). – wurtel Mar 19 '15 at 13:57
  • I will try with /dev/sdb, yeah didn't reach till putting root file system, I thought I will first try to show up grub screen. – Renjith Mar 19 '15 at 14:08
  • Thank you Wurtel and Gogoud, it worked, I am able to get grub prompt. – Renjith Mar 19 '15 at 14:31

2 Answers2

9

I'm not a grub2 expert (sorry) but try adding --skip-fs-probe to your grub-install line, I have found this prevents creation of /boot/grub/device.map which can cause booting to a grub prompt. I think that without this parameter grub-install, instead of doing what you tell it, thinks it is cleverer than you, and may do something different.

Another thing is to be sure you are using the right grub-install (i.e. for grub2 and not for original grub). This isn't a problem if you are inside Centos but with SystemRecoveryCD both versions are available and so you have to use grub2-install. I learned the hard way...

And as @wurtel pointed out (kudos), you should specify a drive not a partition. Grub2 installs in sector 0 of the whole disk drive, and this 'stub' is what runs at boot time, but it needs to know whereabouts on the disk it should install the files for the next stage of booting - this is what the --root-directory parameter is for. (I think.)

Reading man grub-install and googling I see that --root-directory is not really meant to be used for grub2 versions 1.99++, though it does work in my experience. You are meant to use --boot-directory and refer to the actual boot directory, so this would give you:

grub-install /dev/sdb --skip-fs-probe --boot-directory=/media/new_drive/boot
gogoud
  • 2,672
  • My first attempt was without partitioning and formating grub-install /dev/sdb but it gave error. Later I tried with partitioned and formatted disk, with formatted disk I was always using /dev/sdb1, I will attempt along --skip-fs-probe – Renjith Mar 19 '15 at 14:04
  • @Renjith oh and the root-directory should refer to the mounted mountpoint when you run grub-install, so you need to mount the partition on the new drive e.g. at /mnt/sys2 and then in your grub-install line specify --root-directory=/mnt/sys2. It's counter-intuitive (like a lot of grub stuff I think) but it's how it works. – gogoud Mar 19 '15 at 14:20
  • The grub right now I am using 0.97, which doesn't support --skip-fs-probe. but without that it worked. sdb1 was the mistake. – Renjith Mar 19 '15 at 14:34
  • ok glad you got it solved, that is old grub not the newer 'shiny' grub2. I didn't realise RedHat was so slow to move to grub2. CentOS 7 uses grub2 but CentOS 6 (and earlier) uses grub. – gogoud Mar 19 '15 at 14:38
6

This is how I moved a Debian installation consisting of a boot partition /boot and a root partition / to a new drive and made it bootable using GNU GRUB:

Clone partitions

  • Using the GParted live CD, create the boot and root partition on the new drive.
  • Using a root console in GParted, mount the old boot partition (let's say it's /dev/sda1) and the new partition (/dev/sdb1): mount /dev/sda1 /mnt/oldBoot && mount /dev/sdb1 /mnt/newBoot
  • Copy the data from the old boot partition to the new one: cp -afv /mnt/oldBoot /mnt/newBoot. Explanation of cp -afv:
    • a stands for "archive" which means:
      • don't dereference links
      • copy recursively (like -R)
      • preserve all attributes (timestamp, owner, permission)
    • f: force, if an existing destination file cannot be opened, remove it and try again
    • v: verbose, explain what is being done
  • This will generate some output on your console showing you which file is currently copied and whether cp makes progress
  • Mount and copy the files from your old root partition to the new one:
    • For safety: umount /mnt/oldBoot && umount /mnt/newBoot
    • Mount the old and the new root partition (assuming it's /dev/sda2 and /dev/sdb2): mount /dev/sda2 /mnt/oldRoot && mount /dev/sdb2 /mnt/newRoot
    • Copy the data of the old root partition to the new root partition: cp -afv /mnt/oldRoot /mnt/newRoot
  • Edit the filesystem table that defines which partitions are mounted on boot (I'll use Vim for that):

    • vi /etc/fstab

    • You'll notice that your old partitions are referenced here. Use the UUIDs of the new partitions instead

    • You can temporarily insert all UUIDs into fstab for easier copy and pasting with :r !blkid

    • Use the UUIDs of your new partitions to change the entries in fstab. They should look something like this:

       # <file system> <mount point> <type> <options> <dump> <pass>
 # Root partition
 UUID=76fd1ffd-fb96-4ab4-be1a-42f8e9223983 / ext4 errors=remount-ro 0 1
 # Boot partition
 UUID=e560e29e-8752-4b83-b1ee-4b86c0009f0b /boot ext2 defaults 0 2

    • Remove the output of blkid from fstab that you inserted earlier with :r !blkid

Install GRUB

  • Mount the virtual filesystems of the GParted live CD:
    mount --bind /dev /mnt/newRoot/dev
    mount --bind /proc /mnt/newRoot/proc
    mount --bind /sys /mnt/newRoot/sys
  • Make the GRUB utilities of the GParted live CD available to the root partition: mount --bind /usr/ /mnt/newRoot/usr
  • Mount the boot partition onto the root partition since GRUB will store its configuration in /boot: mount /dev/sdb1 /mnt/newRoot/boot
  • Use chroot /mnt/newRoot to make the new root partition temporarily the root of the filesystem
  • Create a GRUB config file at /boot/grub/grub.cfg using update-grub2
  • Install GRUB on the new drive: grub-install /dev/sdb. You mustn't specify a partition number here
  • Return to the filesystem of the GParted live CD: exit
  • Unmount partitions: umount /mnt/newRoot/*
  • Shutdown machine
  • If you have multiple drives attached, make sure the newer drive comes first in the boot order
  • Start machine

These instructions are inspired by those of oaktreepeak.com.

Alternatively, you can give Clonezilla a try to achieve the same.

Matthias Braun
  • 8,239