vg00 missing from lvmtab, vgdisplay, and lvlnboot

[Bernie Vande Griend]

Got a strange one here on a HP-UX 10.20 system. vg00 is missing from /etc/lvmtab, vgdisplay -v and lvlnboot -v. We did have some major changes with non-vg00 volumes on here and perhaps somehow vg00 got messed up. All forms of vgscan end up with a core dump, and with moving /etc/lvmtab out of the way. There is no /etc/slvmvg file so that is not the issue. I can get information out of the vgcfgrestore for vg00 and I do know the two drives that should be in vg00 (mirrored together) and there is no issue with them. The system itself is still running fine and even reboots fine. /dev/vg00/group seems to also be fine. I know I have the option of booting into LVM maintenance mode and doing a vgexport and then an vgimport but I wanted to get some 2nd opinions and see if anyone else had some ideas. Also let me know of safety steps I should do before the maintenance mode option if that is want I need to do.

[Patrick Wallek]

Did you happen to duplicate a VG's minor number?

What does:

# ll /dev/vg*/group

show? Are all the minor numbers unique? They should all be of the format 0x0?0000 where the ? is unique among all vg*/group files.

[Steven E. Protter]

Every time this happened to me it was due to duplciate minor numbers as Patrick says.

Fix that and try again.

make_tape_recovery tape handy?

SEP

[Bernie Vande Griend]

No duplication that I can find (one of the first things I checked:
crwxrwxrwx 1 root sys 64 0x000000 Feb 6 2003 /dev/vg00/groupcrw-rw-rw- 1 root sys 64 0x030000 Jan 18 10:14 /dev/vg01/groupcrw-rw-rw- 1 root sys 64 0x040000 Jan 18 10:22 /dev/vg02/groupcrw-rw-rw- 1 root sys 64 0x050000 Jan 18 10:23 /dev/vg03/groupcrw-rw-rw- 1 root sys 64 0x060000 Jan 18 10:23 /dev/vg04/group

We might have a recovery tape although I know Ignite is failing now since that is first how we found the problem.

[Mic V.]

In what way is Ignite failing? I had a server with several messed-up non-vg00 VGs. An older Ignite just refused to make a tape, but a newer one complained and wrote the tape anyway. (It was a phantom volume problem.) Perhaps a new version would help, assuming you could install it.

[Sridhar Bhaskarla]

Hi,

At the best you could do is to export the external volume groups and restore lvmtab from your backups and see if it works.

If not, you know the last resort anyway. In the maintenance mode, be sure to check the autofile and run all 'lvlnboot' commands. Double check the output of lvlnboot -v and strings /etc/lvmtab before you reboot it to normal mode.

-Sri

[Bernie Vande Griend]

Ignite is not the issue here, it is just a symtom of a larger problem. Ignite worked fine until we had the issue with vg00.

Sridhar, that's a good idea to try to export the other volume groups, restore the lvmtab and then reimport them, but most likely the lvmtab that I will restore will have older physical volumes for these external volume groups and I'm not sure if they will interfere. (we just replaced SANs). If I export them, replace the lvmtab, do I export again to clear up the old lvmtab, and them import? Actually this option may be just as risky as going into LVM maintenance mode. Anyway, any other thoughts are welcome.

[Mic V.]

My point was that if you want to make an Ignite tape for paranoia purposes, changing versions might help. That way, whatever you do with vg00 could be considered less risky. Sorry I wasn't more clear.

[Sridhar Bhaskarla]

Hi,

Since the VGs are not in activated state after the restoration, you should be able to get rid of them using vgexport. Make sure you have map files taken on the existing VGs with all the possible options (-s, -f)and copy them over to a network system.

-Sri

[Anoop P_2]

I beleive, for exporting a VG, the physical volumes should be accessible. If those old physical volumes are detached, then exporting those vgs from your old lvmtab might become a challenge.

Anoop

[Bernhard Mueller · Accepted solution]

Bernie,

if this reply is not too late:

once I had a similar issue on 10.20 where vgscan would core dump - however running /sbin/vgscan did the trick.

Regards,
Bernhard

[Fabio Ettore]

Hi Bernie,

just a thought: you talked about /etc/slvmvg; I know that it is under /dev, that is /dev/slvmvg.
Is it just a your typo or have you searched for /etc/slvmvg exactly?
Otherwise

# mv /dev/slvmvg /tmp
# mv /etc/lvmtab /tmp/lvmtab.old
# vgscan -v

I hope this helps you.

Best regards,
Ettore

[Bernie Vande Griend]

Bernhard, you the man!! I'd give you 20 points if I could. /sbin/vgscan works just fine and did not core dump and brought the correct lvmtab back. vgdisplay, lvlnboot, etc all works now. Now I don't need to do anything risky or have any extra downtime.
Ettore, yes that was a typo, I meant /dev/ not /etc. Thanks everyone for your help!