Bug 28879

Насколько я понимаю, это скорее к make-initrd, чем к ядру.

(В ответ на комментарий №1)
> Насколько я понимаю, это скорее к make-initrd, чем к ядру.

2legion: согласны?

2boyarsh: это, полагаю, блокер для Кентавра. Если не согласны, напшите.

(В ответ на комментарий №2)
> (В ответ на комментарий №1)
> > Насколько я понимаю, это скорее к make-initrd, чем к ядру.
> 
> 2legion: согласны?

Для ответа слишком мало информации. Не сказано грузилась ли эта машина с всеми дисками. Неизвестно даже какие модули make-initrd были при сборке образа.
Поэтому вина не доказана.

(В ответ на комментарий №3)
> (В ответ на комментарий №2)
> > (В ответ на комментарий №1)
> > > Насколько я понимаю, это скорее к make-initrd, чем к ядру.
> > 
> > 2legion: согласны?
> 
> Для ответа слишком мало информации. Не сказано грузилась ли эта машина с всеми
> дисками. Неизвестно даже какие модули make-initrd были при сборке образа.
> Поэтому вина не доказана.

Ok.
Прошу rotkart@ представить информацию, если это сейчас возможно.

(В ответ на комментарий №4)
> (В ответ на комментарий №3)
> > (В ответ на комментарий №2)
> > > (В ответ на комментарий №1)
> > > > Насколько я понимаю, это скорее к make-initrd, чем к ядру.
> > > 
> > > 2legion: согласны?
> > 
> > Для ответа слишком мало информации. Не сказано грузилась ли эта машина с всеми
> > дисками. Неизвестно даже какие модули make-initrd были при сборке образа.
> > Поэтому вина не доказана.
> 
> Ok.
> Прошу rotkart@ представить информацию, если это сейчас возможно.

