решение:
--- 00-lsb.rules        2005-03-31 18:57:09 +0300
+++ 00-lsb.rules.gns    2005-07-15 01:37:18 +0300
@@ -15,7 +15,6 @@

 # block
 # ignore dm
-KERNEL="dm-[0-9]*",            NAME=""
 KERNEL="device-mapper",                NAME="mapper/control"

 KERNEL="raw[0-9]*",            NAME="raw/%k"
-------------------------------------------
/etc/udev/rules.d/10-lvm.rules:
## LVM compatibility by gns@altlinux.org
KERNEL="dm-[0-9]*",     PROGRAM="/etc/udev/scripts/lvm-vg.sh %M %m", NAME="%k",
SYMLINK="%c"
-------------------------------------------
/etc/udev/scripts/lvm-vg.sh:
#!/bin/sh
## LVM compatibility by gns@altlinux.org
[ -e /usr/sbin/vgmknodes ] && /usr/sbin/vgmknodes >/dev/null 2>/dev/null
/sbin/devmap_name $*
-------------------------------------------
упомянутый devmap_name выковыривается отсюда:
http://gd.tuwien.ac.at/gnu/sourceware/dm/multipath-tools/multipath-tools-0.4.3.tar.bz2

можно не собирать весь multipath-tools, взять один файл и положить в
libdevmapper или сам udev.

Created attachment 989 [details]
devmap_name.c

Created attachment 990 [details]
makefile for it

Created attachment 991 [details]
devmap_name.c

*** Bug 7370 has been marked as a duplicate of this bug. ***

IMHO все-таки стоит собрать multipath-tools

Может быть соберете ?

