udevd стартует после активации LVM, из-за чего созданные LVM устройства стаановятся недоступны.
решение: --- 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 завершит обработку событий).
