ALT Linux Bugzilla – #11282

(In reply to comment #0)
> Я не знаю, это проблема mkinitrd или startup -- зависит от того,
> должны ли после raid autorun быть подняты все md*, состоящие из
> разделов типа 0xfd, или догрузка модулей и активация всего,
> кроме корнесодержащего массива, входит в обязанности startup.

Сейчас в initrd делается попытка поднять всё, что лежит в разделах
с типом 0xfd, однако в startup следовало бы запускать то, что по
каким-то причинам осталось незапущенным - и вроде бы там это
делается (по крайней мере, у меня поднятие raid через mdadm
работало довольно давно, независимо от того, срабатывало ли оно в
initrd).

> Может, класть все наблюдающиеся на момент mkinitrd raid
> personalities?

В настоящий момент mkinitrd делает именно это:

ListRaidLevelsFromMdadm()
{
	$MDADM --detail --scan 2>/dev/null | \
		sed -ne 's/^.* level=\([^ ]*\) .*$/\1/p' |
		sed -e 's/^raid\([0-9]*\)$/\1/'
}

> => в процессе загрузки попытались смонтировать по UUID не
> /dev/evms/md/md0, а /dev/hda2 и суперблока там не нашли.

Если в системе установлен evms, предполагается, что он и должен
поднимать raid и всё прочее - запуск raid и lvm в этом случае уже
не производится.  Чтобы при загрузке вызывался именно mdadm,
необходимо либо удалить пакет evms, либо загрузить систему с
опцией noevms.

> В /dev/ и /dev/evms/md/ наличествовали md[01], но в /proc/mdstat 
> -- только md0 (присмотрелся -- md1 не поднимается по причине
> отсутствующего в initramfs raid0.ko).  Ручная сборка прошла успешно:
> 
> # mdadm --assemble /dev/md1 /dev/hd[ab]2
> => появилось в /proc/mdstat)
> 
> но монтироваться по UUID всё равно отказываемся:
> # mount /home
> mount: /dev/hda2 already mounted or /home busy

А вот это, возможно, проблемы libblkid.  В libvolume_id из udev,
используемой в /lib/udev/vol_id, проверка суперблоков raid стоит
раньше проверки суперблоков обычных ФС, чтобы компоненты raid не
распознавались как отдельные ФС.

<gvy> vsu, re #11282: странно, снёс всё нафиг вместе с lvm, повесил / на зеркало
и /var/cache/squid на страйп -- нормально поднимается, хотя и не из initrd
<gvy> но в /proc/mdstat этого /dev/dm-2 нет (md2, по идее -- md0 был остатками
предыдущего раза, то ли недостопленными, то ли ещё чего)
<vsu> gvy: а страйп через lvm сделан?
<gvy> ну я-то думал, что evms/mdadm/raidtools дёргают одни и те же ручки в ядре
<gvy> vsu, не, просто raid0
<vsu> gvy: хм, интересно
<vsu> gvy: получается, что evms ухитряется поднимать именно raid0 через dm?
<vsu> gvy: /lib/udev/vol_id с компонентов этого страйпа что показывает?
<gvy> vsu, FS_TYPE=linux_raid_member
<gvy> vsu, FS_VERSION=0.90.0
<gvy> а, ID_FS_USAGE=raid
<gvy> ещё UUID
<gvy> LABEL и LABEL_SAFE пустые
<gvy> UUID на обоих одинаковый

Наверное, INVALID/WORKSFORME.  В первый раз raid0 действительно _не_
смонтировался, если получится воспроизвести -- вернусь.  Во второй раз его опять
не было в /proc/mdstat, но смонтирован -- был.

У меня есть подозрение, что из-за подобного поведения evms не будет работать
корень на raid0 (если подобная конфигурация кому-то может быть нужна).

Кстати, что образуется в /etc/mdadm.conf после работы инсталятора - пишет ли он
туда информацию о созданных массивах?

Вообще я не совсем понимаю, что у нас будет делаться с evms - вроде бы когда-то
решили, что evms будет использоваться в инсталяторе, но ставиться в систему по
умолчанию не будет. Судя по тому, что произошло в описанном здесь случае, это
решение кто-то изменил.

