Hi, I already reported this problem to azarah (Martin Schlemmer) personally. I file this bug report in order to make sure it isn't forgotten. The problem: Recently I migrated a HP Proliant DL380 G3 system from devfs to udev. This system makes use of LVM2 for disk space management purposes. The output of 'df' on the system looks like this: $ df Filesystem 1K-blocks Used Available Use% Mounted on /dev/cciss/c0d0p3 963768 48860 865948 6% / /dev/vg01/home 3096336 34476 2904576 2% /home /dev/vg01/opt 3096336 164304 2774748 6% /opt /dev/vg01/tmp 1032088 32840 946820 4% /tmp /dev/vg01/usr 3096336 1590944 1348108 55% /usr /dev/vg01/var 3096336 68988 2870064 3% /var none 1037692 0 1037692 0% /dev/shm Alas, after activating udev, the '/dev/vg01/...' device nodes were gone. Doing some research I learned that the udev daemon gets it's device names from sysfs. Sysfs produces it's own internal enumerated representation of device-mapper devices (/dev/dm-0, /dev/dm-1, ...). The current udev setup makes no attempt to create the familiar LVM2 device nodes, see the current /etc/udev/rules.d/50-udev.rules file: # dm devices (ignore them) KERNEL="dm-[0-9]*", NAME="" This is very annoying for people who use LVM2. My research led me to the multipath project. They have developed a package 'multipath-tools, which is currently not in portage. They obviously ran into the same problem as I did, and developed a small utility called 'devmap_name'. I downloaded the package (http://christophe.varoqui.free.fr/multipath-tools/multipath-tools-0.2.8.tar.bz2) compiled it, and installed the devmap_name program in /sbin by hand. On top of that, in /etc/udev/rules.d/50-udev.rule I commented out the line... KERNEL="dm-[0-9]*", NAME="" ...and activated the line... KERNEL="dm-[0-9]*", PROGRAM="/sbin/devmap_name %M %m", NAME="%k", SYMLINK="%c" ...instead. An lo and behold: everything suddenly looks familiar again! See the output below. # ls -l /dev/dm* brw-r----- 1 root root 254, 0 Sep 12 17:34 /dev/dm-0 brw-r----- 1 root root 254, 1 Sep 12 17:34 /dev/dm-1 brw-r----- 1 root root 254, 2 Sep 12 17:34 /dev/dm-2 brw-r----- 1 root root 254, 3 Sep 12 17:34 /dev/dm-3 brw-r----- 1 root root 254, 4 Sep 12 17:34 /dev/dm-4 # ls -l /dev/mapper/ total 0 crw-rw---- 1 root root 10, 63 Sep 12 17:34 control brw------- 1 root root 254, 2 Sep 12 17:34 vg01-home brw------- 1 root root 254, 3 Sep 12 17:34 vg01-opt brw------- 1 root root 254, 4 Sep 12 17:34 vg01-tmp brw------- 1 root root 254, 0 Sep 12 17:34 vg01-usr brw------- 1 root root 254, 1 Sep 12 17:34 vg01-var # ls -l /dev/vg* lrwxrwxrwx 1 root root 4 Sep 12 17:34 /dev/vg01-home -> dm-2 lrwxrwxrwx 1 root root 4 Sep 12 17:34 /dev/vg01-opt -> dm-3 lrwxrwxrwx 1 root root 4 Sep 12 17:34 /dev/vg01-tmp -> dm-4 lrwxrwxrwx 1 root root 4 Sep 12 17:34 /dev/vg01-usr -> dm-0 lrwxrwxrwx 1 root root 4 Sep 12 17:34 /dev/vg01-var -> dm-1 /dev/vg01: total 0 lrwxrwxrwx 1 root root 21 Sep 12 17:34 home -> /dev/mapper/vg01-home lrwxrwxrwx 1 root root 20 Sep 12 17:34 opt -> /dev/mapper/vg01-opt lrwxrwxrwx 1 root root 20 Sep 12 17:34 tmp -> /dev/mapper/vg01-tmp lrwxrwxrwx 1 root root 20 Sep 12 17:34 usr -> /dev/mapper/vg01-usr lrwxrwxrwx 1 root root 20 Sep 12 17:34 var -> /dev/mapper/vg01-var I'm not sure wether this solution is the right one, but it is obvious that something needs to be done about this. But even if it isn't the ultimate solution, it could be implemented as a temporary one. For this temporary solution support will have to be added in portage for the multipath-tools package. Thanks for your time. Toon van der Pas. Reproducible: Always Steps to Reproduce: 1. 2. 3.
This should be fixed in the latest version of udev (the nodes are created at start time in the correct order.)
