LINUX.ORG.RU
ФорумAdmin

[gentoo] Странность с LVM и udev(?)

 


0

0

Имеется домашний сервер. На нём стоит Gentoo x86 (стабильная ветка). Все разделы на LVM/RAID1 (кроме /boot, который просто на RAID1). LVM VG - homeserver, LVM LV - swap, root, home, srv.

Вчера ночью он внезапно капитально завис по неизвестным причинам (скорее всего - обычный глюк старого дешёвого железа), но не в этом суть. После ресета он не запустился с руганью на неправильный суперблок на разделе /dev/homeserver/root. Самое интересное в том, что система тут же предложила зайти в рутовую однопользовательскую консоль, но не в busybox, а в нормальную. Т.е. / всё-таки примонтировался и система была почти нормальной (не примонтировались /home и /srv). Дальнейшее ковыряние показало, что после запуска файлы устройств LVM LV /dev/mapper/homeserver-* существуют, а /dev/homeserver/* - нет! Решить проблему помогла замена /dev/homeserver/ на /dev/mapper/homeserver- в /etc/fstab. Причём скрипты из genkernel'овского initrd нормально создают девайсы /dev/homeserver/*, так что в конфиге grub'а я оставил real_root=/dev/homeserver/root и всё работает...

А теперь вопрос: это нормальное поведение или глюк? Писать ли в багзиллу? Появилось предположительно после одного из последних обновлений udev. ИМХО он не создаёт все файлы девайсов сразу после запуска, но создаёт их чуть позже. И кстати, вроде же использовать /dev/mapper/* не рекомендуется или я ошибаюсь?

P.S. Для любителей читать по диагонали: 1) Я разобрался в чём проблема; 2) Я нашёл workaround для этой проблемы и 3) Меня интересует именно ответы на мои вопросы =).

Deleted

Когда последний раз обновлял мир, не полностью обновился. Сейчас, новым udev, сносится dev-mapper, т.к. оный функционал теперь в udev.

Короче, грузись с livecd, делай chroot и делай нормальное обновление мира. Сейчас так:

sys-fs/udev-146-r1
sys-fs/lvm2-2.02.51-r1

sys-fs/device-mapper - больше не нужен (он блокировать будет обновление udev).

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

Когда последний раз обновлял мир, не полностью обновился. Сейчас, новым udev, сносится dev-mapper, т.к. оный функционал теперь в udev.

Короче, грузись с livecd, делай chroot и делай нормальное обновление мира. Сейчас так:

sys-fs/udev-146-r1

sys-fs/lvm2-2.02.51-r1

sys-fs/device-mapper - больше не нужен (он блокировать будет обновление udev).

Стоят именно эти версии udev и lvm2, а проблему с блокировкой я как раз решал при последнем обновлении. В любом случае, когда досинхронизируются RAID'ы, попробую обновиться и пересобрать udev с lvm2. Может действительно что-то недообновилось...

Deleted
()
Ответ на: комментарий от Deleted

Ну, странно тогда. У меня машина с lvm2 после последних апдейтов перегружалась без проблем. Хотя, обновив систему не полностью перед этим именно на такие грабли наступил. Но вылечил, загрузившись с livecd и обновив мир.

KRoN73 ★★★★★
()

Так ведь реальные девайсы как раз в /dev/mapper/, а в /dev/$VGname/ софт-линки на эти девайсы.

Или что-то в распоследних (>2.6.30) ядрах/udev поменяли?

sdio ★★★★★
()
Ответ на: комментарий от sdio

Так ведь реальные девайсы как раз в /dev/mapper/, а в /dev/$VGname/ софт-линки на эти девайсы.

Да, там симлинки. ЕМНИП во всех прочитанных мной руководствах по LVM рекомендовалось использовать только /dev/$VGname/$LVname, а содержимое /dev/mapper якобы трогать лучше не надо. Причины этого мне неизвестны.

Deleted
()

Пересборка udev не помогает вообще. Хотя при сборке он выдавал сообщение о том, что в конфиге ядра нужно выключить CONFIG_SYSFS_DEPRECATED_V2, иначе может работать неправильно. Пересборка ядра с выключенной этой опцией приводит к тому, что inird просто не видит LVM =\. У меня такое ощущение, что я натыкаюсь на два варианта: 1) Работает LVM в initrd, и неправильно работает в остальной системе, и 2) LVM не работает в initrd, но по идее должен нормально работать в остальной системе. О_о

В общем пока оставляю всё как есть (на костылях), остальные эксперименты откладываю на выходные...

Deleted
()
Ответ на: комментарий от KRoN73

KRoN73, а у тебя корень тоже на LVM? Можешь выложить куда-нибудь конфиг своего ядра (если есть для x86) и сказать как собираешь initrd?

Deleted
()
Ответ на: комментарий от Deleted

>KRoN73, а у тебя корень тоже на LVM?

Угу.

>Можешь выложить куда-нибудь конфиг своего ядра (если есть для x86)


http://pastebin.ca/1684600

>и сказать как собираешь initrd?


genkernel --splash=livecd-2007.0 --menuconfig all

:)

/etc/genkernel.conf, соответственно, вот: /etc/genkernel.conf

KRoN73 ★★★★★
()
Ответ на: комментарий от anonymous

А чем вы с RAID1 грузитесь? Разве старый grub так умеет?

initrd на отдельном /boot под ext2, а остальное - уже где угодно и как угодно :)

# mount|grep root
rootfs on / type rootfs (rw)
/dev/vgs/root on / type ext4 (rw,noatime,barrier=0,data=ordered)

KRoN73 ★★★★★
()
Ответ на: комментарий от anonymous

Части линуксового софтверного RAID1 по отдельности являются почти обычными разделами. У меня /boot на RAID1 и в grub.conf два пункта - по одному на каждую половинку RAID'а.

Deleted
()

Кажется я разобрался в проблеме. Точнее в проблемах, т.к. их две.

Всё нижеописанное относится к стабильной системе Gentoo x86 на данный момент:

  • sys-kernel/gentoo-sources-2.6.31-r6
  • sys-fs/udev-146-r1
  • sys-fs/lvm2-2.02.51-r1
  • sys-kernel/genkernel-3.4.10.904

Первая проблема: система из initramfs, сгенерированного genkernel'ом, не может найти и собрать группу томов LVM. Когда в конфиге ядра выключена опция CONFIG_SYSFS_DEPRECATED_V2, в /sys не создаются некоторые устаревшие симлинки, плюс немного меняется структура директорий. Но утилиты lvm, которые идут в поставке genkernel'а, ожидают именно устаревшую структуру /sys, и новая их вводит в ступор. Возможных решения у этой проблемы три:

  • (самое простое) Собрать системный sys-fs/lvm2 с USE-флагом «static» и обновить sys-kernel/genkernel до >=3.4.10.905. Начиная с версии 3.4.10.905 genkernel использует системный статически собранный бинарник lvm, если он есть, вместо своего собственного. Естественно, после обновления надо пересобрать ядро новым genkernel'ом.
  • Обновить версии device-mapper и lvm, которые genkernel собирает для initramfs. За это отвечают настройки DEVICE_MAPPER_VER и LVM_VER в /etc/genkernel.conf.
  • (лучше так не делать) Включить CONFIG_SYSFS_DEPRECATED_V2 в конфиге ядра. Нынешний стабильный udev при запуске выдаёт варнинг, что с этой опцией он может работать некорректно, но тем не менее работает. Есть немаленький риск, что после очередного обновления udev всё сломается.

Вторая проблема: при запуске основной системы (после initramfs) udev не создаёт симлинки /dev/$VG_NAME/$LV_NAME, хотя девайсы /dev/mapper/$VG_NAME-$LV_NAME существуют. Буквально через несколько секунд эти симлинки всё же создаются. Из-за этой проблемы, все ФС на логических томах, указанные в /etc/fstab в виде /dev/$VG_NAME/$LV_NAME, не смогут примонтироваться. Решения два:

  • Заменить в /etc/fstab /dev/$VG_NAME/$LV_NAME на /dev/mapper/$VG_NAME-$LV_NAME. Это не рекомендуется, т.к. содержимое /dev/mapper по идее предназначено только для внутреннего использования утилитами lvm.
  • Добавить vgmknodes --ignorelockingfailure в скрипт /etc/init.d/udev. Этот вайриант найден в багзилле (см. ссылки ниже) и я его не пробовал.

Gentoo Bugzilla: #255196, #225249, #292833

Deleted
()
Ответ на: комментарий от Deleted

Тоже что-ли поворчать на тему «гента уже не слоёный пирожок»? =)

Deleted
()
Ответ на: комментарий от Deleted

На то оно и без бубнов, чтобы работало само :) Точнее - не знаю :)

KRoN73 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.