35918 2019-01-17 12:46:51 +0300 Установщик Starterkit server (20181212) перезагружается на этапе выбора дисков. 2020-10-22 20:38:19 +0300 1 1 4 Development Sisyphus alterator-vm unstable x86_64 Linux CLOSED FIXED P3 critical --- 1 kiber_pank4 ptrnine aen boyarsh cas mcpain mike rider sem shaba zerg qa-sisyphus oldest_to_newest 177472 0 kiber_pank4 2019-01-17 12:46:51 +0300 Установщик Starterkit server (20181212) перезагружается на этапе выбора дисков для установки и нажатия далее. Дисковая подсистема состоит из двух HDD, на которых ранее был установлен ClearOS 7.3 (на LVM поверх MDADM RAID1). Могу предположить, что воспроизведётся также с дисками аналогичной конфигурации после CentOS. Костыль для обхода проблемы состоит в загрузке с LiveCD и удалении всех следов LVM и MDADM с дисков, после чего инсталлятор отрабатывает без падения. 185193 1 kiber_pank4 2019-10-30 12:34:12 +0300 Проблема актуальная для последнего Стартеркита от 12.09.2019. В данном случае, с помощью того-же стартеркита загрузился в livecd, на 2 новых ssd без разметки создал разделы, собрал raid1 и поверх него lvm. Перезагрузился в режим установки и в интерфейсе подготовки диска сначала ошибка "Bad file descriptor", переходим назад и возвращаемся в интерфейс подготовки дисков, где диски уже отображаются, выбираем вручную и здесь при попытке создания файловой системы система уходит в ребут. По сути, для воспроизведения нужно иметь диски, где есть lvm поверх mdadm. 185199 2 kiber_pank4 2019-10-30 15:17:08 +0300 Похоже нашёл причину падения - установщик настолько стеснителен, что предпочитает уйти по-английски, вместо того, чтобы сказать, что ему не нравится metadata > 0.90 :) Инфа не 100%, так как нет времени проводить повторный тест, но почти наверняка так. В подтверждение этому, ClearOS использует по умолчанию суперблок версии 1.2, что похоже явилось изначальной проблемой при создании этого бага. 187474 3 mike 2020-02-04 14:58:41 +0300 Ах так вот на что я напоролся на p9_e2k вчера. Субъективно вообще блокер: обход с отключением массивов и тем более их переинициализацией может быть возможен далеко не всегда. 187475 4 rider 2020-02-04 15:01:37 +0300 Да, вполне возможно что виновата metadata > 0.9 187606 5 ptrnine 2020-02-06 18:42:42 +0300 Нашел причину падения. Актуально это дело для metadata >= 1.0 Проблема происходит при попытке сделать mknod, потому что у dev_t устройства, которое передается в эту функцию, minor установлен в -1. Функции mknod это не нравится, и она прерывается с errno = EINVAL Прилетает этот -1 вот отсюда: http://git.altlinux.org/gears/e/evms.git?p=evms.git;a=blob;f=plugins/md/md_super.c;h=4138315522be42f6c8ef30f210e2629026d10e1c;hb=HEAD#l2155 Здесь ожидается, что имя будет "md" + число (которое как раз и будет использоваться в качестве minor). Но на практике - mdadm, например, выставил имя localhost:localdomain:0. А с помощью ключа --name можно задать вообще любое имя. В общем, я подумаю. Наверное, нужен механизм, который в случае чего, раздаст эти minor'ы тем, у кого они оказались равны -1 187607 6 ptrnine 2020-02-06 18:52:02 +0300 Кстати, просьба для тех, кто столкнулся с данной проблемой - посмотрите, пожалуйста, название RAID массива. Может быть, я вообще на другой баг наткнулся :) 188845 7 zerg 2020-03-26 18:33:17 +0300 Никому не надо? 188854 8 mike 2020-03-26 22:15:23 +0300 Видимо, никто глыбже Славы и не копал. 188872 9 zerg 2020-03-27 11:42:56 +0300 Я про Славину просьбу. 188880 10 ptrnine 2020-03-27 15:13:56 +0300 Проблема с минором это пол беды. По каким-то причинам не отрабатывает ioctl с аргументом ADD_NEW_DISK, когда evms пытыется собрать массив (EINVAL) При этом, для этого нет никаких видимых причин (устройство существует, дескриптор валидный, мажор/минор установлены правильно) Что еще удивительнее - при повторении всех действий evms (которые я не упустил) "вручную" ADD_NEW_DISK отрабатывает нормально. Также все нормально работает и в evms-ncurses (!?) Если очень детально сравнить логи/strace при mkfs из alterator-vm'а и evmsn, то выясняется, что в evmsn ioctl просто не фэйлится :) EINVAL прилетает из-за того, что в где-то в ядре оказывается неверная версия суперблока и в результате в функции load_1_super (drivers/md/md.c) суперблок читается не по тому смещению. На данный момент я пытаюсь выяснить, почему так происходит. Если у кого-нибудь есть хоть какие идеи, то прошу озвучить 188881 11 zerg 2020-03-27 15:25:38 +0300 Или подпишите заинтересованных. 189294 12 ptrnine 2020-04-17 14:16:41 +0300 В общем, по каким-то причинам на новых образах баг с ADD_NEW_DISK больше не воспроизводится. Баг с минорами исправлен с помощью супер-костыля: http://git.altlinux.org/people/ptrnine/packages/?p=evms.git;a=commit;h=981fd11cfd968732293a735929bd79acdcdf6e68 Работает оно так: - проходится по всем md* из файла /proc/mdstat - для каждого md* берет первую в списке ноду и читает из ее суперблока uuid - если uuid подошел - значит в md* и записан наш минор (вместо звездочки) Сегодня отправлю, осталось еще чуть-чуть протестировать. 191550 13 kiber_pank4 2020-07-24 14:45:33 +0300 Сегодня вновь была возможность затестить наличие этого бага и он на месте на последнем alt-p9-server-systemd-20200612-x86_64.iso. Теперь уже однозначно могу сказать что дело в не корректной работе с mdadm суперблоком 1.2. Элементарно воспроизводится на ВМ - в девтсвтенной ВМ грузимся с livecd, создаём raid 0 с метадата по умолчанию, перезагружаемся, активируем массив (всё это наверное можно сделать и в консоли после запуска установки до диалога разбивки дисков), заходим с диалог ручного разбиения дисков, пытаемся там что-то сделать и система уходит в ребут. 192717 14 repository-robot 2020-09-21 17:51:19 +0300 evms-2.5.5-alt45 -> sisyphus: Tue Sep 15 2020 Slava Aseev <ptrnine@altlinux> 2.5.5-alt45 - plugins/md: + fix raid discovering and md_minor getting for metadata=1.* (closes: #35918) + use better name's collision resolving for metadata=1.* + use metadata=1.2 by default + add RAID test 192730 15 mike 2020-09-22 11:20:17 +0300 Слава, спасибо! В p9 тащим, чтоб не только регуляркам полегчало? :) 192740 16 ptrnine 2020-09-22 12:28:40 +0300 (Ответ для Michael Shigorin на комментарий #15) > Слава, спасибо! > В p9 тащим, чтоб не только регуляркам полегчало? :) Да, p9 на подходе: http://webery.altlinux.org/task/258473 193344 17 zerg 2020-10-19 17:54:27 +0300 (Ответ для Slava Aseev на комментарий #16) > Да, p9 на подходе: http://webery.altlinux.org/task/258473 Когда? 193346 18 ptrnine 2020-10-19 18:10:30 +0300 (Ответ для Sergey V Turchin на комментарий #17) > (Ответ для Slava Aseev на комментарий #16) > > Да, p9 на подходе: http://webery.altlinux.org/task/258473 > Когда? Сейчас отправлю, там надо убрать автогенерируемую зависимость на /usr/share/install2/initinstall.d/80-stop-md-dm.sh, т.к. на p9 из-за нее невозможно установить пакет с тестами: # apt-get install /usr/share/install2/initinstall.d/80-stop-md-dm.sh E: Невозможно найти пакет /usr/share/install2/initinstall.d/80-stop-md-dm.sh # apt-get install installer-scripts-remount-stage2 Следующие НОВЫЕ пакеты будут установлены: installer-scripts-remount-stage2 ... 1: installer-scripts-remount-stage2-0.5.#################################################################################### [100%] Завершено. # rpm -qf /usr/share/install2/initinstall.d/80-stop-md-dm.sh installer-scripts-remount-stage2-0.5.19-alt1.noarch На сизифе все нормально. Хотел отправить одним релизом с исправлением вот этого https://bugzilla.altlinux.org/show_bug.cgi?id=38796 но там, видимо, исправление подъедет нескоро, так что сейчас отправлю так. 193449 19 repository-robot 2020-10-22 20:38:19 +0300 evms-2.5.5-alt47 -> p9: Tue Oct 20 2020 Slava Aseev <ptrnine@altlinux> 2.5.5-alt47 - Revert "Fix LVM2 logical volume deactivation" Fix not ready yet and was sent by mistake Tue Sep 29 2020 Slava Aseev <ptrnine@altlinux> 2.5.5-alt46 - Fix LVM2 logical volume deactivation (closes: #38796) - Remove broken dependency on /usr/share/install2/initinstall.d/80-stop-md-dm.sh Tue Sep 15 2020 Slava Aseev <ptrnine@altlinux> 2.5.5-alt45 - plugins/md: + fix raid discovering and md_minor getting for metadata=1.* (closes: #35918) + use better name's collision resolving for metadata=1.* + use metadata=1.2 by default + add RAID test