This was tested on a RedHat 5.4
Boot the machine with installation CD into rescue mode
boot: linux rescue
at the request of mounting the existing installation, choose skip
Activate the volume group with
#lvm pvscan
#lvm vgscan
Now you can rename the volume group
#lvm vgrename VolGroup00 VolGroup99
Now you must change all the references to VolGroup00 on the filesytem to the new volume group name.
Activate the new volume group
#lvm vgchange -ay VolGroup99
Mount the root and the boot filesystems
#mkdir -p /mnt/sysimage
#mount /dev/VolGroup99/LogVol00 /mnt/sysimage
Mount the boot filesystems (note that the device name may vary according to your actual boot device)
#mount /dev/sda1 /mnt/sysimage/boot
Edit the fstab to look like this
#vi /mnt/sysimage/etc/fstab
/dev/VolGroup99/LogVol00 / ext3 defaults 1 1
LABEL=/boot /boot ext3 defaults 1 2
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0
/dev/VolGroup99/LogVol01 swap swap defaults 0 0
and the grub configuration
#vi /mnt/sysimage/boot/grub/grub.conf
# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,0)
# kernel /vmlinuz-version ro root=/dev/VolGroup99/LogVol00
# initrd /initrd-version.img
#boot=/dev/sda
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Red Hat Enterprise Linux Server (2.6.18-164.el5)
root (hd0,0)
kernel /vmlinuz-2.6.18-164.el5 ro root=/dev/VolGroup99/LogVol00 rhgb quiet
initrd /initrd-2.6.18-164.el5.img
Now reboot once again in rescue mode.
This time choose to mount the filesystem onto /mnt/sysimage (not in read only)
Finally, rebuild the initrd image, as it yet contains the old fstab, matching your kernel version
#chroot /mnt/sysimage
#mkinitrd -v -f /boot/initrd-2.6.18-164.el5.img 2.6.18-164.el5
Reboot into your newly renamed system.
Note: if you don't reboot into rescue mode before rebuilding the initial ram disk, the mkinitrd will fail as it won't find the new /dev/VolGroup99 pseudo files
Thanks for the detailed post! I was unable to remame a volumegroup using just the man page. I admire your spirit of giving back!
ReplyDeleteDavid K
2nd Try. I took a chance and didn't save what I typed in the hope that the web page wouldn't do something user-unfriendly, such as not post the entry AND clear the text box.
ReplyDeleteI would like to better understand the note at the bottom about mkinitrd not being able to find some pseudo files without a reboot. What files are they? I would like to find a method short of a reboot to make mkinitrd do its job.
I've successfully used your instructions (thanks) to create several disk drives - now with unique volume group names and unique UUIDs - that I can now use as destination disks for full-disk, live system backups. [Destination disk is a clone of the original disk; backup was done while the system was running - using a snapshot of the logical volume.] But, I want to be able to manipulate the destination disks from the running system, too; not from a rescue CD. And, I don't want to have to reboot the running system.
Wow! Thanks a lot for posting this!
ReplyDeleteI figured out the obvious part by myself, e.g. editing fstab and grub.conf files, but I was at a loss regarding the required rebuilding of the initrd.
For those who (like me!) wonder: this works even though one is rebuilding initrd for a different kernel than the one the host is running, provided that the appropriately-versionned files exist in the /lib/modules directory residing on the chrooted root filesystem. I successfully performed this procedure on an Oracle Linux 5.10 server, running an Oracle-provided UEK kernel (v2.3.39....), very different from the 2.6.18.... loaded from installation DVD.