/dev/md0 (/boot) - 16M /dev/md1 (/) - 667M /dev/md3 (/var/lib/vz) - LVM При загрузке fsck вываливается с руганью на /dev/.dev-253-0 (или что-то в этом роде). Вылечилось банальным sleep 3 после поднятия LVM. P.S. Возможно этот баг стОит перевесить на более подходящий пакет. 23:32 <raorn> vsu: после старта LVM у меня чекалка не нашла /dev/mapper/storage-OpenVZ AKA /dev/dm-3 AKA /dev/.dev-253-0 23:32 <vsu> raorn: и на каком основании не нашла? 23:33 <raorn> vsu: /dev/.dev-253-0 23:33 <raorn> vsu: вставил тупо sleep 3 после активации LVM и завелось 23:33 <vsu> raorn: не понял, оно что, его так обозвало? 23:34 <raorn> ну udeff наверно сначала левый файл создаёт 23:34 <raorn> а потом его переименовывает 23:34 <raorn> вот и race 23:34 <raorn> остальные разделы ма-а-а-а-аленькие 23:34 <raorn> быстро прочекались 23:34 <vsu> raorn: так при чём тут udeff? lvm же вроде сам своими кривыми лапами в /dev лезет 23:35 <raorn> vsu: а udeff видимо dm-3 в этот момент создавал 23:35 <raorn> который по UUID находился первым 23:35 <vsu> raorn: ну и? он его в /dev создаёт, а /dev/mapper вообще не трогает 23:36 <vsu> raorn: в /dev/disk/by-uuid/* получаются симлинки в /dev/dm-* 23:36 <vsu> raorn: а в /dev/mapper/* файлы устройств отдельно лежат 23:36 <raorn> vsu: brw-r----- 1 root disk 253, 0 Mar 16 22:58 /dev/dm-0 23:36 <vsu> raorn: ну да, это udeff 23:36 <raorn> и подмонтирован у меня именно /dev/dm-0 23:37 <vsu> raorn: хм... а ты его как в fstab указал? 23:37 <raorn> /dev/mapper/storage-OpenVZ тоже есть 23:37 <raorn> vsu: по UUID 23:37 <vsu> а... 23:37 <vsu> тогда понятно 23:38 <raorn> во-о-о-от 23:38 <vsu> вот если писать /dev/mapper/storage-OpenVZ, будет работать 23:38 <vsu> правда, в df получится лажа 23:38 <raorn> дык инсталлер создал 23:38 <vsu> точнее, не совсем 23:39 <vsu> если написать /dev/storage/OpenVZ, df всё равно будет писать /dev/mapper/storage-OpenVZ 23:39 <vsu> хотя в /proc/mounts при этом будет /dev/storage/OpenVZ 23:39 <vsu> а вот в mtab эти симлинки раскрываются 23:42 * lioka в /proc/mounts имеет и /dev/vg/vat и /dev/dm-* для lv 23:42 <vsu> raorn: вообще не совсем понятно, что с этим делать 23:42 <raorn> в общем я сегодня-завтра развешаю багов и отпишу в рассылку 23:42 <vsu> lioka: а в fstab это в виде UUID=.... ? 23:43 <lioka> vsu: нет, LABEL, что в общем одно и тожк 23:43 <vsu> ну да, вид сбоку 23:43 <lioka> те, что dm-* -- создавались во время этого uptime 23:43 <vsu> тогда это к libblkid или как ещё называется та жопа, через которую сделан поиск 23:44 <vsu> видимо, что первое попалось, то и цепляется
/dev/.dev-253-0 - это файл устройства, временно создаваемый udevd в процессе обработки событий (например, для передачи vol_id, когда окончательное имя устройства ещё не определено). Вероятно, проблема в том, что библиотека libblkid, используемая для поиска устройств в случае, если в fstab задано UUID=... или LABEL=..., перебирает все файлы устройств в /dev в поисках подходящего, и в некоторых случаях может получить такой временный файл устройства, созданный udevd. Один из вариантов обхода проблемы - модифицировать libblkid, чтобы скрытые файлы (.*) там игнорировались (кстати, в /dev ещё может быть каталог /dev/evms/.nodes, устройства из которого тоже использовать нежелательно). Хотя это не спасает от неоднозначности - при использовании lvm устройства dm присутствуют в /dev в двух экземплярах (/dev/dm-$NUMBER и симлинки на них, создаваемые udevd, и /dev/mapper/$VG_NAME-$LV_NAME и симлинки /dev/$VG_NAME/$LV_NAME, создаваемые lvm), и libblkid использует один из этих вариантов фактически случайным образом. Впрочем, фатальных проблем это не вызывает, но вывод команд mount и df становится некрасивым. Если указывать тома lvm в fstab не через UUID=... или LABEL=..., а в виде /dev/$VG_NAME/$LV_NAME, подобные проблемы возникать не должны. Возможно, в инсталяторе при использовании lvm стоит заполнять fstab именно таким образом.
Я соберу libblkid с поддержкой libdevmapper, это должно решить проблему.
Should be fixed in 1.39-alt3. Please reopen if not.
Похоже, что всё в порядке: /dev/dm-1 on /home type ext3 (rw,nosuid) /dev/mapper/storage-usr on /usr type ext3 (rw,nodev,noatime) /dev/dm-2 on /var type ext3 (rw,nosuid) Раньше падало, видимо, на создании /dev/dm-* для /usr
Но /dev/dm-* и /dev/mapper/* всё равно цепляются случайным образом?
Думаю, приоритет у dm-*, но для /usr этот dm-* ещё не создан udev'ом.
