vgcreate failure

[Pete Randall]

I'm trying to re-create a volume group. Sam can't see it yet when it tries to create it, it says the physical volume is already recorded in /etc/lvmtab. I've tried re-creating lvmtab with vgscan but it complains "The Volume Group /dev/vg99 was not matched with any Physical Volumes."

I can't go forward and I can't go back - it's the proverbial Catch-22.

Pete

[Jeff Schussele]

Pete,

Did you mv lvmtab prior to vgscan?
Also IF you know for a fact that the the vg99 is no longer used, try to vgexport it. Then also IF you know the PV is no longer unused do a pvcreate -f on it.
Then rerun your vgscan again prior to vgcreate.

HTH,
Jeff

[Tom Maloy]

Sounds like the VG exists, but in an odd state. Can you use vgextend to add a disk to the VG, and then use vgscan? I know that you need at least one disk to remove it. That still would leave the ? of how the last disk got removed...

Tom

[Jeff Schussele]

DOOOOOHHHHH....PV no longer used.....

Jeff

[Pete Randall]

Jeff/Tom,

Hang on - I'm re-trying the vgscan after making absolutely sure that I moved it first. I'll get back to you in a few minutes.

Pete

P.S. Jeff, when I went back and looked at my wizard congratulatory thread yesterday I noticed that it was you and Steven at the head of the list again - he started it and you had the first response. Are you two my guardian angels, or what?

[James R. Ferguson]

Hi Pete:

Make sure that the minor number of the volume group you are trying to create is unique. Do:

# ls -l /dev/vg*/group

Regards!

...JRF...

[Martin Johnson]

"vgexport /dev/vg99" should work. Does /dev/vg99 and /dev/vg99/group exist?

Marty

[Pete Randall]

OK, vgscan finished and said:
The Volume Group /dev/vg99 was not matched with any Physical Volumes.
*** LVMTAB has been created successfully.
*** If PV links are configured in the system.
*** Do the following to resync information on disk.
*** #1. vgchange -a y
*** #2. lvlnboot -R

Now, however, when SAM tries to create the vg, it says
"A volume group is already using this major and minor number"

Aarghh!

[Tom Maloy]

Look for duplicate minor numbers in the /dev/vgXX/group file information. Perhaps one got "fat-fingered".

Tom

[Pete Randall]

I've tried removing /dev/vg99 and still it complains that the major and minor number are in use. I tried a different vgname (vg22) and it still complains. Vgexport complains that vg99 is not listed in lvmtab. Looking at /dev/vg*/group shows that the minor number SAM is trying to use should be unique (SAM's trying to use 0x040000):
ll /dev/vg*/group
crw-r----- 1 root sys 64 0x000000 Feb 14 2000 /dev/vg00/group
crw-rw-rw- 1 root root 64 0x010000 Jul 13 09:12 /dev/vg01/group
crw-rw-rw- 1 root root 64 0x020000 Jul 13 09:12 /dev/vg02/group
crw-r--r-- 1 root sys 64 0x030000 Jun 27 2000 /dev/vgswap/group

[S.K. Chan]

I suspect that you some "abnormality" in some of your VG configuration. The minor number (0x040000) may not appear to be used in all the /dev/vg*/group files but it may still be in the kernel. Can you try to manually creating it (with command lines) but use another minor number (say 0x080000 or what ever).

[Helen French]

Thought to add a note:

If possible bring system to single user mode, unmount all data file systems and try:

1) vgexport
2) check lvmtab
3) do vgscan -a
4) Create new vg with unique number
5) Add disk

In either case, vgexport should work very easily. Carefully check the settings and try resolving one by one !

[Jeff Schussele]

Hi Pete,

No I just wanted to see you squirm a little again ;~)
Steve & I just happened to post @ the same time.

Back to the issue @ hand:
1) It is possible (but unprobable) that there's a misconfigured LV minor number in a VG. Look down thru them all to make sure you don't have am 0x040002 or such.