Доброго дня!
Как раз про то, что грузилась со всеми дисками - сказано в описании бага. Эта бета устанавливается на зеркальный рейд и грузится с него.
Загрузчик, правда, устанавливается только на один первый диск :-(
Если отключить второй диск - происходит та ситуация из-за которой я открыл этот баг. При возвращении шлейфа на место - система опять грузится.

Остальное - в понедельник 6-го марта. Даже установлю с нуля новую бету Кентавра p7.

Если уточните, где, после установки, можно будет посмотреть параметры сборки образа initrd - буду премного благодарен!

(В ответ на комментарий №5)
> Если уточните, где, после установки, можно будет посмотреть параметры сборки
> образа initrd - буду премного благодарен!

Сразу несколько вопросов:

1. Какие параметры передаются при загрузке ядру ?
2. Какая версия make-initrd ?
3. Какие модули make-initrd-* были при сборке ?
4. Можно взглянуть на /etc/initrd.mk ?

(In reply to comment #6)
> (В ответ на комментарий №5)
> > Если уточните, где, после установки, можно будет посмотреть параметры сборки
> > образа initrd - буду премного благодарен!
> 
> Сразу несколько вопросов:
> 
> 1. Какие параметры передаются при загрузке ядру ?
> 2. Какая версия make-initrd ?
> 3. Какие модули make-initrd-* были при сборке ?
> 4. Можно взглянуть на /etc/initrd.mk ?

Установил http://beta.altlinux.org/p7/centaurus/altlinux-6.9.9-beta20130426-centaurus-x86_64-ru-install-dvd5.iso в режиме серверной авторазбивки дисков c предварительной их очисткой.
Дождался синхронизации зеркал. Отключил второй диск - не грузится. Скриншот - в аттаче.
По вопросам:
1. Из grub.cfg
menuentry 'ALT Linux 6.9.9 Centaurus beta' --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-cdc7ca57-ba49-47
07-bd8f-bc6ea9dedf13' {
        savedefault
        load_video
        insmod gzio
        insmod part_gpt
        insmod part_gpt
        insmod diskfilter
        insmod mdraid09
        insmod ext2
        set root='mduuid/b254f21abc2704235ac3455f95402b32'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint='mduuid/b254f21abc2704235ac3455f95402b32'  cdc7ca57-ba49-4707-bd8f-bc6ea9dedf13
        else
          search --no-floppy --fs-uuid --set=root cdc7ca57-ba49-4707-bd8f-bc6ea9dedf13
        fi
        echo    'Загружается Linux vmlinuz …'
        linux   /boot/vmlinuz root=UUID=cdc7ca57-ba49-4707-bd8f-bc6ea9dedf13 ro failsafe vga=normal resume=/dev/disk/by-uuid/81737117-7724
-4110-bd7f-e4c9ca64d4ad panic=30 splash
        echo    'Загружается начальный виртуальный диск …'
        initrd  /boot/initrd.img
}

2,3: [root@testserv ~]# rpm -qa | grep initrd
make-initrd-0.8.4-alt1
make-initrd-plymouth-0.8.4-alt1
make-initrd-luks-0.8.4-alt1
make-initrd-lvm-0.8.4-alt1
make-initrd-mdadm-0.8.4-alt1
make-initrd-devmapper-0.8.4-alt1

4. [root@testserv ~]# cat /etc/initrd.mk
# trying to detect modules and features to access to root volume
AUTODETECT = all

Created attachment 5818 [details]
Скриншот kernel panic при отключении второго диска

Ой, из моего #7, наверное, непонятно, что при возвращении второго диска на место система грузится и работает. Из неё и пишу сейчас.
[root@testserv ~]# cat /etc/altlinux-release 
ALT Linux 6.9.9 Centaurus beta (Cheiron)
[root@testserv ~]# uname -a
Linux testserv.localdomain 3.8.9-std-def-alt1 #1 SMP Fri Apr 26 05:38:53 UTC 2013 x86_64 GNU/Linux

После того как диск вернули и смогли загрузиться в систему, покажите пожалуйста вывод команды:

$ blkid -c /dev/null

(В ответ на комментарий №10)
> После того как диск вернули и смогли загрузиться в систему, покажите пожалуйста
> вывод команды:
> 
> $ blkid -c /dev/null

[root@testserv ~]# blkid -c /dev/null
/dev/sdb1: UUID="745e0b7a-da1d-2126-edf1-9ed36b19e340" TYPE="linux_raid_member" PARTUUID="b29dd04e-15df-a74d-8920-4f95c1cb94f8" 
/dev/sdb2: UUID="b254f21a-bc27-0423-5ac3-455f95402b32" TYPE="linux_raid_member" PARTUUID="5c9d8362-2024-9143-92c2-01a7bc0caf60" 
/dev/sdb3: UUID="c87e6a45-3cac-7273-3fab-56b7d5d0b22e" TYPE="linux_raid_member" 
/dev/sda1: UUID="29BB-ABE1" TYPE="vfat" PARTUUID="b720db72-3e48-8041-ad0f-32aee9aa3387" 
/dev/sda3: UUID="745e0b7a-da1d-2126-edf1-9ed36b19e340" TYPE="linux_raid_member" 
/dev/sda4: UUID="b254f21a-bc27-0423-5ac3-455f95402b32" TYPE="linux_raid_member" 
/dev/sda5: UUID="c87e6a45-3cac-7273-3fab-56b7d5d0b22e" TYPE="linux_raid_member" 
/dev/md4: UUID="cdc7ca57-ba49-4707-bd8f-bc6ea9dedf13" TYPE="ext4" 
/dev/md0: UUID="81737117-7724-4110-bd7f-e4c9ca64d4ad" TYPE="swap" 
/dev/md5: UUID="6936bc5d-32b9-445b-9854-422bbbc04ce2" TYPE="ext4"

Образ с оффсайта: altlinux-7.0.1-centaurus-x86_64-ru-install-dvd5
Взял два нулевых, идентичных винта по 1ТБ. Установил по инструкции на зеркальный райд массив(mirror(1)). Разбиение делал: своп, 100гБ система, отстаток. Установил. Запустил, обновил(дистриб, ядро ответило, что самое новое), ребутнул. Все работало. 
Для имитации проблем, выключил систему, выдернул шлейф с одного из винчестеров. Включаем.
загрузка доходит до
initrd: processing kernel events и подвисает. Потом выскакивает:
initrd: loop: ERROR: /root: not mounted
initrd: stage 'loop' failed
initrd: this shell remains here for debug purposes. Press ctrl-d to continue (initparams)
Жмем ctrl-d, комп выводит кучу строк, и перегружается.

Если выключить, воткнуть шлейф, загрузится без проблем. При выдергивании ЛЮБОГО hdd ситуация повторяется.

[pavel@tsthost2 ~]$ cat /proc/mdstat
Personalities : [raid1]
md5 : active raid1 sdb3[1] sda3[0]
      856313792 blocks [2/2] [UU]

md3 : active raid1 sdb1[1] sda1[0]
      9616320 blocks [2/2] [UU]

md4 : active raid1 sdb2[1] sda2[0]
      110828480 blocks [2/2] [UU]

[root@tsthost2 ~]# blkid -c /dev/null
/dev/sdb1: UUID="713bf167-01b5-5d25-6d8c-cd7481e5bf4e" TYPE="linux_raid_member"
/dev/sdb2: UUID="25d98361-51cd-5260-6f6f-1c8490789c74" TYPE="linux_raid_member"
/dev/sdb3: UUID="cd9023ca-c8c9-2c27-3c4c-202d1e88febf" TYPE="linux_raid_member"
/dev/sda1: UUID="713bf167-01b5-5d25-6d8c-cd7481e5bf4e" TYPE="linux_raid_member"
/dev/sda2: UUID="25d98361-51cd-5260-6f6f-1c8490789c74" TYPE="linux_raid_member"
/dev/sda3: UUID="cd9023ca-c8c9-2c27-3c4c-202d1e88febf" TYPE="linux_raid_member"
/dev/md4: UUID="b50d6897-2de4-4fb4-bbc7-3110d3bad485" TYPE="ext4"
/dev/md3: UUID="3d631567-11c4-4c5d-9e3b-34cb6a35fa81" TYPE="swap"
/dev/md5: UUID="680144c0-d3a9-4b0a-9e6c-c8a8a404156e" TYPE="ext4"

[root@tsthost2 ~]# uname -a
Linux tsthost2 3.8.13.4-std-def-alt1.M70P.2 #1 SMP Tue Jul 16 11:08:06 UTC 2013 x86_64 GNU/Linux
[root@tsthost2 ~]# cat /etc/altlinux-release
ALT Linux 7.0.1 Centaurus  (Pholus)

Такая-же ситуация возникает, если поменять при установке SysVinit на Systemd.
При отсутствии одного из винтов, все встает колом.

Я попробовал сымитировать эту ситуацию в qemu и проблема не воспроизвелась. Система нормально грузится, mdadm честно рассказывает что статус "degraded, clean"

> initrd: stage 'loop' failed
> initrd: this shell remains here for debug purposes. Press ctrl-d to continue
> (initparams)
> Жмем ctrl-d, комп выводит кучу строк, и перегружается.
Я думаю, надо исползовать этот отладочный shell для сбора дополнительной информации. Можно примонтировать, допустим, флэшку и сохранить на ней вывод dmesg и mdadm --detail /dev/md0

Created attachment 5908 [details]
mdadm и не нахождение флешки

Created attachment 5909 [details]
mdstat

Created attachment 5910 [details]
концовка dmesg

(В ответ на комментарий №14)
> Я попробовал сымитировать эту ситуацию в qemu и проблема не воспроизвелась.
> Система нормально грузится, mdadm честно рассказывает что статус "degraded,
> clean"
> 
> > initrd: stage 'loop' failed
> > initrd: this shell remains here for debug purposes. Press ctrl-d to continue
> > (initparams)
> > Жмем ctrl-d, комп выводит кучу строк, и перегружается.
> Я думаю, надо исползовать этот отладочный shell для сбора дополнительной
> информации. Можно примонтировать, допустим, флэшку и сохранить на ней вывод
> dmesg и mdadm --detail /dev/md0

вставил флешку на живой системе
ls -l /dev/s*
brw-rw---- 1 root disk  8,   0 Aug 15  2013 /dev/sda
brw-rw---- 1 root disk  8,   1 Aug 15  2013 /dev/sda1
brw-rw---- 1 root disk  8,   2 Aug 15  2013 /dev/sda2
brw-rw---- 1 root disk  8,   3 Aug 15  2013 /dev/sda3
brw-rw---- 1 root disk  8,  16 Aug 15  2013 /dev/sdb
brw-rw---- 1 root disk  8,  17 Aug 15  2013 /dev/sdb1
brw-rw---- 1 root disk  8,  18 Aug 15  2013 /dev/sdb2
brw-rw---- 1 root disk  8,  19 Aug 15  2013 /dev/sdb3
brw-rw---- 1 root disk  8,  32 Aug 15 09:18 /dev/sdc    
brw-rw---- 1 root disk  8,  36 Aug 15 09:18 /dev/sdc4
флешку находит (sdc).
Выкл, Отключил винт, включил комп, подождал пока он впадет в ступор.
ls -l /dev/s* - не находит моей флешки.
mdadm - см скриншоты.
dmesg выдает много чего и не помещается на экран, полностью сфотать не получится. 
Попробовал dmesg | more, dmesg | less выдает /bin/sh more not found, /bin/sh less not found
15-16.08.2013 с 8:00 - 14:00 по Мск, готов выступить тестером и помочь разобраться с проблемой под руководством, например с видео по скайпу, опытных товарищей :).

