2011-11-25

How to rename the root volume group

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

3 comments:

  1. Anonymous21/3/13 18:49

    Thanks for the detailed post! I was unable to remame a volumegroup using just the man page. I admire your spirit of giving back!
    David K

    ReplyDelete
  2. Anonymous19/7/13 22:40

    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.

    I 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.

    ReplyDelete
  3. Anonymous19/9/14 20:14

    Wow! Thanks a lot for posting this!

    I 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.

    ReplyDelete