2) Possible that something was/is linked to the old /dev/vg99/group entry or vice/versa.

2) highly possible that the kernel thinks there's an 64 0x040000 device out there.

For now manually create it with 64 0x050000 & track it down after the next reboot. May be gone after a reboot....


Rgds,
Jeff

[Pete Randall]

I tried the manual method.
mkdir /dev/vg99
mknod /dev/vg99/group c 64 0x050000
pvcreate /dev/rdsk/c18t1d2
pvcreate /dev/rdsk/c18t1d3
vgcreate /dev/vg99 /dev/dsk/c18t1d2 /dev/dsk/c18t1d3
Increased the number of physical extents per physical volume to 17326.
vgcreate: Volume group "/dev/vg99" could not be created:
Device busy

lsof /dev/dsk/c18t1d2 shows nothing.

Unless someone comes up with something brilliant, I think I'm going to give up for now and come in this weekend when I can re-boot this server.

[Jeff Schussele]

I'd physically check those drives.
Are they active - light on?
If you're sure of just which they are & they're hot-swappable, I'd pull them for 10-20 seconds & reseat them.
Something may have them tied up for some reason.

Also if this is a shared array, be damn sure that another system doesn't have it mitts on 'em.

Rgds,
Jeff

[James R. Ferguson]

Hi Pete:

DOes 'diskinfo' yield good information (like a disk size > 0)?:

# diskinfo /dev/rdsk/c18t1d2

Second, can you do the 'vgcreate' without this disk?

I'm beginning to think you have a bad disk.

Regards!

...JRF...

[Pete Randall]

Jeff/James,

It's a pair of RAID 5 luns in an FC60 array. No failure lights. Diskinfo looks good. I really don't think there's anything wrong with the disk(s). I'll run a *little* dd just to prove that they can be exercised - it would probably take hours to dd the whole 140 MB.

Pete

[Pete Randall]

The dd was successful - I read about a gig off of each lun. I think, at this point, a re-boot is in order so I'll come in Sunday and see if that helps or makes things worse and post results on Monday.

My thanks to all.

Pete

[Deshpande Prashant]

Hi
Can you check pvdisplay on those disks?

Thanks.
Prashant.

[Pete Randall]

pvdisplay /dev/dsk/c18t1d2
pvdisplay: Couldn't find the volume group to which
physical volume "/dev/dsk/c18t1d2" belongs.
pvdisplay: Cannot display physical volume "/dev/dsk/c18t1d2".
Same for the other.

[Helen French]

Did you try a pvcreate -f on these disks ? Did you try some other vgname (not vg99) and then changing the major and minor numbers just to make sure that it's not conflicting.

[Pete Randall]

Shiju,

#mkdir /dev/vg20
# mknod /dev/vg20/group c 64 0x060000
# vgcreate /dev/vg20 /dev/dsk/c18t1d2 /dev/dsk/c18t1d3
Increased the number of physical extents per physical volume to 17326.
vgcreate: Volume group "/dev/vg20" could not be created:
Device busy

Pete

[Wodisch_1]

Hi Pete,

I seem to remember having seen that quite some years ago... Can you please try to use "vgcreate" with some options:

vgcreate -s 32 -e 2048 -l 32 /dev/vgXX ...

does it work now?
If yes, then it was a *wrong* error-message (your LVM headers did not fit into a single PE).

HTH,
Wodisch

[Volker Borowski]

Hi,
open for some desperate ideas ?

ll /dev/*/group
--> a volume group name does not need to start with vg

Somebody reduced "the kernel tunable parameter maxvgs" to 4 ?

I noticed diffrent permissions/ownerships on the group-files, although the ones on my system differ as well.

Just vague ideas
Volker

[Pete Randall]

Wodisch,

vgcreate -s 32 -e 2165 -l 32 /dev/vg20 /dev/dsk/c18t1d2 /dev/>
vgcreate: Volume group "/dev/vg20" could not be created:
Device busy

Pete