Bug 11282 - add every raid personality involved || fix startup
: add every raid personality involved || fix startup
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/mkinitrd)
: unstable
: all Linux
: P2 normal
Assigned To:
:
:
:
: 10804
: 9199
  Show dependency tree
 
Reported: 2007-03-31 14:52 by
Modified: 2008-01-30 23:40 (History)


Attachments
raid1 config (14.27 KB, application/x-gzip)
2007-10-24 15:30, Boris Savelev
no flags Details


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2007-03-31 14:52:25
Я не знаю, это проблема mkinitrd или startup -- зависит от того, должны ли
после
raid autorun быть подняты все md*, состоящие из разделов типа 0xfd, или
догрузка
модулей и активация всего, кроме корнесодержащего массива, входит в обязанности
startup.

При тестировании установки server-i586-20070330.iso / на raid1 встал
замечательно, а вот /home на raid0 (страйп для теста, разумеется) не
поднимается
при загрузке до монтирования локальных разделов и соответственно не монтируется
(по UUID происходит попытка монтирования его части -- неуспешная, разумеется). 
Все разделы -- 0xfd, активных после установки не было.

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

--- из письма в sisyphus@
qemu; hda = 10Gb raw; hdb = 10Gb raw

отрезал по 1024M "Linux RAID" под / на ext3 (RAID1)
остаток -- "Linux RAID" под /home на xfs (RAID0 -- только тесту
  ради, хотя и вообще было бы здорово по умолчанию выделять
  RAID1, не 0)
заодно сказал lilo встать не на hda, а на md/md0 и
raid-extra-boot выбрал "mbr-only"

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

В /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

Поправил в fstab на /dev/md1, смонтировалось; сделал
# mv /etc/mdadm.conf /etc/mdadm.conf-
# mdadm --examine --scan > /etc/mdadm.conf
# reboot
=> всё равно
Checking filesystems
fsck: cannot check /dev/md1: fsck.xfs not found

Mounting local filesystems: mount: /dev/md1: can't read superblock

