Created attachment 5985 [details] /var/log/evms-engine.log При попытке установить очередную сборку regular-rc на тестовую vbox vm получил на шаге разбивки дисков сообщение No such device, при этом диски в списке отсутствовали, хотя оба видны в `fdisk -l` в консоли там же. По /var/log/evms-engine.log выяснилось, что происходит попытка стучаться в md/md127, который образовался из ошмётков зеркала на sda/sdb при более раннем эксперименте, после которого sda (расположенный на tmpfs) был обнулён. Прилагаю лог EVMS и `mdadm -Evv --scan`; поскольку ситуация не то чтобы редчайшая, а последствия неприятны (установка невозможна, внятная диагностика отсутствует) -- предлагаю повысить фактический приоритет этой проблемы и починить до 7.0.2 или где там. Воспроизведено на сегодняшнем сизифе, версии с p7/branch одинаковые: alterator-vm-0.4.3-alt1 evms-2.5.5-alt30 guile-evms-0.4-alt14
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).
