help-grub
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Looking for insight into grub issue involving SAN storage migration.


From: Phillips, Demian
Subject: Looking for insight into grub issue involving SAN storage migration.
Date: Tue, 15 Sep 2020 21:12:23 +0000

Greetings.

Red Hat says they only support fresh installs of the OS as a way to move from 
one backend Storage SAN to another. This seems strange since I have been able 
to migrate boot LUNs for numerous Unix based systems over the years.

I took a RHEL6 server that was due to be rebuilt with RHEL 7 (it had no issues, 
application updates require RHEL7 in the future) we thought we would test 
migrating it from old SAN to new SAN since we have a bunch of server clusters 
that are in production with no option to rebuild them. The server boots from 
san otherwise we would have no issue.

I've got all the data migrated including cloning the OS onto a new LUN.
I ran all the steps I could find that would migrate the boot/grub and all the 
stuff outside of systemvg.

What I am left with is it boots to a grub prompt.

If I put in all the same options and paths that I saves in the grub config and 
wrote to disk it will boot the OS just fine and everything works.

I feel like I missed some small step that is eluding me and with no support 
from the OS vendor I am reaching out to the list to see if I can resolve this 
and move the rest of the servers I need to without having to take down 
production clusters to re-load operating systems.

Here is the grub boot strings that work to bring the system up from the grub 
prompt.


root (hd0,0)

kernel /vmlinuz-2.6.32-754.28.1.el6.x86_64 ro root=/dev/mapper/systemvg-sysroot 
rd_NO_LUKS rd_LVM_LV=systemvg/sysroot rd_LVM_LV=systemvg/swap

initrd /initramfs-2.6.32-754.28.1.el6.x86_64.img


Here is how I cloned the OS disk to a LUN provided by the new SAN (devices are 
generic because I was documenting how to do it for the other migrations)


Update /etc/lvm.conf to add a filter for mpath.

Add the following "a/dev/mapper/mpath.*/", to the filter line (watch spacing) 
including the quotation marks.



sfdisk -d /dev/source_hdisk | sfdisk --force /dev/target_hdisk



pvcreate /dev/mpath_device_partition (ex /dev/mapper/mpathbp2 this was the 
partition for systemvg)



vgextend systemvg /dev/mpath_device_partition (ex /dev/mapper/mpathbp2)



pvmove /dev/source_lvm_partition (ex /dev/emcpowerca2)



vgreduce /dev/source_lvm_partition (ex /dev/emcpowerca2)



pvremove /dev/source_lvm_partition (ex /dev/emcpowerca2)


clone boot

umount /boot/

dd if=/dev/source_boot_partition (ex /dev/emcpowerca1) 
of=/dev/target_boot_partition (ex /dev/mapper/mpathbp1) bs=512 conv=noerror,sync

mount /boot



copy boot sector

dd if=/dev/source_disk (ex /dev/emcpowerca) of=/dev/target_disk (ex 
/dev/mapper/mpathb) bs=1 count=512



update grub device map (make sure this is mounting the mpath location)

vi /boot/grub/device.map

update line for the target disk to have the target disk (ex /dev/mapper/mpathb)



install grub in new disk

grub-install /dev/target_disk (ex /dev/mapper/mpathb)



sync changes

sync


This email and its attachments may contain privileged and confidential 
information and/or protected health information (PHI) intended solely for the 
use of Netsmart Technologies and the recipient(s) named above. If you are not 
the recipient, or the employee or agent responsible for delivering this message 
to the intended recipient, you are hereby notified that any review, 
dissemination, distribution, printing or copying of this email message and/or 
any attachments is strictly prohibited. If you have received this transmission 
in error, please email compliance@NTST.com immediately and permanently delete 
this email and any attachments.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]