Bug 29554

Summary: сходу "No such device" при виде ошмётков mdraid
Product: [Development] Sisyphus Reporter: Michael Shigorin <mike@altlinux.org>
Component: installer-scripts-remount-stage2Assignee: Gleb F-Malinovskiy <glebfm@altlinux.org>
Status: CLOSED FIXED QA Contact: qa-sisyphus@altlinux.org
Severity: normal    
Priority: P3 CC: aen@altlinux.org, asy@altlinux.org, boyarsh@altlinux.org, rider@altlinux.org
Version: unstable   
Hardware: all   
OS: Linux   
Bug Depends on:    
Bug Blocks: 27685    
Attachments:
Description Flags
/var/log/evms-engine.log
none
`mdadm -Evv --scan` none

Description From 2013-11-05 11:15:00
Created an attachment (id=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 From 2013-11-05 11:19:15 -------
Created an attachment (id=5986) [details]
`mdadm -Evv --scan`

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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