Ага, спасибо, в процессе разбирательства в отличиях dmesg, я понял, что воспроизводил проблему на слишком старом образе, попробую повторить, пока dmesg и прочей информации достаточно.

Мне удалось воспроизвести проблему, правда для этого мне пришлось выдёргивать диски поочерёдно (до этого всё грузилось). После выдёргивания сначала второго, возвращения его и выдёргивания первого диска (без efi этот номер проходит) я получил очень похожее выпадание в (initramfs) с очень похожим mdstat.

Raid-ы собраны, но неактивны.

Запуск mdadm --run /dev/mdX переводит raid в состояние active,degraded, и, вероятно, с него можно было бы загрузиться, вручную смонтировав / и запустив init.

Видимо, в make-initrd надо вставить mdadm --run (причём от лишнего его запуска вреда не будет, кроме сообщения об ошибке) перед монтированием того, что лежит на этом raid.

проблема в том, что в make-initrd-mdadm не видно никакого места, куда этот mdadm --run можно было бы воткнуть..

> Запуск mdadm --run /dev/mdX переводит raid в состояние active,degraded, и,
> вероятно, с него можно было бы загрузиться, вручную смонтировав / и запустив
> init.
Таки да, если после mdadm --run /dev/mdX сделать
mount /dev/mdX /root
exec /root/sbin/init то загрузка проходит.