Сделал
# cp -a /boot/initrd-2.6.18-ovz-smp-alt12.img
/boot/initrd-2.6.18-ovz-smp-alt12.img-orig
# mkinitrd -f --with raid0 -v /boot/initrd-2.6.18-ovz-smp-alt12.img
2.6.18-ovz-smp-alt12
# lilo
# reboot
=> при загрузке raid0 автоподнялся, том смонтировался.
------- Comment #1 From 2007-03-31 16:41:49 -------
(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 не
распознавались как отдельные ФС.
------- Comment #2 From 2007-03-31 20:39:23 -------
<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 на обоих одинаковый
------- Comment #3 From 2007-04-02 09:05:46 -------
Наверное, INVALID/WORKSFORME.  В первый раз raid0 действительно _не_
смонтировался, если получится воспроизвести -- вернусь.  Во второй раз его
опять
не было в /proc/mdstat, но смонтирован -- был.
------- Comment #4 From 2007-04-02 13:34:23 -------
У меня есть подозрение, что из-за подобного поведения evms не будет работать
корень на raid0 (если подобная конфигурация кому-то может быть нужна).

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

Вообще я не совсем понимаю, что у нас будет делаться с evms - вроде бы когда-то
решили, что evms будет использоваться в инсталяторе, но ставиться в систему по
умолчанию не будет. Судя по тому, что произошло в описанном здесь случае, это
решение кто-то изменил.
------- Comment #5 From 2007-04-02 15:30:58 -------
(In reply to comment #4)
> У меня есть подозрение, что из-за подобного поведения evms не будет работать
> корень на raid0 (если подобная конфигурация кому-то может быть нужна).
Чур-чур, ну его нафиг, с дисками-расходниками страйп под маленькое, но ценное...

> Кстати, что образуется в /etc/mdadm.conf после работы инсталятора - пишет ли он
> туда информацию о созданных массивах?
Не заметил, попробую дома вечером посмотреть.
------- Comment #6 From 2007-04-23 22:31:16 -------
Похоже, к mdadm --detail --scan (вывод информации об устройствах md, активных в
текущий момент) придётся добавить ещё mdadm --examine --scan (вывод информации
об устройствах, описанных в /etc/mdadm.conf) - в случае, когда raid0 поднят
средствами evms (т.е., через dm вместо md), mdadm --detail --scan не видит
raid0, однако mdadm --examine --scan обнаруживает массивы при условии наличия
их
описания в /etc/mdadm.conf.
------- Comment #7 From 2007-04-23 22:43:40 -------
С другой стороны, raid0, поднятый напрямую через md, мешает последующему
использованию evms (хотя при evms_activate явных ошибок не возникает,
выполнить,
например, deactivate для этого md уже не удаётся). Хотя в текущей реализации
подниматься через md будут только разделы с типом 0xfd, использование которых
вместе с evms как раз не рекомендуется.
------- Comment #8 From 2007-05-04 04:56:39 -------
fixed or invalid?
------- Comment #9 From 2007-10-11 19:12:37 -------
есть md1 (mirror) в качестве /
никак не могу загрузится.
есть ли решение по данной баге?
------- Comment #10 From 2007-10-11 19:18:35 -------
Опишите подробнее, из чего и на что как ставите.  У меня всё работает.
------- Comment #11 From 2007-10-11 20:19:51 -------
ставлю с 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
------- Comment #12 From 2007-10-21 13:18:35 -------
В 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.
------- Comment #13 From 2007-10-24 15:30:35 -------
Created an attachment (id=2236) [details]
raid1 config

создал один массив из 2 разделов. Эффект тот же. Пробовал новый mkinitrd,
безрезультатно...
------- Comment #14 From 2007-10-26 21:26:15 -------
выяснилось что инсталятор ставит не верный тип ФС на рейд. должен быть - fb
------- Comment #15 From 2007-10-26 22:14:30 -------
нет, не должен.
------- Comment #16 From 2007-10-26 23:40:17 -------
Тип 0xFD, а не fb, но не суть.
Поясняю суть проблемы:
1. Берём ALT Linux 4.0 Server, запускаем установку на машине с двумя дисками
2. Создаём по разделу на каждом диске для корневой ФС
3. Создаём RAID 1 на этих разделах
4. Ставим систему
5. Теперь если тип разделов не поставить в 0XFD, то массив не соберётся в 
initrd сам (через raid_autorun или как он там сейчас), и значит корень не 
будет найден, система не загрузится.

Могу повесить отдельную blocker-багу. Как можно было выпустить дистрибутив, 
который нельзя поставить на софтовый RAID, я ещё могу понять. Но почему до сих 
пор нет рецепта или хотя бы признания проблемы - я не понимаю.
------- Comment #17 From 2007-10-27 14:43:06 -------
что мешает указать требуемый тип при создании разделов ?
эта возможность есть.
------- Comment #18 From 2007-10-28 02:35:42 -------
(In reply to comment #7)
...
> Хотя в текущей реализации
> подниматься через md будут только разделы с типом 0xfd, использование которых
> вместе с evms как раз не рекомендуется.

  Почему?
------- Comment #19 From 2007-10-28 12:06:23 -------
(In reply to comment #18)
>   Почему?

При использовании EVMS лучше, чтобы RAID тоже поднимался через EVMS - разница в
том, что без EVMS компонентами RAID будут разделы, распознанные ядром, а с EVMS
- устройства dm, что лучше стыкуется с возможностью EVMS менять таблицу разделов
без необходимости перезагрузки (да и управление самим RAID, поднятым мимо EVMS,
потом вроде бы не совсем работает).
------- Comment #20 From 2007-10-28 13:10:20 -------
(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 -- всё это загружалось и работало.

Так что, наверное, речь идёт о чём-то другом.
------- Comment #21 From 2007-10-28 13:53:08 -------
Нечто подобное наблюдал на XEN ядрах (см.
<http://lists.altlinux.org/pipermail/devel/2007-October/065182.html> и далее по
треду).
------- Comment #22 From 2007-10-28 14:32:54 -------
В текущей реализации mkinitrd тип 0xfd обязателен для разделов, из которых
собирается RAID для /; для всех остальных ФС это не обязательно. Проблема со
старыми сборками ядер xen вызвана отсутствием в них патчей для правильного
взаимодействия драйвера md и udev, в результате root=UUID=... с ними не
работает
(объезд через root=/dev/mdX).
------- Comment #23 From 2007-10-28 14:38:53 -------
root=UUID=... не основная проблемма (темболие, что для 2.6.18-xen-dom0-alt2 она
действительно решена).

Основная -- то что без копания в сформированном initrd руками RAID1, на
разделах
отмеченных 0xfd, у меня так и неподнялся...
------- Comment #24 From 2007-10-28 14:43:00 -------
(In reply to comment #23)
...
> Основная -- то что без копания в сформированном initrd руками RAID1, на разделах
> отмеченных 0xfd, у меня так и неподнялся...

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

------- Comment #25 From 2007-10-31 03:53:27 -------
В #9958 я доработал старый патч поднимающий EVMS из initrd. На XEN ядрах (в
комбинации с grub) он работает вполне надёжно. (В смысле: на двух хостах глюков
с ним пока не словил.)
------- Comment #26 From 2007-11-01 20:28:59 -------
(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.
------- Comment #27 From 2007-11-01 21:48:40 -------
(In reply to comment #19)
> При использовании EVMS лучше, чтобы RAID тоже поднимался через EVMS - разница в
> том, что без EVMS компонентами RAID будут разделы, распознанные ядром, а с EVMS
> - устройства dm, что лучше стыкуется с возможностью EVMS [...]
Зато вовсю вылазит проблема "несколько кусочков разных md на одном шпинделе":
ядро при этом не откладывает синхронизацию массивов таким образом, чтобы не
выскакивать на сплошной seek.  Кажется, бага про это не висит, но пока помню --
может, будем просто стопать все райды, кроме корневого, если есть?  Загрузится
-- отсинкается уже соображая, что где...
------- Comment #28 From 2007-11-01 23:07:56 -------
> >Но почему до сих пор нет рецепта или хотя бы признания проблемы - 
> >я не понимаю.
> Потому что проблема, как ни редко я такое говорю -- в /dev/hands.
Да нет, очередная грабелька из серии raw data для CUPS или update_chrooted conf 
для ping.
Ну и интерфейс конфигурирования в стиле консоли - оператор должен знать 
заранее, какую команду вводить, и программа ему не подскажет.

А сказать что у троих людей руки кривые что они 2 недели ставили систему на 
RAID... Я вот могу RAID руками сделать, так что же у меня не получилось через 
инсталлятор? Руки для инсталлятора кривые?
Наверное от таких дружелюбных программ установки и появляются статьи типа
http://www.freesource.info/wiki/AltLinux/Sisyphus/admin/CreateMdRAID1onLiveSystem
:) проще и понятнее сделать всё самому...
------- Comment #29 From 2007-11-01 23:45:19 -------
(In reply to comment #28)
> Да нет, очередная грабелька из серии raw data для CUPS или update_chrooted conf 
> для ping.
Нет.  Там гайки перекручены.  А тут гаек просто нет.  Причём не только в ALT.

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

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

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

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

Пока из относительно реализабельных идеальных частных случаев -- только
предложение создавать полные зеркала разделов, если видим 2 (два) одинаковых
диска.  И то не возьмусь алгоритмически описать, как это вижу.
------- Comment #30 From 2007-11-01 23:52:07 -------
http://heap.altlinux.org/modules/alterator_vm/index.html
спорить не о чем.
------- Comment #31 From 2007-11-02 01:24:32 -------
(In reply to comment #30)
> http://heap.altlinux.org/modules/alterator_vm/index.html
> спорить не о чем.
> 
:) О, спасибо огромное.

P.S. Миша, ну вот так всё получилось. Как всегда хотелось быстрее и без 
проблем.
P.P.S.
Прошу прощения, если создал лишний шум.
Будет что конструктивное по ТЗ - проявлюсь.
------- Comment #32 From 2008-01-26 02:20:55 -------
Поскольку жалоб на mkinitrd по поводу raid больше нет, закрываю.