A question about moving boot disks

[aunwin2]

Hi all, this is my first post here.

Basically I've got a Red Hat server that's currently booting off a 3Par array and we want to change it to boot off a DMX (don't ask).

As I mentioned above the existing disk is on a 3Par array and the new disk on an EMC DMX.  The new LUN is presented fine and I've created multipath devices for the new disk. 

What's the recommendation for getting the boot disk copied?  The 2 options I'm considering are to basically

1/. dd the existing disk to the new one, then see if the new disk will boot via grub.

2/. use lvm to add the new disk to VG0 and pvmove to move everything which is within the existing PVs across .
I then need to work out how to deal with /boot.

Any suggestions?  If you need more deatils I can provide it.

Some useful info

Server is an HP bare blade

O/S is Red Hat (5.5)

The current /boot is off /dev/mapper/mpath0p1 the rest of the FSs are LVM all in VG00

Regds

Andy

[Matti_Kurkela · Accepted solution]

PC servers generally use BIOS to boot (except some of the newest ones use UEFI).

The bootloader uses BIOS to handle low-level disk I/O, so the kernel file and the initrd file must be stored in some way that is recognizable by the BIOS + bootloader combination.

As far as I know, there is no Linux bootloader that would support LVM natively.

The LILO bootloader stores the location of the kernel and initrd as raw disk block numbers, so it is somewhat filesystem agnostic: it does not know nor care about the partitioning scheme nor the filesystem, as long as all the blocks of the kernel and initrd are on the same physical disk. But using LILO means you must update your boot block each time you update your kernel, and any mistake while updating the boot block will most likely render your system unbootable. This is a weak point, so most modern Linux distributions prefer to use GRUB instead.

The GRUB bootloader understands traditional PC-style partitioning and VFAT/ext2/3/4 filesystems. Therefore, it can find its own configuration, kernel & initrd as regular files in a specified PC-style partition.  In a server system, GRUB is typically installed in the Master Boot Record. Thus, GRUB requires the following things in order to boot successfully:

• the BIOS must choose the right disk for booting and successfully read the Master Boot Record. With a FibreChannel disks, this choice is usually managed by the BIOS extension of the FC HBA.
• the disk must contain a traditional PC-style partition table and at least one partition
• the partition must contain at least the /boot/grub/stage2 component of GRUB itself, the GRUB configuration file, and the kernel & initrd that should be booted.

If you add the new disk as a whole-disk (/dev/sdX) to your VG00, you cannot add a partition table to the disk afterwards without overwriting the PV header. So you must _first_ partition the new disk and set up two partitions to it: one (preferably the first one) should be about 100 - 500 MB and will be used as /boot; the other should occupy all the remaining space on the disk and will be used as a LVM PV.

After that, I would create a filesystem on the new /boot partition (let's call it /dev/sdX1 or /dev/mapper/mpathN), mount it to a temporary location and copy the contents of /boot to it. Then I could unmount the old /boot and mount the new /boot in its place. This will make it easier to use the GRUB tools.

The next step would be to edit /boot/grub/device.map. Currently it will indicate that the disk that holds the old /boot filesystem is known as "(hd0)" to GRUB. When booting from the new disk, the new boot disk will be known as (hd0) instead. For GRUB to successfully anticipate that, the device.map file on the new /boot partition must be edited: it should indicate that /dev/sdX (or /dev/mapper/mpathN) will be "(hd0)".

Now it's time to prepare the system to use the new /boot.

• edit /etc/fstab to refer to the new /boot instead of the old one
• if /var is a separate filesystem, move the /var/lib/multipath/bindings file to /etc/multipath/bindings instead and add bindings_file "/etc/multipath/bindings" to the  /etc/multipath.conf if you have not already done so. See https://access.redhat.com/knowledge/node/17643 (valid RedHat subscription required)
• use mkinitrd to recreate your initrd file, so that the new multipath.conf and bindings file will be included in it
• run grub-install /dev/mapper/mpathN to install GRUB to the new disk
• change the BIOS settings of the HBA(s) and/or the SAN disk presentation to select the new disk as the boot disk (check your HBA documentation)

After all this, your system should now be able to reboot using the new /boot but the old VG00. Verify that by rebooting. Once you've successfully rebooted using the new /boot, you can migrate the rest of VG00. If the new /boot does not work, all you need to do is to restore the /etc/fstab, the HBA BIOS settings and/or the SAN presentation to what it was originally and you'll be booting from the old disk again.

[aunwin2]

That's excellent.

I've already created a partition for /boot on the new disk and another for the vg, it was just how to get the rest of it working.