Bug 29554 - сходу "No such device" при виде ошмётков mdraid
Summary: сходу "No such device" при виде ошмётков mdraid
Status: CLOSED FIXED
Alias: None
Product: Sisyphus
Classification: Development
Component: installer-scripts-remount-stage2 (show other bugs)
Version: unstable
Hardware: all Linux
: P3 normal
Assignee: Gleb F-Malinovskiy
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks: 27685
  Show dependency tree
 
Reported: 2013-11-05 11:15 MSK by Michael Shigorin
Modified: 2013-11-18 15:10 MSK (History)
5 users (show)

See Also:


Attachments
/var/log/evms-engine.log (20.36 KB, text/plain)
2013-11-05 11:15 MSK, Michael Shigorin
no flags Details
`mdadm -Evv --scan` (1.12 KB, text/plain)
2013-11-05 11:19 MSK, Michael Shigorin
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Shigorin 2013-11-05 11:15:00 MSK
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
Comment 1 Michael Shigorin 2013-11-05 11:19:15 MSK
Created attachment 5986 [details]
`mdadm -Evv --scan`

PS: отключение sdb помогло, разумеется.  Образ могу предоставить.
Comment 2 Sergey Y. Afonin 2013-11-05 11:38:00 MSK
Мне кажется, это просто разновидность Bug 29473, просто вылезло раньше, чем в моём случае.
Comment 3 Sergey Y. Afonin 2013-11-05 11:47:00 MSK
(In reply to comment #0)

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

Добавлю ссылку на третий случай, до кучи (тема там неправильная, но оно о том же):
http://lists.altlinux.org/pipermail/community/2013-October/680663.html
Comment 4 Michael Shigorin 2013-11-05 12:05:15 MSK
(В ответ на комментарий №2)
> Мне кажется, это просто разновидность Bug 29473
Возможно, но тут в первую очередь нужен evms-engine.log.

(В ответ на комментарий №3)
> Добавлю ссылку на третий случай
Нет, там явно про поддержку ядром: dmraid у нас нет и пока не предвидится.
Comment 5 Sergey Y. Afonin 2013-11-05 12:50:08 MSK
(In reply to comment #4)

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

Нет. Там тот же контроллер, что и у меня на Intel S2600GZ. И те же два режима (LSI/RST), один из которых хочет megasr.ko, а установка во втором, с isci.ko, обламывается в какой-то момент. Вот то, что обламывается точно так у меня, это да, из той ветки не следует. Но советы, как я понимаю, помогли. :-)
Comment 6 Sergey Y. Afonin 2013-11-05 12:59:04 MSK
(In reply to comment #4)

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

А если речь про Intel Matrix, который, якобы, формируется в режиме RST, то на сайте Intel написано, что mdadm это тоже умеет:
http://www.intel.com/support/chipsets/imsm/sb/CS-020663.htm
Comment 7 timonbl4@altlinux.org 2013-11-05 13:46:21 MSK
(В ответ на комментарий №1)
> Образ могу предоставить.

Было бы здорово, жду ссылку
Comment 8 Michael Shigorin 2013-11-05 13:50:35 MSK
(В ответ на комментарий №7)
> Было бы здорово, жду ссылку
.vdi удобно или лучше .raw?

http://fly.osdn.org.ua/~mike/tmp/grub2raid1test.vdi.gz [642M]
Comment 9 timonbl4@altlinux.org 2013-11-05 14:20:22 MSK
УМВР. Да, он нашёл какой то raid и обозвал его md127. Удаление и разбивка прошла успешна
Comment 10 timonbl4@altlinux.org 2013-11-05 14:25:16 MSK
(В ответ на комментарий №9)
> УМВР. Да, он нашёл какой то raid и обозвал его md127. Удаление и разбивка
> прошла успешна

Образ: kdesktop на сизифе
Comment 11 Michael Shigorin 2013-11-05 18:11:01 MSK
(В ответ на комментарий №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 и компания там есть.
Comment 12 timonbl4@altlinux.org 2013-11-07 14:46:38 MSK
Предположение такое: до запуска инсталлятора, mdadm собрал raid'ы и не даёт evms ими управлять. В образе kdesktop отсутствуют утилиты mdadm и lvm (в инсталляторе)
Comment 13 Anton Farygin 2013-11-07 14:48:30 MSK
ещё в kdesktop не используется remount_chroot()
Comment 14 Michael Shigorin 2013-11-07 21:48:06 MSK
(В ответ на комментарий №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 или отдельный.
Comment 15 Anton Farygin 2013-11-08 09:41:46 MSK
Итого, вывод:
alterator-vm работает нормально
нужно разобрать массивы, собранные mdadm перед стартом alterator-vm (разумно)
нужно разорбрать VG собранные с помощью lvm перед стартом alterator-vm

все ошибки, связанные с невозможностью уйти в chroot после установки пакетов - вешаем на installer-scripts-remount-stage2
Comment 16 Sergey Y. Afonin 2013-11-08 09:51:51 MSK
(In reply to comment #15)

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

Только не хотелось бы потерять возможность ставить на уже готовое и с чем alterator-vm работает. То, что Михаил в 14-ом комментарии вторым абзацем написал. Или alterator-vm это сам увидит и соберёт ?
Comment 17 Anton Farygin 2013-11-08 10:03:59 MSK
если alterator-vm не соберёт, то тогда будем с ним разбираться. 

а так - да, должен собрать и показать. По крайней мере в наших тестовых сценариях он это делает без проблем, если ему не мешая mdamd.
Comment 18 Anton V. Boyarshinov 2013-11-08 13:43:50 MSK
Похоже, эта проблема характерна только при установке с livecd, так как при запуске обычного установщика никакой mdadm ничего не собирает.
Более того, для livecd, собранных из mkimage-profiles, так как только там raid-ы собираются уже в initrd.
Comment 19 Anton Farygin 2013-11-08 13:58:22 MSK
т.е. - в Кентавре не должно быть этой ошибки ?
Comment 20 Anton V. Boyarshinov 2013-11-08 14:02:43 MSK
(В ответ на комментарий №19)
> т.е. - в Кентавре не должно быть этой ошибки ?

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

Чинить это дейстивтельно надо, но это действительно не alterator-vm, так как он не проектировался в расчёте на ситуации, когда в системе уже есть собранные кем-то raid.
Comment 21 Sergey Y. Afonin 2013-11-08 14:38:01 MSK
(In reply to comment #19)

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

Есть без вариантов. Bug 29473 - это результат установки именно Кентавра и не из Live CD.
Comment 22 Anton V. Boyarshinov 2013-11-08 14:50:20 MSK
(В ответ на комментарий №21)
> (In reply to comment #19)
> 
> > т.е. - в Кентавре не должно быть этой ошибки ?
> 
> Есть без вариантов. Bug 29473 - это результат установки именно Кентавра и не из
> Live CD.
Не факт, что это одна и та же ошибка. Так, как исправление 
29471 проверяли на образе, собранном на mkimage-profiles, она, возможно, исправлена
Comment 23 Michael Shigorin 2013-11-14 21:48:51 MSK
Просьба обратить внимание на installer-scripts-remount-stage2 0.5-alt1
из http://git.altlinux.org/tasks/108512/ или у glebfm@.
Comment 24 Michael Shigorin 2013-11-15 18:10:28 MSK
Просьба к RM по возможности дать отзывы о предложенном задании, оно всё ещё в TESTED.

NB: неинтерактивно можно бороться с ошмётками mdraid, а вот с dmraid придётся всё же делать что-то в alterator-vm: пока склоняюсь к мысли о дополнительном вопросе пользователю "чистим диски?" и вызове скрипта зачистки вроде приложенного к bug #29471.
Comment 25 Michael Shigorin 2013-11-16 05:20:27 MSK
У меня работает -- Глеб, отправляй #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
Comment 26 Repository Robot 2013-11-18 15:10:35 MSK
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).