Bug 29554

Created attachment 5986 [details]
`mdadm -Evv --scan`

PS: отключение sdb помогло, разумеется.  Образ могу предоставить.

Мне кажется, это просто разновидность Bug 29473, просто вылезло раньше, чем в моём случае.

(In reply to comment #0)

> поскольку ситуация не то чтобы редчайшая,

Добавлю ссылку на третий случай, до кучи (тема там неправильная, но оно о том же):
http://lists.altlinux.org/pipermail/community/2013-October/680663.html

(В ответ на комментарий №2)
> Мне кажется, это просто разновидность Bug 29473
Возможно, но тут в первую очередь нужен evms-engine.log.

(В ответ на комментарий №3)
> Добавлю ссылку на третий случай
Нет, там явно про поддержку ядром: dmraid у нас нет и пока не предвидится.

(In reply to comment #4)

> Нет, там явно про поддержку ядром: dmraid у нас нет и пока не предвидится.

Нет. Там тот же контроллер, что и у меня на Intel S2600GZ. И те же два режима (LSI/RST), один из которых хочет megasr.ko, а установка во втором, с isci.ko, обламывается в какой-то момент. Вот то, что обламывается точно так у меня, это да, из той ветки не следует. Но советы, как я понимаю, помогли. :-)

(In reply to comment #4)

> Нет, там явно про поддержку ядром: dmraid

А если речь про Intel Matrix, который, якобы, формируется в режиме RST, то на сайте Intel написано, что mdadm это тоже умеет:
http://www.intel.com/support/chipsets/imsm/sb/CS-020663.htm

(В ответ на комментарий №1)
> Образ могу предоставить.

Было бы здорово, жду ссылку

(В ответ на комментарий №7)
> Было бы здорово, жду ссылку
.vdi удобно или лучше .raw?

http://fly.osdn.org.ua/~mike/tmp/grub2raid1test.vdi.gz [642M]

УМВР. Да, он нашёл какой то raid и обозвал его md127. Удаление и разбивка прошла успешна

(В ответ на комментарий №9)
> УМВР. Да, он нашёл какой то raid и обозвал его md127. Удаление и разбивка
> прошла успешна

Образ: kdesktop на сизифе

(В ответ на комментарий №9)
> УМВР. Да, он нашёл какой то raid и обозвал его md127.
А у меня его не было видно (как и дисков).  Экспортировал виртуалку целиком: http://fly.osdn.org.ua/~mike/tmp/test.ova

(В ответ на комментарий №10)
> Образ: kdesktop на сизифе
А у меня это был сегодняшний из http://nightly.altlinux.org/sisyphus/snapshots/ (завтра этот RC будет заменён типа релизным 20131106), конкретно regular-cinnamon-20131105-i586.iso, но это не должно быть столь существенным -- mdadm и компания там есть.

Предположение такое: до запуска инсталлятора, mdadm собрал raid'ы и не даёт evms ими управлять. В образе kdesktop отсутствуют утилиты mdadm и lvm (в инсталляторе)

ещё в kdesktop не используется remount_chroot()

(В ответ на комментарий №12)
> Предположение такое: до запуска инсталлятора, mdadm собрал raid'ы и не даёт
> evms ими управлять.
Как объезд, можно их все (либо выше некоторого предела, либо от 127 вниз до "дырки" в нумерации) тормозить перед запуском /vm.  Всё-таки иметь под рукой mdadm в серверном инсталяторе бывает удобно, да и в инсталируемых livecd нужен.

Ещё неясно, в чём разница с тем случаем, когда массив уже создан и с ним вполне нормально получается работать при разбивке (могу экспортировать и такое состояние, когда тестировал grub -- многократно проводил такие установки).

(В ответ на комментарий №13)
> ещё в kdesktop не используется remount_chroot()
Вообще-то installer-scripts-remount-stage2 используется в alterator-preinstall и alterator-livecd.  Если требуется документация помимо %description, хорошо бы уточнить; если с ним выясняются проблемы (чего некоторое время не было, сейчас висит одна потенциальная жалоба asy@ насчёт dmraid, которую мне не на чем воспроизвести) -- чиню.

Если бы он не использовался, grub бы не получалось установить без тех дичайших и всё равно неполных кульбитов, ради выкорчёвывания которых и затеял эту переработку.

Но с этим лучше в bug #28181 или отдельный.

Итого, вывод:
alterator-vm работает нормально
нужно разобрать массивы, собранные mdadm перед стартом alterator-vm (разумно)
нужно разорбрать VG собранные с помощью lvm перед стартом alterator-vm

все ошибки, связанные с невозможностью уйти в chroot после установки пакетов - вешаем на installer-scripts-remount-stage2

(In reply to comment #15)

> нужно разобрать массивы, собранные mdadm перед стартом alterator-vm (разумно)
> нужно разорбрать VG собранные с помощью lvm перед стартом alterator-vm

Только не хотелось бы потерять возможность ставить на уже готовое и с чем alterator-vm работает. То, что Михаил в 14-ом комментарии вторым абзацем написал. Или alterator-vm это сам увидит и соберёт ?

если alterator-vm не соберёт, то тогда будем с ним разбираться. 

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

Похоже, эта проблема характерна только при установке с livecd, так как при запуске обычного установщика никакой mdadm ничего не собирает.
Более того, для livecd, собранных из mkimage-profiles, так как только там raid-ы собираются уже в initrd.

т.е. - в Кентавре не должно быть этой ошибки ?

(В ответ на комментарий №19)
> т.е. - в Кентавре не должно быть этой ошибки ?

Немного подумав я склоняюсь к мнению, что всё-таки "или", а не "и". То есть при установке с livecd и при любой установке из mkimage-profiles.

Чинить это дейстивтельно надо, но это действительно не alterator-vm, так как он не проектировался в расчёте на ситуации, когда в системе уже есть собранные кем-то raid.

(In reply to comment #19)

> т.е. - в Кентавре не должно быть этой ошибки ?

Есть без вариантов. Bug 29473 - это результат установки именно Кентавра и не из Live CD.

(В ответ на комментарий №21)
> (In reply to comment #19)
> 
> > т.е. - в Кентавре не должно быть этой ошибки ?
> 
> Есть без вариантов. Bug 29473 - это результат установки именно Кентавра и не из
> Live CD.
Не факт, что это одна и та же ошибка. Так, как исправление 
29471 проверяли на образе, собранном на mkimage-profiles, она, возможно, исправлена

Просьба обратить внимание на installer-scripts-remount-stage2 0.5-alt1
из http://git.altlinux.org/tasks/108512/ или у glebfm@.

Просьба к RM по возможности дать отзывы о предложенном задании, оно всё ещё в TESTED.

NB: неинтерактивно можно бороться с ошмётками mdraid, а вот с dmraid придётся всё же делать что-то в alterator-vm: пока склоняюсь к мысли о дополнительном вопросе пользователю "чистим диски?" и вызове скрипта зачистки вроде приложенного к bug #29471.

У меня работает -- Глеб, отправляй #108512 в сизиф.  Проверено на виртуалке из comment 11 рассмотрением /proc/mdstat при старте первого шага инсталятора -- там пусто, md127 далее собирает уже EVMS.

Тестовый образ: http://ftp.linux.kiev.ua/pub/Linux/ALT/people/mike/iso/mkimage-profiles/tmp/regular-sysv-tde-20131116-i586.iso

installer-scripts-remount-stage2-0.5-alt1 -> sisyphus:

* Thu Nov 14 2013 Gleb F-Malinovskiy <glebfm@altlinux> 0.5-alt1
- Stop MD/DM devices in initinstall (ALT#29554).