ikoniIf an LVM partition table or data containing the LVM information on the physical volume is ever lost, there is a way back out
First, boot the system without the volume active. Get in to single user.
Second, identify the device in question. In this example, let’s say /dev/sdb1 has lost its LVM information.
Third, find the latest archive of the volume information in /etc/lvm/archive which contains the UUID that the system cannot find, but you are sure it is the disk that has had its volume information overwritten or lost (in this example, let’s say the file is MyLVMgroupA.vg)
Fourth, run pvcreate to restore the information:
pvcreate –uuid –restorefile /etc/lvm/archive/MyLVMgroupA.vg -ff /dev/sdb1
Fifth, reboot and all is good. Run an fsck just to be on the safe side!
Fedora has become rather dramatic in its fast moving changes. Fedora of today is what RHEL will become, and the system as a whole will look entirely different. systemctl is one of the bigger changes, and going from Fedora 14 to Fedora 15 wasn’t that painl since most services transferred over with ease. However, going from Fedora 15 to Fedora 16, some key services got renamed.
It’s best to do a systemctl command prior to any upgrade to record what you had running previously. The NFS server, for example, is one such service that gets renamed and, thus, will not automatically start on an upgraded system due to the name change. To correct this:
Fedora, as do other distros, freaks out when you add a physical drive to a system which had been previously part of another logical volume. This doesn’t happen often, but if it does, the symptom is when you run system-config-lvm and it exits unexpectedly with:
'NoneType' object is not iterable
The way to resolve this is to fdisk the new disk on the system, create a partition on it, and write that partition table back to the disk. This overwrites the previous LVM information.