(In reply to comment #4)
> У меня есть подозрение, что из-за подобного поведения evms не будет работать
> корень на raid0 (если подобная конфигурация кому-то может быть нужна).
Чур-чур, ну его нафиг, с дисками-расходниками страйп под маленькое, но ценное...

> Кстати, что образуется в /etc/mdadm.conf после работы инсталятора - пишет ли он
> туда информацию о созданных массивах?
Не заметил, попробую дома вечером посмотреть.

Похоже, к mdadm --detail --scan (вывод информации об устройствах md, активных в
текущий момент) придётся добавить ещё mdadm --examine --scan (вывод информации
об устройствах, описанных в /etc/mdadm.conf) - в случае, когда raid0 поднят
средствами evms (т.е., через dm вместо md), mdadm --detail --scan не видит
raid0, однако mdadm --examine --scan обнаруживает массивы при условии наличия их
описания в /etc/mdadm.conf.

С другой стороны, raid0, поднятый напрямую через md, мешает последующему
использованию evms (хотя при evms_activate явных ошибок не возникает, выполнить,
например, deactivate для этого md уже не удаётся). Хотя в текущей реализации
подниматься через md будут только разделы с типом 0xfd, использование которых
вместе с evms как раз не рекомендуется.

fixed or invalid?

есть md1 (mirror) в качестве /
никак не могу загрузится.
есть ли решение по данной баге?

Опишите подробнее, из чего и на что как ставите.  У меня всё работает.

ставлю с CD altlinux server 4.0 коробочная версия
на 2 сата винта сигейт 80 гб.
размечаю sda:
sda1 2048М
sda2 5000M
sda3 73000M
sdb идентично.

Создаю соответственно 3 рейда
md0 swap
md1 root{/}
md2 LVM{usr,var}

cat lilo.conf
vga="0x314"
lba32
prompt
default="ALTLinux"
raid-extra-boot="mbr-only"
boot="/dev/md1"
map="/boot/map"
timeout="100"
install="menu"
append="panic=30"

image="/boot/vmlinuz"
        label="ALTLinux"
        initrd="/boot/initrd.img"
        root=/dev/md1
        read-only

image="/boot/vmlinuz"
        label="failsafe"
        initrd="/boot/initrd.img"
        root=/dev/md1
        addappend="failsafe"
        vga="normal"
        read-only

image="/boot/vmlinuz-2.6.18-ovz-smp-alt14"
        initrd="/boot/initrd-2.6.18-ovz-smp-alt14.img"
        label="2618-ovz-smp-14"
        root=/dev/md1
        read-only
        optional

image="/boot/vmlinuz-2.6.18-std-smp-alt6"
        initrd="/boot/initrd-2.6.18-std-smp-alt6.img"
        label="2618-std-smp-6"
        root=/dev/md1
        read-only
        optional

В mkinitrd-3.0.5-alt1 добавлен вызов mdadm --examine --scan, который должен
помочь в случае, если RAID в момент вызова mkinitrd был поднят через EVMS, но
при этом описания всех нужных массивов были добавлены в /etc/mdadm.conf.

(In reply to comment #11)
> ставлю с CD altlinux server 4.0 коробочная версия
На вид всё правильно - стоит ещё посмотреть, что получилось в /etc/mdadm.conf.

Created attachment 2236 [details]
raid1 config

создал один массив из 2 разделов. Эффект тот же. Пробовал новый mkinitrd,
безрезультатно...

выяснилось что инсталятор ставит не верный тип ФС на рейд. должен быть - fb

нет, не должен.

Тип 0xFD, а не fb, но не суть.
Поясняю суть проблемы:
1. Берём ALT Linux 4.0 Server, запускаем установку на машине с двумя дисками
2. Создаём по разделу на каждом диске для корневой ФС
3. Создаём RAID 1 на этих разделах
4. Ставим систему
5. Теперь если тип разделов не поставить в 0XFD, то массив не соберётся в 
initrd сам (через raid_autorun или как он там сейчас), и значит корень не 
будет найден, система не загрузится.

Могу повесить отдельную blocker-багу. Как можно было выпустить дистрибутив, 
который нельзя поставить на софтовый RAID, я ещё могу понять. Но почему до сих 
пор нет рецепта или хотя бы признания проблемы - я не понимаю.

что мешает указать требуемый тип при создании разделов ?
эта возможность есть.

(In reply to comment #7)
...
> Хотя в текущей реализации
> подниматься через md будут только разделы с типом 0xfd, использование которых
> вместе с evms как раз не рекомендуется.

  Почему?

(In reply to comment #18)
>   Почему?

При использовании EVMS лучше, чтобы RAID тоже поднимался через EVMS - разница в
том, что без EVMS компонентами RAID будут разделы, распознанные ядром, а с EVMS
- устройства dm, что лучше стыкуется с возможностью EVMS менять таблицу разделов
без необходимости перезагрузки (да и управление самим RAID, поднятым мимо EVMS,
потом вроде бы не совсем работает).

(In reply to comment #16)
> Тип 0xFD, а не fb, но не суть.
> Поясняю суть проблемы:
> 1. Берём ALT Linux 4.0 Server, запускаем установку на машине с двумя дисками
> 2. Создаём по разделу на каждом диске для корневой ФС
> 3. Создаём RAID 1 на этих разделах
> 4. Ставим систему
> 5. Теперь если тип разделов не поставить в 0XFD, то массив не соберётся в 
> initrd сам (через raid_autorun или как он там сейчас), и значит корень не 
> будет найден, система не загрузится.
> 
> Могу повесить отдельную blocker-багу. Как можно было выпустить дистрибутив, 
> который нельзя поставить на софтовый RAID, я ещё могу понять. Но почему до сих 
> пор нет рецепта или хотя бы признания проблемы - я не понимаю.
> 

Не наблюдал ни одной из вышеперечисленных проблем.
Я сам ставил 4.0/Server на raid1 штатными средствами, и создавал /home на raid1
без 0xfd -- всё это загружалось и работало.

Так что, наверное, речь идёт о чём-то другом.

Нечто подобное наблюдал на XEN ядрах (см.
<http://lists.altlinux.org/pipermail/devel/2007-October/065182.html> и далее по
треду).

В текущей реализации mkinitrd тип 0xfd обязателен для разделов, из которых
собирается RAID для /; для всех остальных ФС это не обязательно. Проблема со
старыми сборками ядер xen вызвана отсутствием в них патчей для правильного
взаимодействия драйвера md и udev, в результате root=UUID=... с ними не работает
(объезд через root=/dev/mdX).

root=UUID=... не основная проблемма (темболие, что для 2.6.18-xen-dom0-alt2 она
действительно решена).

Основная -- то что без копания в сформированном initrd руками RAID1, на разделах
отмеченных 0xfd, у меня так и неподнялся...

(In reply to comment #23)
...
> Основная -- то что без копания в сформированном initrd руками RAID1, на разделах
> отмеченных 0xfd, у меня так и неподнялся...

  При использовании initramfs (остальное не проверял).

В #9958 я доработал старый патч поднимающий EVMS из initrd. На XEN ядрах (в
комбинации с grub) он работает вполне надёжно. (В смысле: на двух хостах глюков
с ним пока не словил.)

(In reply to comment #16)
> Тип 0xFD, а не fb, но не суть.
Но показательно...

> Поясняю суть проблемы:
> 1. Берём ALT Linux 4.0 Server, запускаем установку на машине с двумя дисками
> 2. Создаём по разделу на каждом диске для корневой ФС
> 3. Создаём RAID 1 на этих разделах
К этому моменту человек или обязан знать про то, как в линуксе собирается
софтрейд (включая тип разделов), или инструмент обязан уметь прятать эти
подробности от человека.  В данном случае инструмент умеет только сказать "Linux
RAID"; более другие варианты предлагались (e.g. #11289), но мне неизвестны
вообще хоть где-то реализации, которые бы можно было указать как образец (AW не
в счёт, там своя специфика была).

Пока сборка рейдов под линуксом -- область, где эти нюансы приходится знать.

> 4. Ставим систему
> 5. Теперь если тип разделов не поставить в 0XFD, то массив не соберётся в 
> initrd сам (через raid_autorun или как он там сейчас), и значит корень не 
> будет найден, система не загрузится.
Это верно только для корня AFAIK.

> Могу повесить отдельную blocker-багу. Как можно было выпустить дистрибутив, 
> который нельзя поставить на софтовый RAID, я ещё могу понять.
Ещё как можно, чем регулярно и пользуюсь.  Хотя с cfq это в некоторых ситуациях
требует ещё более сокровенных знаний о том, как остановить конкурентную
синхронизацию массивов "на dm-*" (которые на одних шпинделях на деле) :-/

>Но почему до сих пор нет рецепта или хотя бы признания проблемы - 
>я не понимаю.
Потому что проблема, как ни редко я такое говорю -- в /dev/hands.

(In reply to comment #19)
> При использовании EVMS лучше, чтобы RAID тоже поднимался через EVMS - разница в
> том, что без EVMS компонентами RAID будут разделы, распознанные ядром, а с EVMS
> - устройства dm, что лучше стыкуется с возможностью EVMS [...]
Зато вовсю вылазит проблема "несколько кусочков разных md на одном шпинделе":
ядро при этом не откладывает синхронизацию массивов таким образом, чтобы не
выскакивать на сплошной seek.  Кажется, бага про это не висит, но пока помню --
может, будем просто стопать все райды, кроме корневого, если есть?  Загрузится
-- отсинкается уже соображая, что где...

> >Но почему до сих пор нет рецепта или хотя бы признания проблемы - 
> >я не понимаю.
> Потому что проблема, как ни редко я такое говорю -- в /dev/hands.
Да нет, очередная грабелька из серии raw data для CUPS или update_chrooted conf 
для ping.
Ну и интерфейс конфигурирования в стиле консоли - оператор должен знать 
заранее, какую команду вводить, и программа ему не подскажет.

А сказать что у троих людей руки кривые что они 2 недели ставили систему на 
RAID... Я вот могу RAID руками сделать, так что же у меня не получилось через 
инсталлятор? Руки для инсталлятора кривые?
Наверное от таких дружелюбных программ установки и появляются статьи типа
http://www.freesource.info/wiki/AltLinux/Sisyphus/admin/CreateMdRAID1onLiveSystem
:) проще и понятнее сделать всё самому...

(In reply to comment #28)
> Да нет, очередная грабелька из серии raw data для CUPS или update_chrooted conf 
> для ping.
Нет.  Там гайки перекручены.  А тут гаек просто нет.  Причём не только в ALT.

> Ну и интерфейс конфигурирования в стиле консоли - оператор должен знать 
> заранее, какую команду вводить, и программа ему не подскажет.
Да, увы.

> А сказать что у троих людей руки кривые что они 2 недели ставили систему на 
> RAID...
Спросить в жабере не мог?  Я ж регулярно отчёты пишу, в т.ч. и по системам с
софтрейдом. (письмо Бориса видел и до сих пор в inbox лежит -- как раз на
подготовку ALTSP и конференции пришлось)

> Я вот могу RAID руками сделать, так что же у меня не получилось через 
> инсталлятор? Руки для инсталлятора кривые?
Нет.  Просто ты, имея достаточно знаний, или не применил их, или понадеялся на
машину.  А она ещё не умеет того, что от неё можно хотеть.

> Наверное от таких дружелюбных программ установки
Виталик, если сможешь нарисовать разумное ТЗ -- думаю, уже за это будут
благодарны при работах по 4.1.  Я вот точно буду благодарен, поскольку в
процессе работ по alterator-vm не раз переписывались с Сержем по части
автоматизации рейдовой установки -- и я, с одной стороны, понимаю, сколько
примерно добавляется сложности и проблем реализации, с другой -- не могу даже
внятно изложить, какой бы был идеальный вариант для меня.

Пока из относительно реализабельных идеальных частных случаев -- только
предложение создавать полные зеркала разделов, если видим 2 (два) одинаковых
диска.  И то не возьмусь алгоритмически описать, как это вижу.

http://heap.altlinux.org/modules/alterator_vm/index.html
спорить не о чем.

(In reply to comment #30)
> http://heap.altlinux.org/modules/alterator_vm/index.html
> спорить не о чем.
> 
:) О, спасибо огромное.

P.S. Миша, ну вот так всё получилось. Как всегда хотелось быстрее и без 
проблем.
P.P.S.
Прошу прощения, если создал лишний шум.
Будет что конструктивное по ТЗ - проявлюсь.

Поскольку жалоб на mkinitrd по поводу raid больше нет, закрываю.