[linux-lvm] missing device nodes for vg, but vg appears in scan

[Geoff Mishkin]

Hi,

I am using lvm2 2.01.09 on Gentoo Linux.  My kernel version is 2.6.15 and I'm 
using udev 079.  I hope the @redhat.com suffix doesn't mean this is a Red 
Hat-only list, but if it does I'll gladly take my question elsewhere (I have 
not received an answer on the Gentoo forums).

I am trying to set up an LVM2 VG using a loop device.  My problem is that 
device nodes are never created for my VG.  However, my VG shows up in scans 
(vgscan) and displays (vgdisplay).  Even vgscan --mknodes does not make the 
nodes.  Because I never get a node for my VG, I can't figure out how I am 
supposed to create LV's in it.

I have the modules loop, dm-mod and dm-snapshot loaded.  Therefore, I do 
have /dev/mapper/control.  Here is what I have done so far:

 o Create file and set up to use with loop device
# dd if=/dev/zero of=/local/snapshot bs=1M count=512
# losetup /dev/loop0 /local/snapshot
 o Set up the PV
# pvcreate /dev/loop0
 o Create the VG
# vgcreate snapshot /dev/loop0

At this point commands like this fail:
# lvcreate -L512 -s -n backup snapshot
  Path required for Logical Volume "snapshot"
  The origin name should include the volume group.
# lvcreate -L512 -s -n backup /dev/snapshot
  "/dev/snapshot": Invalid path for Logical Volume
  The origin name should include the volume group.

I have read in the docs that "vgscan" is run automatically now and that I 
should expect to see my VG in /dev.  This does not happen so I do the 
following:

 o Try to activate the VG
# vgchange -a y snapshot
  0 logical volume(s) in volume group "snapshot" now active
 o Try running vgscan manually
# vgscan
  Reading all physical volumes.  This may take a while...
  Found volume group "snapshot" using metadata type lvm2
# vgscan --mknodes
  Reading all physical volumes.  This may take a while...
  Found volume group "snapshot" using metadata type lvm2
 o No results in /dev, try vgdisplay
# vgdisplay
  --- Volume group ---
  VG Name               snapshot
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  1
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                0
  Open LV               0
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               508.00 MB
  PE Size               4.00 MB
  Total PE              127
  Alloc PE / Size       0 / 0
  Free  PE / Size       127 / 508.00 MB
  VG UUID               RG5GM3-WrEZ-PmCM-Fl0A-wjAy-Udqo-xLASVj

It looks like my VG is there, but it still isn't showing up in /dev.  I read 
something about how if udev isn't configured properly, you will get devices 
like /dev/dm-# where # is 0-9, instead of named VG nodes.  I don't have those 
either, but I follow the instructions which are to uncomment a line in my 
udev rules:

KERNEL=="dm-[0-9]*",    PROGRAM="/sbin/devmap_name %M %m", NAME="%k", 
SYMLINK+="%c"

I learn that devmap_name is included with multipath-tools, so I install those, 
version 0.4.6.  I reload my udev rules and repeat the steps above, but there 
is no change.  Then I wonder if this has anything to do with the multipath 
target in the kernel configuration for the device mapper.  I enable it, 
reboot for good measure, and load the multipath module.  I repeat the steps 
above, but there is still no change.

At this point I wonder if udev has some problem outside the scope of my 
imagination, so I try to see if I can use vgscan to create nodes outside 
of /dev by editing lvm.conf.  When I run vgscan --mknodes, however, it still 
only creates mapper/control.  I guess I shouldn't have really expected that 
to work, but it's still weird.

Please CC me on replies as I am not subscribed to the list.

			--Geoff Mishkin <gmishkin at bu.edu>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/linux-lvm/attachments/20060122/e7e87296/attachment.sig>