там есть только одна проблема:
gpt.c:85: undefined reference to `__le16_to_cpu'

надо либо затащить byteorder к себе, либо попробовать собрать с
glibc-kernheaders, но в этом случае может поломаться что-то другое.

да, в новом multipath-tools пофиксили сборку.

но он доступен только в git

За основу можно взять пакет из SuSE:
http://ftp.lug.ro/suse/people/lmb/multipath-tools/multipath-tools-0.4.4-0.18.src.rpm

> IMHO все-таки стоит собрать multipath-tools  
  
кому-то оно надо? + в udev появляется совершенно излишняя зависимость на  
этот пакет. imho все же стоит иметь отдельный бинарь   
  
(независимо от этого с multipath я все же поиграюсь).  
  

Надо.

Да и devmap_name можно собрать в отдельный пакет, но из multipath-tools.src.rpm

Nick, так и не добрался ты до  multipath-tools ?

(In reply to comment #10)   
> Nick, так и не добрался ты до  multipath-tools ?   
   
добирался... тестировать не на чем, из него всего мне один devmap_name нужен.  
но могу залить с формулировкой УМР :)  
   

заливай, там разберемся.

(In reply to comment #12)       
> заливай, там разберемся.       
       
залил. осталось придумать в какой пакет положить все эти  /etc/udev/scripts/lvm-vg.sh      
(обычный rules.d/multipath.rules не катит -  нужно делать vgmknodes).    
 

либо в multipath-tools, либо соответственно в lvm2

Надо подумать как лучше сделать.

Можно конечно и в udev, но тогда мне придется в нем поставить соответствующие
зависимости.

(In reply to comment #14) 
> либо в multipath-tools 
я вынес devmap_name в отдельный пакет, тогда уж в него. но лучше не стоит. 
 
>либо соответственно в lvm2 
а если udev нету?  
 
> Надо подумать как лучше сделать. 
> Можно конечно и в udev, но тогда мне придется в нем поставить соответствующие 
> зависимости. 
на маленький devmap_name, наверное так лучше всего. нужно еще из дефолтных правил 
вынести строку про ignore dm.  
 

(In reply to comment #15)
> (In reply to comment #14) 
> > либо в multipath-tools 
> я вынес devmap_name в отдельный пакет, тогда уж в него. но лучше не стоит.

Почему ?
 
>  
> >либо соответственно в lvm2 
> а если udev нету?  

Если udev нет, то все равно все будет работать.

>  
> > Надо подумать как лучше сделать. 
> > Можно конечно и в udev, но тогда мне придется в нем поставить соответствующие 
> > зависимости. 
> на маленький devmap_name, наверное так лучше всего. нужно еще из дефолтных правил 
> вынести строку про ignore dm.  

Лучше конечно если это кто-то сделает в отдельных пакетах.

Ну или в виде патча к текущему udev (068-alt2).

Но лучше все-таки отдельно.

> Почему ?   
некрасиво   
   
можно отдельно udev-lvmtool, в него эту ботву. и пусть udev (или lvm? как все сложно :)) 
требует этот пакет.  а он требует devmap_name. 

ну так что, пакет готов ?

давно в сизифе
-rw-r--r--    1 ftp      ftp          9090 Sep 01 13:25
multipath-tools-devmap_name-0.4.4-alt0.18.i586.rpm

, а вот как положить конфиги - я не знаю. проблема в отсутствии у rpm hints -
этот пакет должен ставиться если установлены udev и lvm2

Конфиг можно дать мне, и я его включу в udev

multipath-tools а также multipath-tools-devmap_name снова в Сизифе, приведенные
выше /etc/udev/rules.d/10-lvm.rules и /etc/udev/scripts/lvm-vg.sh вполне рабочие
- можно включать их в udev с зависимостью на multipath-tools-devmap_name

Включим в следущей сборке.

с одной поправкой в lvm-vg.sh: 
/sbin/devmap_name $* | sed 's,|,/,g' | sed 's,lvm2/,,'

я делаю так, для того чтобы имена устройств LV до загрузки udev и после
совпадали: типа /dev/mainvg/coolvolume.

так где брать этот lvm-vg.sh  и правила для udev?

Сейчас есть такое правило:
KERNEL=="dm-[0-9]*", ACTION=="add", PROGRAM="/sbin/dmsetup info -c --noopencount
--noheadings -o name -j %M -m %m", SYMLINK="disk/by-name/%c"

его не достаточно ?

посмотрите на последнем udev.

Судя по всему сейчас lvm'ные тома создаются в /dev/disk/by-name/

(In reply to comment #25)
> посмотрите на последнем udev.
> 
> Судя по всему сейчас lvm'ные тома создаются в /dev/disk/by-name/
> 

это хорошо, но этого недостаточно - хотелось бы чтобы были доступны
/dev/vgtest/lvtest. 

[root@mordor ~]# /sbin/dmsetup info -j 253 -m 0
Name:              test-lvtest
State:             ACTIVE
Tables present:    LIVE
Open count:        0
Event number:      0
Major, minor:      253, 0
Number of targets: 1
UUID: LVM-mqIQOvy4V0T2LLfF67WgfFsdA7iFEAkPy9UwCbiNG7a0zGo9Nqc56wj4izwSqZH9

хм. если у lvm томов всегда есть "LVM" в UUID, можно их по этому признаку искать
и для них создавать дополнительный симлинк, типа 

/sbin/dmsetup info --noheadings -c -o name -j 253 -m 1 | sed 's,-,/,g' | sed
's,//,-,g'

давай я вечерком напишу обвязку для всего этого - обрабатывая LVM специальным
образом и сохраняя текущее поведение для остальных?

Давай.

Тогда сразу делай патч на мой git:
rsync://rsync.altlinux.org/people/rider/git/udev.git

(In reply to comment #29)
> Давай.
> 
> Тогда сразу делай патч на мой git:
> rsync://rsync.altlinux.org/people/rider/git/udev.git
> 

gns@mordor new/udev/git $ git-clone
rsync://rsync.altlinux.org/people/rider/git/udev.git git
Welcome to ALT Linux Team public rsync server!

receiving file list ... rsync: link_stat "/rider/git/udev.git/objects/." (in
people) failed: No such file or directory (2)
done

Created attachment 1490 [details]
поддержка LVM device nodes 

замечательно работает с вот такой штукой:
scripts/dm_helper.sh:
#!/bin/sh
dminfo=$(/sbin/dmsetup info -c --noopencount --noheadings -j $1 -m $2)
echo DM_NAME=$(echo $dminfo | cut -d: -f 1)
echo DM_NAME_LVM=$(echo $dminfo | cut -d: -f 1 | sed 's,-,/,g' | sed
's,//,-,g')
echo DM_ID=$(echo $dminfo | cut -d: -f 8 )


после этого получаем:

find /dev/ -name \*te\*
/dev/test
/dev/test/lvtest-my
/dev/test/lvtest
/dev/disk/by-name/test-lvtest--my
/dev/disk/by-name/test-lvtest

забыл udev.git выложить

Сейчас можно забрать.

По поводу изменения: я считаю не очень хорошо, когда создаются какие-то файлы по
именам в /dev/

т.е. - если я правильно понял, то DM_NAME_LVM в теории может привести к
неработоспособности чего-либо, если пользователь назовёт том каким-то именем,
под которое есть устройство.

Например hda

> т.е. - если я правильно понял, то DM_NAME_LVM в теории может привести к
> неработоспособности чего-либо, если пользователь назовёт том каким-то именем,
> под которое есть устройство.
> 
> Например hda

только если обозвать volume group, тогда будет дира /dev/hda/. 

> > Например hda
> только если обозвать volume group, тогда будет дира /dev/hda/. 

том *всегда* будет в подкаталоге: /dev/hda/lvolume.

LVM по жизни так работает, если без udev. и vgchange -ay именно так создает - в
т.ч. поверх udev (возможно, он для начала не позволит vgcreate hda ?).

а пользователь если захочет, всегда сможет прострелить себе ногу.

Понятно. 

Тогда давайте так:
скрипт переместите в /lib/udev/

и бросайте сюда патч на git.

Created attachment 1493 [details]
git patch for udev 091

вот, собственно

Добавил в 092-alt1

Сейчас при запущенном udevd имеем такое поведение:

# lvscan
   ACTIVE            '/dev/system/root' [2.00 GB] inherit
   ACTIVE            '/dev/system/home' [1.00 GB] inherit
   ACTIVE            '/dev/system/var' [1.00 GB] inherit
   ACTIVE            '/dev/system/data' [65.00 GB] inherit
# /sbin/lvcreate -L1000 -s -nhomebackup /dev/system/home
   Symbolic link /dev/mapper/system-home not created: file exists
   Failed to create symlinks for home.
   Failed to suspend origin home
# lvscan
   ACTIVE            '/dev/system/root' [2.00 GB] inherit
   ACTIVE            '/dev/system/home' [1.00 GB] inherit
   ACTIVE            '/dev/system/var' [1.00 GB] inherit
   ACTIVE            '/dev/system/data' [65.00 GB] inherit
   ACTIVE            '/dev/system/homebackup' [1000.00 MB] inherit
# mount /dev/system/homebackup /mnt/backup
/dev/system/homebackup: Invalid argument
mount: /dev/system/homebackup: can't read superblock
# lvremove /dev/system/homebackup
Do you really want to remove active logical volume "homebackup"? [y/n]: y
   Logical volume "homebackup" successfully removed

Способ борьбы (думаю, сильно неправильный) : комментируем в
60-persistent-storage.rules все строки с KERNEL=="dm-[0-9]*", откатываемся на
10-lvm.rules и lvm-vg.sh, а затем после каждого создания/удаления логических
томов вызываем lvscan. Если не делать вышесказанного, то нужно время от времени
удалять инвалидные ссылки вида /dev/vgname/lvname -> /dev/mapper/vgname-lvname, 
/dev/mapper/vgname-lvname удаляется сам.

Как правильно с этим бороться?

2gns:
что скажешь ?

(In reply to comment #39)
> 2gns:
> что скажешь ?

откуда ссылки /dev/vgname/lvname -> /dev/mapper/vgname-lvname - я не знаю, у
меня их нет:
[root@localhost eth0]# ll /dev/caybo/mirror
lrwxrwxrwx 1 root root 7 May 25 03:10 /dev/caybo/mirror -> ../dm-1


у меня все работает на свежеустановленном 3.0, обновленом до сизифа:

[root@localhost eth0]# lvscan
  ACTIVE            '/dev/caybo/postie' [400.00 MB] inherit
  ACTIVE            '/dev/caybo/mirror' [10.00 GB] inherit

[root@localhost eth0]# lvcreate -s -L100M -n postiebackup /dev/caybo/postie
  Logical volume "postiebackup" created

root@localhost eth0]# lvscan
  ACTIVE   Original '/dev/caybo/postie' [400.00 MB] inherit
  ACTIVE            '/dev/caybo/mirror' [10.00 GB] inherit
  ACTIVE   Snapshot '/dev/caybo/postiebackup' [100.00 MB] inherit

[root@localhost eth0]# mount /dev/caybo/postiebackup /mnt/floppy/
[root@localhost eth0]# mount
/dev/hda2 on / type ext3 (rw)
proc on /proc type proc (rw,gid=19)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/hda1 on /boot type ext3 (rw)
udev on /dev type tmpfs (rw,mode=755,size=5m)
/dev/pts on /dev/pts type none (rw)
shmfs on /dev/shm type tmpfs (rw)
usbfs on /proc/bus/usb type usbfs (rw)
/dev/dm-0 on /var/lib/vservers/postie.caybo.ru type ext3 (rw)
/dev/dm-1 on /var/ftp/pub type ext2 (rw)
/dev/dm-4 on /mnt/floppy type ext3 (rw)
[root@localhost eth0]# rpm -q lvm2
lvm2-2.02.01-alt2
[root@localhost eth0]# rpm -q udev
udev-092-alt1
[root@localhost eth0]# umount /mnt/floppy/
[root@localhost eth0]# lvremove /dev/caybo/postiebackup
Do you really want to remove active logical volume "postiebackup"? [y/n]: y
  Logical volume "postiebackup" successfully removed
[root@localhost eth0]# ll /dev/caybo/
total 0
drwx------  2 root root   80 May 25 14:15 ./
lrwxrwxrwx  1 root root   24 May 25 14:15 postie -> /dev/mapper/caybo-postie
drwxr-xr-x 11 root root 3660 May 25 14:15 ../
lrwxrwxrwx  1 root root    7 May 25 03:10 mirror -> ../dm-1
[root@localhost eth0]# lvcreate -s -L100M -n postiebackup /dev/caybo/postie
  Logical volume "postiebackup" created
[root@localhost eth0]# lvscan
  ACTIVE   Original '/dev/caybo/postie' [400.00 MB] inherit
  ACTIVE            '/dev/caybo/mirror' [10.00 GB] inherit
  ACTIVE   Snapshot '/dev/caybo/postiebackup' [100.00 MB] inherit
[root@localhost eth0]# lvremove /dev/caybo/postiebackup
Do you really want to remove active logical volume "postiebackup"? [y/n]: y
  Logical volume "postiebackup" successfully removed

... и так далее. не воспроизводится, в общем.

> Способ борьбы ...

Однако этот способ все равно приводит к:

+ /sbin/lvscan
  /dev/dm-4: stat failed: No such file or directory
  Path /dev/dm-4 no longer valid for device(253,4)
  /dev/disk/by-uuid/7ac36a0d-59a7-457a-871a-0b2e929c3a8d: stat failed: No such
file or directory
  Path /dev/disk/by-uuid/7ac36a0d-59a7-457a-871a-0b2e929c3a8d no longer valid
for device(253,4)
  Aborting - please provide new pathname for what used to be
/dev/disk/by-uuid/7ac36a0d-59a7-457a-871a-0b2e929c3a8d
  ACTIVE            '/dev/system/root' [2.00 GB] inherit
  ACTIVE            '/dev/system/home' [1.00 GB] inherit
  ACTIVE            '/dev/system/var' [1.00 GB] inherit
  ACTIVE            '/dev/system/data' [65.00 GB] inherit

(In reply to comment #41)
> > Способ борьбы ...
> 
> Однако этот способ все равно приводит к:
> ...

Но не всегда. Вот сейчас не воспроизвелось :(

пожалуйста, если есть возможность - попробуйте воспроизвести на чистом сизифе
(3.0 -> sisyphus). у меня не воспроизводится, похоже на какой-то подземный стук
в самом lvm - зачем ему /dev/disk/by-uuid/7ac36a0d-59a7-457a-871a-0b2e929c3a8? 

(In reply to comment #40)
> (In reply to comment #39)
> > 2gns:
> > что скажешь ?
> 
> откуда ссылки /dev/vgname/lvname -> /dev/mapper/vgname-lvname - я не знаю, у
> меня их нет:
> [root@localhost eth0]# ll /dev/caybo/mirror
> lrwxrwxrwx 1 root root 7 May 25 03:10 /dev/caybo/mirror -> ../dm-1

Удалил 10-lvm.rules и lvm-vg.sh, раскомментировал в
60-persistent-storage.rules все строки с KERNEL=="dm-[0-9]*". Перегрузился. Имею:

root@asterisk ~ # ls -l /dev/mapper                                   
total 0
lrwxrwxrwx 1 root root 16 May 25 19:19 control -> ../device-mapper
root@asterisk ~ # ls -l /dev/device-mapper 
crw-rw---- 1 root root 10, 63 May 25 19:19 /dev/device-mapper
root@asterisk ~ # ls -l /dev/system       
ls: /dev/system: No such file or directory
root@asterisk ~ # lvscan 
  ACTIVE            '/dev/system/root' [2.00 GB] inherit
  ACTIVE            '/dev/system/home' [1.00 GB] inherit
  ACTIVE            '/dev/system/var' [1.00 GB] inherit
  ACTIVE            '/dev/system/data' [65.00 GB] inherit

На самом деле все так: есть hda и hdc, hda1+hdc1 - это md0 (/boot), на hda2 и
hdc2 - swap, hda3+hdc3 - это md1, который целиком отведен под system. Загрузкой
занимается специальный initrd, в linuxrc которого написано:

#!/bin/sh

/bin/insmod -f 
/lib/modules/2.6.16-std26-up-alt5/kernel/drivers/md/dm-mod.ko
/bin/insmod -f 
/lib/modules/2.6.16-std26-up-alt5/kernel/drivers/ide/ide-core.ko
/bin/insmod -f 
/lib/modules/2.6.16-std26-up-alt5/kernel/drivers/ide/pci/piix.ko
/bin/insmod -f 
/lib/modules/2.6.16-std26-up-alt5/kernel/drivers/ide/pci/generic.ko
/bin/insmod -f 
/lib/modules/2.6.16-std26-up-alt5/kernel/drivers/ide/ide-generic.ko
/bin/insmod -f 
/lib/modules/2.6.16-std26-up-alt5/kernel/drivers/ide/ide-disk.ko
/bin/insmod -f /lib/modules/2.6.16-std26-up-alt5/kernel/drivers/md/raid0.ko
/bin/insmod -f /lib/modules/2.6.16-std26-up-alt5/kernel/drivers/md/raid1.ko
/bin/insmod -f /lib/modules/2.6.16-std26-up-alt5/kernel/fs/mbcache.ko
/bin/insmod -f /lib/modules/2.6.16-std26-up-alt5/kernel/fs/jbd/jbd.ko
/bin/insmod -f /lib/modules/2.6.16-std26-up-alt5/kernel/fs/ext3/ext3.ko

/bin/mount -t proc proc /proc
/bin/mount -t tmpfs -o size=1m none /dev/mapper
/bin/mount -t tmpfs -o size=1m none /dev/system
/bin/mount -t tmpfs -o size=1m none /etc
/bin/mount -t tmpfs -o size=1m none /var

/bin/mknod -m 600 /dev/mapper/control c 10 63

/bin/raidautorun /dev/md255

cat /proc/mdstat

/bin/lvm vgscan
/bin/lvm vgchange -ay
/bin/lvm lvscan

read cmdline </proc/cmdline
cmdline=" $cmdline "
if test -z "${cmdline##*[        ]real_root=*}" ; then
     root="${cmdline##*[  ]real_root=}"
     echo "real_root param is " $root
     root_mapping=`ls -l $root | awk -F'->' '{print $2}'`
     echo "root mapping is " $root_mapping
     major=`ls -l $root_mapping | awk '{print $5}' | awk -F',' '{print $1}'`
     minor=`ls -l $root_mapping | awk '{print $6}'`
     echo "root mapping is " $root_mapping " " $major " " $minor
     echo $(( ($minor & 0xff) | ($major << 8) | (($minor & ~0xff) << 12) 
)) > /proc/sys/kernel/real-root-dev
fi

/bin/umount /var
/bin/umount /etc
/bin/umount /dev/system
/bin/umount /dev/mapper
/bin/umount /proc

Не спорю, что это не самый прямой способ, но более прямые у меня не заработали -
см. сизифовские арихивы

Но связи с тем, что у меня рут на lvm и тем, что происходит, я не вижу.

/dev/caybo/mirror -> ../dm-1 у gns меня сильно удивляет. Это без ручных
манипуляций, т.е. так отрабатывает udevd и компания?

> /dev/caybo/mirror -> ../dm-1 у gns меня сильно удивляет. Это без ручных
> манипуляций, т.е. так отрабатывает udevd и компания?

да

правда, в процессе симлинки иногда меняются: появляется postie ->
/dev/mapper/caybo-postie, но это явно делает не udev а сам lvm. есть у него
такая вредная (теперь) привычка - создавать device nodes и symlinks.

/ на lvm я никогда не делал, вечером попробую (обычно у меня типа
Disk /dev/hdd: 200.0 GB, 200049647616 bytes
255 heads, 63 sectors/track, 24321 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hdd1               1          10       80293+  83  Linux
/dev/hdd2              11         130      963900   82  Linux swap / Solaris
/dev/hdd3             131         300     1365525   fd  Linux raid autodetect
/dev/hdd4             301       24321   192948682+   5  Extended
/dev/hdd5             301       24321   192948651   fd  Linux raid autodetect
 и md0 - /, pvcreate /dev/md1).

(In reply to comment #45)
> > /dev/caybo/mirror -> ../dm-1 у gns меня сильно удивляет. Это без ручных
> > манипуляций, т.е. так отрабатывает udevd и компания?
> 
> да
> 
> правда, в процессе симлинки иногда меняются: появляется postie ->
> /dev/mapper/caybo-postie, но это явно делает не udev а сам lvm. есть у него
> такая вредная (теперь) привычка - создавать device nodes и symlinks.

да, так оно и есть: /dev/caybo/postie -> /dev/mapper/caybo-postie, но
/dev/caybo/postie -> ../dm-1 я никогда не видел

> / на lvm я никогда не делал, вечером попробую

Попробуйте. Т.к. если / не на lvm, то все происходит именно так, как вы
описываете (и lvtest -> ../dm-0 есть) :

root@test ~ # fdisk -l /dev/hda

Disk /dev/hda: 20.0 GB, 20020396032 bytes
16 heads, 63 sectors/track, 38792 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hda1               1        2031     1023592+  83  Linux
/dev/hda2            2032        3046      511560   82  Linux swap / Solaris
/dev/hda3            3047        4984      976752   8e  Linux LVM

root@test ~ # pvcreate /dev/hda3
  Physical volume "/dev/hda3" successfully created
root@test ~ # vgcreate test /dev/hda3
  Volume group "test" successfully created
root@test ~ # ls -l /dev/mapper 
total 0
lrwxrwxrwx 1 root root 16 May 25 20:12 control -> ../device-mapper
root@test ~ # ls -l /dev/test  
ls: /dev/test: No such file or directory
root@test ~ # ls -l /dev/device-mapper 
crw-rw---- 1 root root 10, 63 May 25 20:12 /dev/device-mapper
root@test ~ # lvcreate -nlvtest -L100M test
  /dev/cdrom: open failed: Read-only file system
  Logical volume "lvtest" created
root@test ~ # ls -l /dev/mapper            
total 0
lrwxrwxrwx 1 root root     16 May 25 20:12 control -> ../device-mapper
brw------- 1 root root 253, 0 May 25 20:14 test-lvtest
root@test ~ # ls -l /dev/device-mapper     
crw-rw---- 1 root root 10, 63 May 25 20:12 /dev/device-mapper
root@test ~ # ls -l /dev/mapper       
total 0
lrwxrwxrwx 1 root root     16 May 25 20:12 control -> ../device-mapper
brw------- 1 root root 253, 0 May 25 20:14 test-lvtest
root@test ~ # ls -l /dev/test              
total 0
lrwxrwxrwx 1 root root 7 May 25 20:14 lvtest -> ../dm-0
root@test ~ # service udevd restart
Stopping udevd service:                                                        
                                                       [ DONE ]
Removing udev device nodes:                                                    
                                                       [ DONE ]
Starting udevd service:                                                        
                                                       [ DONE ]
Populating /dev                                                                
                                                       [ DONE ]
root@test ~ # ls -l /dev/test      
total 0
lrwxrwxrwx 1 root root 7 May 25 20:15 lvtest -> ../dm-0

В чем тогда разница?

разница очевидно в том, создает ли ноды lvm или udev. а при загрузке Вы root=
как указываете? 

(In reply to comment #47)
> разница очевидно в том, создает ли ноды lvm или udev. а при загрузке Вы root=
> как указываете? 

А чем отличается, создает ли ноды lvm или udev?

Тогда, когда udevd опущен, ноды созданы средствами vgmknodes. Точно так же они
созданы внутри initrd. После старта udevd старое содержимое /dev, насколько я
понимаю, уничтожается, и нодами начинает заниматься udevd, а lvm по мере
возможностей вставляет ему палки в колеса ;) Но в чем разница - на lvm / или
нет? Что меняется?

В lilo.conf у меня написано:

raid-extra-boot=mbr-only
boot=/dev/md0
map=/boot/map
install=/boot/boot-bmp.b
vga=0x0311
default=linux-up
ramdisk=8192
image=/boot/vmlinuz-2.6.16-std26-up-alt5
    label=linux-up
    initrd=/boot/initrd-up
    append=" real_root=/dev/system/root"
    read-only

Как обрабатывается real_root= см. выше. Параметр root не используется, т.к. у
lilo есть привычка его уродовать. На grub не перехожу ввиду отсутствия там
raid-extra-boot

* vsu|x86_64 готовит бомбу с надписью udev-103-alt1

(In reply to comment #49)
> * vsu|x86_64 готовит бомбу с надписью udev-103-alt1

И это там не трогалось; основная цель - засунуть версию с поддержкой нового
синтаксиса (который там очередной раз поменяли).

Насколько я понимаю, при использовании startup >= 0.9.8.9-alt1 и udev >=
105-alt3 проблем быть уже не должно, если только не отключить запуск udev из
rc.sysinit. Остаётся только race между libblkid и udevd, если в fstab устройства
задаются через UUID=... или LABEL=..., но это отдельная проблема (Bug #11133).

Переносить создание симлинков /dev/$VG_NAME/$LV_NAME в udevd, на мой взгляд,
нецелесообразно - как минимум, появится race (нужно будет каким-то образом
дожидаться, когда udevd завершит обработку событий).