rebuild lvmtab?

[Todd Pardi_1]

Hi All,

What risks do I run if my lvmtab files are more or less empty? I have a bunch of boxes that it looks like a vgexport was run but there are no mapfiles. Is there any way other than a vgscan to rebuild this information? Also, does it matter if minor number used in the mknod does not match the original minor used? Any help would be appreciated.

[Rajeev Shukla]

If lvmtab files are empty, you wont be able to activate any VG and if root vg is also not present in lvmtab file then your system i guess wont come to normal state (multiuser mode)
If you dont want to run vgscan then you should know what disks belonged to what VG and then do a vgimport using the disks.
you can use different minor number to what they were originaly.

[Albert_31 · Accepted solution]

Hello Todd,

Good Day,

The lvmtab files should be having the VG00 entries and hope that they do.

To answer your questions.

a) Is there any way other than a vgscan to rebuild this information?

though vgscan is the easiest way, we do have the vgimport command to help rebuild the lvmtab file with entries for that particular vg. I would suggest the following be done

Collect the information about the vg's and pv's

# vgscan -p -v
Here we do a vgscan in preview mode, this helps to determine if the system is able to identify the disks to the volume groups.

or

# vgcfgrestore -l -f /etc/lvmconf/ should also help if it is the latest one and regularly updated.

Once you ascertain which are the disks that belong to the volume group

# cp -P /etc/lvmtab /etc/lvmtab. for backup
# mkdir /dev/vgname
# mknod /dev/vgname/group c 64 0xXX0000
where XX is teh minor number of the group

# vgimport -p -v /dev/vgname
The above command does the import in preview mode so taht you can correct any issues/errors. Once you clear all the errors

# vgimport -v /dev/vgname



b) Also, does it matter if minor number used in the mknod does not match the original minor used?

No it does not matter, however recommended.

regards

[James R. Ferguson]

Hi:

Generally one renames the current '/etc/lvmtab' and runs 'vgscan' to create a new one. In this fashion, the file is built from scratch.

Mapfiles have no relationship to '/etc/lvmtab'. Mapfiles associate (map) *logical volume* minor numbers with their names. In the absence of a mapfile, a 'vgimport' will name logical volumes 'lvolN' where N varies from 1..n and N matches the value found in the LVM header, or VGRA (Volume Group Reserved Area). During a 'vgimport' device file are created for the logical volumes to match.

You can construct your own missing mapfile to look like:

1 lvol1
2 mylvoltwo <--- nonstandard name
3 lvol3

Please read the manpages for 'vgscan' if you use it. You will likely need to arrange your primary and alternate links (pvlinks) after the '/etc/lvmtab' is rebuilt. Remember that it is only the *order* of the pvlinks that determines which is a "primary" and which is a "secondary" -- he who is first is the primary pvlink.

To swap a primary and an alternate pvlink, simply 'vgreduce' the primary and; 'vgextend' the same link. This promotes the secondary link to primary status and adds the old primary back in as a secondary (alternate) pvlink.

Regards!

...JRF...

[Bill Hassell]

"...lvmtab files are more or less empty?"

What caused this situation? The lvmtab file contains all the information for activated volume groups. If something has trashed lvmtab, you can rename it and rebuild it using vgscan. If lvmtab (and your device files) have been removed, you've got some work ahead of you.

But vgscan does NOT find inactive volume gtroups nor does it build directories and device files for missing volumes. You would use vgimport along with /etc/lvmconf to accomplish this task. You can also import the missing volume groups using SAM. SAM will create the directories and volume groups but a lot depends on what cause the problem in the first place.

[Todd Pardi_1]

Thank you all for your responses, I believe I have all the info I need.

Regards