Я не знаю, это проблема 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 автоподнялся, том смонтировался.
(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 больше нет, закрываю.