Created attachment 5911 [details]
попытка активации

Created attachment 5912 [details]
попытка запуска

Created attachment 5913 [details]
попытка запуска №2, удачная

В чем разница между первой и второй попыткой я не понял, но система стартанула.
Причем, если систему опять перегрузить, то она стартует более-менее НОРМАЛЬНО (см примечания) и при одном винте. Видимо надо, при аварийном запуске всего лишь правильно перемонтировать райд и рестартовать систему.

Примечание 1.
После аварийного перезапуска системы появляется сообщение, мол у вас нарушен райд, ждем минуту, вы или что-то делаете или система будет пытаться стартовать в нормальном режиме. Ждем и все стартует. Что есть гуд.

Примечание 2. Отвалился свап. Как прицепить обратно, не знаю. Вроде бы все правильно. При загрузке появляется сообщение:
Aug 16 09:32:15 tsthost2 rc.sysinit: Cleaning up temporary files from previous boot: succeeded
Aug 16 09:32:15 tsthost2 swapon: swapon: cannot find the device for UUID=3d631567-11c4-4c5d-9e3b-34cb6a35fa81
Aug 16 09:32:15 tsthost2 rc.sysinit: Activating swap space: failed
A
грузимся дальше нормально.
[root@tsthost2 ~]# cat /proc/mdstat
Personalities : [raid1]
md3 : inactive sda1[1](S)
      9616320 blocks

md5 : active raid1 sda3[1]
      856313792 blocks [2/1] [_U]

md4 : active raid1 sda2[1]
      110828480 blocks [2/1] [_U]

unused devices: <none>
[root@tsthost2 ~]# blkid -c /dev/null
/dev/sda1: UUID="713bf167-01b5-5d25-6d8c-cd7481e5bf4e" TYPE="linux_raid_member"
/dev/sda2: UUID="25d98361-51cd-5260-6f6f-1c8490789c74" TYPE="linux_raid_member"
/dev/sda3: UUID="cd9023ca-c8c9-2c27-3c4c-202d1e88febf" TYPE="linux_raid_member"
/dev/md4: UUID="b50d6897-2de4-4fb4-bbc7-3110d3bad485" TYPE="ext4"
/dev/md5: UUID="680144c0-d3a9-4b0a-9e6c-c8a8a404156e" TYPE="ext4"
[root@tsthost2 ~]# mdadm --run /dev/md3
mdadm: started /dev/md3
[root@tsthost2 ~]# cat /proc/mdstat
Personalities : [raid1]
md3 : active raid1 sda1[1]
      9616320 blocks [2/1] [_U]

md5 : active raid1 sda3[1]
      856313792 blocks [2/1] [_U]

md4 : active raid1 sda2[1]
      110828480 blocks [2/1] [_U]

unused devices: <none>
[root@tsthost2 ~]# blkid -c /dev/null
/dev/sda1: UUID="713bf167-01b5-5d25-6d8c-cd7481e5bf4e" TYPE="linux_raid_member"
/dev/sda2: UUID="25d98361-51cd-5260-6f6f-1c8490789c74" TYPE="linux_raid_member"
/dev/sda3: UUID="cd9023ca-c8c9-2c27-3c4c-202d1e88febf" TYPE="linux_raid_member"
/dev/md4: UUID="b50d6897-2de4-4fb4-bbc7-3110d3bad485" TYPE="ext4"
/dev/md5: UUID="680144c0-d3a9-4b0a-9e6c-c8a8a404156e" TYPE="ext4"
/dev/md3: UUID="3d631567-11c4-4c5d-9e3b-34cb6a35fa81" TYPE="swap"
Теперь, по виду, все правильно. Но при перезагрузке свап опять уедет :(
Вроде бы и UUID правильный при загрузке, почему он свап-то роняет?
Примечание 3.
Не совсем относится к данной проблеме, но в какую именно рассылку написать, не знаю. При установке дистрибутива altlinux-7.0.1-centaurus-x86_64-ru-install-dvd5 выбирал МИНИМАЛЬНЫЙ набор. Все галочки были сняты. В том числе с bind сервера и dhcp сервера. Проверял на двух установках. Но, в итоге, эти пакеты все равно ставятся. Но в автозапуске не стоят. Может и не стоит их устанавливать-то, раз нее просят.

Чуть позже отпишусь о попытке восстановления райда при подключении чистенького винта.

Все восстановил по инструкции. После восстановления зеркала, ошибка подключения свап раздела тоже пропала. Думаю это связанно с тем, что 
[root@tsthost2 ~]# cat /proc/mdstat
Personalities : [raid1]
md5 : active raid1 sda3[1] sdb3[0]
      856313792 blocks [2/2] [UU]

md4 : active raid1 sdb2[0] sda2[1]
      110828480 blocks [2/2] [UU]

md3 : active raid1 sda1[1] sdb1[0]
      9616320 blocks [2/2] [UU]
 у него разделы с разных винтов чередуются. И он, по ошибке, зачем-то пытался свап поднять с отключенного винта. Но это только предположение.

(В ответ на комментарий №26)
> В чем разница между первой и второй попыткой я не понял, но система стартанула.
Разница в монтировании в /root md5 и md4 соответственно. Очевидно, что на /home нет /sbin/init :D

Created attachment 5914 [details]
доломал массив

Т.е. я восстановил райд, перепрописал загрузчик. Перегрузился, все работало.
Отключил ПЕРВЫЙ винт(тот, который оставался в массиве при первом опыте и с которого все восстанавливалось).
Система не поднималась, как и в прошлый раз.
Проделываем финты:
mdadm --run /dev/md4 
mount /dev/mdX /root
exec /root/sbin/init
И получаем скрин.

Что интересно, если mdadm умышленно сказать, что какой-то из разделов в RAID сбойный, то загрузка проходит нормально. Например:

mdadm /dev/md0 -f /dev/sda1

Но, если отключить диск физически, тогда такая же ошибка, что выше описали.

Отключал по очереди sda, sdb. Не грузится никак. Только парно. Жестко как-то.

(In reply to comment #0)

> Зеркала получились такие:
> 
> md1 : active raid1 sdb1[1] sda3[0]
>        15028736 blocks [2/2] [UU]
> 
> md3 : active raid1 sda5[0] sdb3[1]
>        465587712 blocks [2/2] [UU]
> 
> md2 : active raid1 sdb2[1] sda4[0]
>        7494208 blocks [2/2] [UU]

А почему так ? Почему пары sdb1 и sda3, sda5 и sdb3 и т.д.? Оно, в общем-то, возможно, но как-то неакуратно.

> Смонтировалось:  md1 - swap, md2 - /, md3 - /var, sda1 - /boot/efi

И вот это вот тоже нехорошо для авторазбивки: /boot/efi, всё же, надо на RAID по-умолчанию. И, может, лучше целиком /boot...

Проверил на своей конфигурации, тоже не загружается. По умолчанию установка загрузчика предлагалась на sda, очевидно, на sdb он не прописался. У меня /boot на отдельном /dev/md0 (правда, я ещё и EFI не использую), наверное, стоило предлагать установку туда по-умолчанию. И, сразу, восстанавливать mbr на всех дисках, на всякий случай.

И bootable flag на sdb1 не поставился...
Кстати, может второй баг создать с такой же темой, для обсуждения инсталлятора ? А то мои комментарии к initrd отношения не имеют...

(В ответ на комментарий №34)
> Проверил на своей конфигурации, тоже не загружается. По умолчанию установка
> загрузчика предлагалась на sda, очевидно, на sdb он не прописался.
Очевидно, куда сказано, туда и встал.

> У меня /boot на отдельном /dev/md0 (правда, я ещё и EFI не использую)
С EFI пока известно, что не работает (и не совсем понятно, что с этим делать).  Этот баг -- именно о том.  О другом стоит и вешать другой.

(In reply to comment #36)

> > Проверил на своей конфигурации, тоже не загружается. По умолчанию установка
> > загрузчика предлагалась на sda, очевидно, на sdb он не прописался.

> Очевидно, куда сказано, туда и встал.

Очевидно. Но не очень правильно в плане выбора. :-) Bug 29480.
И из исходного сообщения тут Bug 29481.

(В ответ на комментарий №36)
> (В ответ на комментарий №34)
> > Проверил на своей конфигурации, тоже не загружается. По умолчанию установка
> > загрузчика предлагалась на sda, очевидно, на sdb он не прописался.
> Очевидно, куда сказано, туда и встал.
> 
> > У меня /boot на отдельном /dev/md0 (правда, я ещё и EFI не использую)
> С EFI пока известно, что не работает (и не совсем понятно, что с этим делать). 
> Этот баг -- именно о том.  О другом стоит и вешать другой.
Да  с /boot/efi как раз известно что делать! В Дебиане работает так: во время установки размечаем оба диска одинаково, т.е. /dev/sdX1 - фат-раздел для /boot/efi, /dev/sdX2 - для gruba, остальное под зеркало(а) и своп. Во время инсталляции загрузчик устанавливаем на /dev/sda. После установки просто копируем разделы EFI и grub при помощи dd на sdb. Все, даже fstab править не надо, dd скопировал его UUID. Повторять dd стоит только при обновлении grub, как я понимаю. Ну или если кто ещё в EFI что-то написал.
Я так попытался проделать и на ALT p7. У меня после этих действий мамка начинает видеть EFI на обоих дисках и грузится. Но только с двумя хардами. При отключении одного из них я и поймал этот баг с зеркалами. Жду, может починят.

(In reply to comment #0)

> Зеркала получились такие:
> 
> md1 : active raid1 sdb1[1] sda3[0]
>        15028736 blocks [2/2] [UU]
> 
> md3 : active raid1 sda5[0] sdb3[1]
>        465587712 blocks [2/2] [UU]

Нужен Ваш комментарий в http://bugzilla.altlinux.org/29481
Эти пары из sdb1+sda3 и sda5+sdb3 странно выглядят.

На чем остановилось дело?

Обновлял в начале уже этого года сервер с софтверным raid1 (x86_64, полный dist-upgrade из сизифа, из важного: bootloader-utils, coreutils, grub2-pc, udev, ядро до ovz-el-alt108) после чего система перестала грузиться И с обоих дисков и с каждого в отдельности с идентичной руганью:

initrd: processing kernel events (ДОЛГАЯ пауза)
initrd: loop: ERROR: /root: not mounted
initrd: stage 'loop' failed
initrd: this shell remains here for debug purposes. Press ctrl-d to continue
(initparams)

старое ядро ovz-el-alt104 при этом тоже не грузится, так же.

(тогда ещё не читал этого бага) ок, запускаю с флешки, монтирую всё в чрут, смотрю: старый initrd не обновлялся (логично), от нового он качественно отличается только тем, что одно правило удева для сборки mdadm-массивов разбито на два файла, остальные изменения это размер и сонеймы нескольких библиотек.

Поднял из этого чрута сеть, обновил ядро до ovz-el-alt109 (теже изменения в initrd относительно alt104), перезагружаюсь - не помогло, синдромы те же.

Поскольку перестало грузиться и старое ядро/initrd, я грешу только на сломавшийся udev.

Попробую по мотивам обсуждения здесь запустить сервер на будущей неделе, но не очень понятно, что ломается и как чинить.

Баг висит на make-initrd. Это вообще актуальный компонент?

Поймал вчера на другой машине, уже std-pae, i586. Помогла загрузка с флешки удаление умершего диска из рейда.

При этом система при ошибках диска вставала колом, но рейд не разваливался (судя по логам, можно сделать kernel.hung_task_panic=1 чтобы система автоматически перезагружалась при замирании IO, а не была в колебаниях работа/замерзание).

Непонятно тогда, зачем нужен такой рейд, что ничего делать на одном диске не дает без ручного вмешательства.

Надо воспроизводить на стенде и думать, что делать.  Боюсь, до конференции (ближайшие выходные) маловероятно.

(В ответ на комментарий №6)
1) [...] root=UUID=<соответствующий /dev/md0> ro panic=30 splash
2) make-initrd-0.8.7-alt1
3) lvm, devmapper, luks, mdadm
4) AUTODETECT = all (кроме комментария в первой строке)

blkid в initramfs shell показывает только sda1 (md0 из sda1, sdb1).

(В ответ на комментарий №22)
> mdadm --run /dev/mdX
> mount /dev/mdX /root
> exec /root/sbin/init
Подтверждаю, так догрузилось.

(В ответ на комментарий №26)
> Причем, если систему опять перегрузить, то она стартует более-менее НОРМАЛЬНО
> (см примечания) и при одном винте.
Подтверждаю, без дополнительных действий сделал reboot и получил грузящуюся с одного диска систему.  Вероятно, изменились метаданные md0.

(В ответ на комментарий №38)
Прошу эту багу оставить про initrd, а про raid1 /boot/efi повесить другую.

(В ответ на комментарий №21)
> проблема в том, что в make-initrd-mdadm не видно никакого места, куда этот
> mdadm --run можно было бы воткнуть..
features/raid/data-extra/etc/udev/rules.d/64-md-raid.rules ?

(In reply to comment #40)
> На чем остановилось дело?
> 
> Обновлял в начале уже этого года сервер с софтверным raid1 (x86_64, полный
> dist-upgrade из сизифа, из важного: bootloader-utils, coreutils, grub2-pc,
> udev, ядро до ovz-el-alt108) после чего система перестала грузиться И с обоих
> дисков и с каждого в отдельности с идентичной руганью:
> 
> initrd: processing kernel events (ДОЛГАЯ пауза)
> initrd: loop: ERROR: /root: not mounted
> initrd: stage 'loop' failed
> initrd: this shell remains here for debug purposes. Press ctrl-d to continue
> (initparams)
> 
> старое ядро ovz-el-alt104 при этом тоже не грузится, так же.
> 
> (тогда ещё не читал этого бага) ок, запускаю с флешки, монтирую всё в чрут,
> смотрю: старый initrd не обновлялся (логично), от нового он качественно
> отличается только тем, что одно правило удева для сборки mdadm-массивов разбито
> на два файла, остальные изменения это размер и сонеймы нескольких библиотек.
> 
> Поднял из этого чрута сеть, обновил ядро до ovz-el-alt109 (теже изменения в
> initrd относительно alt104), перезагружаюсь - не помогло, синдромы те же.
> 
> Поскольку перестало грузиться и старое ядро/initrd, я грешу только на
> сломавшийся udev.

Можно каким-нибудь образом добыть версии пакетов, с которыми "все еще работало",
и версии пакетов, с которыми перестало работать?

Похоже, это действительно про --incremental.

<vsu> gvy: вообще там и у других костыли
<vsu> gvy: см., например, https://launchpad.net/ubuntu/+archive/primary/+files/mdadm_3.2.5-5ubuntu2.debian.tar.bz2
<vsu> gvy: debian/initramfs/
<vsu> gvy: там всякие add_mountroot_fail_hook "10-mdadm" торчат
<vsu> gvy: т.е., оно сначала должно висеть и дожидаться появления всех дисков
<vsu> gvy: и только после вываливания по таймауту либо задать вопрос, либо при наличии bootdegraded=yes в командной строке ядра автоматически запустить то, что осталось
<vsu> gvy: mdadm --incremental --run --scan || mdadm --assemble --scan --run
<vsu> gvy: а при ручном сборе, скорее всего, просто отвалившийся диск выкидывается из метаданных, и его уже не ждут при загрузке
<gvy> vsu, ага, вот я тоже заметил около дебунты подобные шорохи и на той неделе начал думать в сторону --run в рулесах или постобработчике каком
<vsu> gvy: ну это, собственно, закономерные следствия перехода на --incremental
<vsu> gvy: каким-то образом нужно определять, что остальные диски отвалились уже совсем
<vsu> gvy: причём та же убунта по умолчанию в такой ситуации грузиться не будет
<gvy> vsu, ну про волшебное слово для загрузки с полудохлого рейда у них видел, но это imho махрово-десктопный подход
<gvy> т.е. лучше догрузиться, пока это возможно, и дальше уже пытаться обратить внимание

(В ответ на комментарий №45)
> Можно каким-нибудь образом добыть версии пакетов, с которыми "все еще
> работало", и версии пакетов, с которыми перестало работать?
Не исключено, что это mdadm < 3.1.3 и mdadm >= 3.1.3.

https://wiki.ubuntu.com/ReliableRaid
http://www.mail-archive.com/initramfs@vger.kernel.org/msg00978.html
https://git.kernel.org/cgit/boot/dracut/dracut.git/commit/?id=ecc13ef17e376c4ee54a2177687ef018466f53ca

Предлагается полумасляный вариант с участием кусков dracut:
65-md-incremental-imsm.rules (с мелкой правкой на скору руку)
mdraid_start.sh (strstr() влинкован статиком)
и копией системных mdraid rules с выкинутым RUN.*incremental по тем же мотивам.

В этих кусках содержится движение в одну из тех сторон, о которых говорили с legion@, только уже навелосипеденное до нас: аварийный дозапуск mdadm -R на то, что оказалось inactive после попытки поднять инкрементально.

Уже тоже грузится с рабочего массива и выпадает через 180 сек в initramfs shell, но ещё не запускает /sbin/mdraid_start.sh по невыясненным причинам (если запустить руками вместо 65-md-incremental-imsm.rules, дальше можно монтировать корень и запускать init)

Желающим увидеть в разобранном виде: http://git.altlinux.org/people/mike/packages/?p=make-initrd.git;a=shortlog;h=refs/heads/28879 (также могу выгрузить подготовленный для тестов raid.ova куда-нибудь, это 159K).

(В ответ на комментарий №48)
> Желающим увидеть в разобранном виде:
> http://git.altlinux.org/people/mike/packages/?p=make-initrd.git;a=shortlog;h=refs/heads/28879

В 65-md-incremental-imsm.rules ты прописал /sbin/mdraid_start а не mdraid_start.shю

Насчёт mdraid_start.sh:

Ты (ты же его коммитил) в /dev/md* усиленно выясняешь их пути в sysfs.
Почему бы тебе не идти сразу по /sys и смотреть на устройства раз уж ты всё равно двигаешься по всем рейдам ?

В общем, с этим вот безобразием грузится (/home на LVM чувствует себя нормально, надо ещё проверить / на LVM/LUKS/LVM+LUKS).

mdadm --assemble --scan не работает, т.к. часть устройств уже включена в состав массивов и потому занята (см. с --verbose при желании).  Поэтому добиваем --incremental --run --scan.

Вообще говоря, хорошо бы фильтровать ARRAY в mdadm.conf, попадающем в initrd -- там нужны / и swap (resume).  Возможно, ещё /usr (надо уточнить у shaba@).

Для помещения в p7/branch надо как минимум:
- сделать вызывалку
- вынести собственно код в features/mdadm/
- поменять 600 децисекунд на ручку вроде RAIDDELAY

Собственно, безобразие: http://git.altlinux.org/people/mike/packages/?p=make-initrd.git;a=commitdiff;h=0942f589ae16eb7a987eecdc84775c751f97f61d

make-initrd-0.8.6-alt1.M70P.1 -> p7:

* Mon Feb 10 2014 Michael Shigorin <mike@altlinux> 0.8.6-alt1.M70P.1
- Add mdadm trouble handler (closes: #28879).

(В ответ на комментарий №51)
> Собственно, безобразие:
> http://git.altlinux.org/people/mike/packages/?p=make-initrd.git;a=commitdiff;h=0942f589ae16eb7a987eecdc84775c751f97f61d

Добрый день!
Подтверждаю, что после выхода из строя массива, при загрузке система ждет и загружается.
Но загрузка происходит не корректно.

[root@srv1 ~]# df
Filesystem      Size  Used Avail Use% Mounted on
udevfs          5.0M     0  5.0M   0% /dev
runfs           5.0M  452K  4.6M   9% /run
/dev/md4        104G  5.5G   94G   6% /
shmfs           1.8G     0  1.8G   0% /dev/shm
tmpfs           1.8G     0  1.8G   0% /tmp
/dev/sda3       804G  371G  393G  49% /home

[root@srv1 ~]# cat /proc/mdstat
Personalities : [raid1]
md5 : inactive sdb3[0](S)
      856313792 blocks

md4 : active raid1 sdb2[2] sda2[1]
      110828480 blocks [2/1] [_U]
      [===========>.........]  recovery = 55.1% (61080000/110828480) finish=8.5min speed=97104K/sec

md3 : active raid1 sdb1[0] sda1[1]
      9616320 blocks [2/2] [UU]

unused devices: <none>

[root@srv1 ~]# grub-autoupdate
Updating grub on /dev/sdb
error: cannot read `/dev/sda': Input/output error.
error: cannot read `/dev/sda': Input/output error.
error: cannot read `/dev/sda': Input/output error.
error: cannot read `/dev/sda': Input/output error.

[root@srv1 ~]#  mdadm --run /dev/md5
mdadm: started /dev/md5
[root@srv1 ~]# cat /proc/mdstat
Personalities : [raid1]
md5 : active raid1 sdb3[0]
      856313792 blocks [2/1] [U_]

md4 : active raid1 sdb2[0] sda2[1]
      110828480 blocks [2/2] [UU]

md3 : active raid1 sdb1[0] sda1[1]
      9616320 blocks [2/2] [UU]

unused devices: <none>
[root@srv1 ~]# mdadm /dev/md5 -a /dev/sda3
mdadm: Cannot open /dev/sda3: Device or resource busy

т.е. md5 мы вроде бы как подняли, но если перезагрузить машину, то в /home опять будет sda3, а md5 будет поврежден.

По идее же md3, md4 подцепились нормально, почему md5 не встал на место и как теперь это чинить? Проблема еще в том, что я могу только удаленно что-то делать.

http://forum.altlinux.org/index.php/topic,29917.0.html