Bug 28879 - Не загружается при отсутствии диска в raid1
: Не загружается при отсутствии диска в raid1
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/make-initrd)
: unstable
: all Linux
: P3 major
Assigned To:
:
:
:
:
: 27685
  Show dependency tree
 
Reported: 2013-04-22 09:18 by
Modified: 2019-01-06 17:27 (History)


Attachments
Скриншот kernel panic при отключении второго диска (1.33 MB, image/jpeg)
2013-05-06 10:40, rotkart
no flags Details
mdadm и не нахождение флешки (553.86 KB, image/jpeg)
2013-08-15 07:10, Pavel V. Sumin
no flags Details
mdstat (238.85 KB, image/jpeg)
2013-08-15 07:13, Pavel V. Sumin
no flags Details
концовка dmesg (598.88 KB, image/jpeg)
2013-08-15 07:14, Pavel V. Sumin
no flags Details
попытка активации (589.51 KB, image/jpeg)
2013-08-16 05:53, Pavel V. Sumin
no flags Details
попытка запуска (609.14 KB, image/jpeg)
2013-08-16 05:55, Pavel V. Sumin
no flags Details
попытка запуска №2, удачная (508.55 KB, image/jpeg)
2013-08-16 06:36, Pavel V. Sumin
no flags Details
доломал массив (510.98 KB, image/jpeg)
2013-08-19 09:44, Pavel V. Sumin
no flags Details


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2013-04-22 09:18:10
Добрый день!
Установил бету Centaurus 20130416 на ПК с мат. платой  ASROCK H61M-GE и двумя
винчестерами по 500Gb в режиме EFI.
При установке выбрал серверный профиль авторазбивки , который собрал мне из
этих хардов raid1.

 Вывод gdisk -l для
 sda:

Number  Start (sector)    End (sector)  Size       Code  Name
    1           16065          530144   251.0 MiB   EF00
    2          530145          546209   7.8 MiB     EF02
    3          546210        30603824   14.3 GiB    0700
    4        30603825        45592469   7.1 GiB     0700
    5        45592470       976768064   444.0 GiB   0700

sdb:

Number  Start (sector)    End (sector)  Size       Code  Name
    1           16065        30073679   14.3 GiB    0700
    2        30073680        45062324   7.1 GiB     0700
    3        45062325       976768064   444.3 GiB   0700

Зеркала получились такие:

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]

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

Итог: загрузчик _только_ на sda, отключаю шлейф от второго диска для имитации
его выхода из строя.
Система с первого диска не грузится - останавливается на этапе:

 chdir: /etc/syslog.d: No such file or directory
 initrd: loop: ERROR: /root: not mounted
 initrd: stage `loop` failed
 initrd: This shell remains here for debug purposes. Press Ctrl-D to continue.
 (initramfs)

По нажатии просимой комбинации - Kernel panic и перезагрузка.
------- Comment #1 From 2013-04-23 17:51:59 -------
Насколько я понимаю, это скорее к make-initrd, чем к ядру.
------- Comment #2 From 2013-05-01 21:59:17 -------
(В ответ на комментарий №1)
> Насколько я понимаю, это скорее к make-initrd, чем к ядру.

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

2boyarsh: это, полагаю, блокер для Кентавра. Если не согласны, напшите.
------- Comment #3 From 2013-05-01 23:34:49 -------
(В ответ на комментарий №2)
> (В ответ на комментарий №1)
> > Насколько я понимаю, это скорее к make-initrd, чем к ядру.
> 
> 2legion: согласны?

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

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

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

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

Если уточните, где, после установки, можно будет посмотреть параметры сборки
образа initrd - буду премного благодарен!
------- Comment #6 From 2013-05-02 15:33:35 -------
(В ответ на комментарий №5)
> Если уточните, где, после установки, можно будет посмотреть параметры сборки
> образа initrd - буду премного благодарен!

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

1. Какие параметры передаются при загрузке ядру ?
2. Какая версия make-initrd ?
3. Какие модули make-initrd-* были при сборке ?
4. Можно взглянуть на /etc/initrd.mk ?
------- Comment #7 From 2013-05-06 10:36:13 -------
(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
------- Comment #8 From 2013-05-06 10:40:21 -------
Created an attachment (id=5818) [details]
Скриншот kernel panic при отключении второго диска
------- Comment #9 From 2013-05-06 10:45:23 -------
Ой, из моего #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
------- Comment #10 From 2013-05-06 10:53:15 -------
После того как диск вернули и смогли загрузиться в систему, покажите пожалуйста
вывод команды:

$ blkid -c /dev/null
------- Comment #11 From 2013-05-06 12:15:19 -------
(В ответ на комментарий №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"
------- Comment #12 From 2013-08-14 06:09:07 -------
Образ с оффсайта: 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)
------- Comment #13 From 2013-08-14 08:33:18 -------
Такая-же ситуация возникает, если поменять при установке SysVinit на Systemd.
При отсутствии одного из винтов, все встает колом.
------- Comment #14 From 2013-08-14 15:37:06 -------
Я попробовал сымитировать эту ситуацию в 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
------- Comment #15 From 2013-08-15 07:10:52 -------
Created an attachment (id=5908) [details]
mdadm и не нахождение флешки
------- Comment #16 From 2013-08-15 07:13:02 -------
Created an attachment (id=5909) [details]
mdstat
------- Comment #17 From 2013-08-15 07:14:25 -------
Created an attachment (id=5910) [details]
концовка dmesg
------- Comment #18 From 2013-08-15 07:22:32 -------
(В ответ на комментарий №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 по Мск, готов выступить тестером и помочь
разобраться с проблемой под руководством, например с видео по скайпу, опытных
товарищей :).
------- Comment #19 From 2013-08-15 14:06:03 -------
Ага, спасибо, в процессе разбирательства в отличиях dmesg, я понял, что
воспроизводил проблему на слишком старом образе, попробую повторить, пока dmesg
и прочей информации достаточно.
------- Comment #20 From 2013-08-15 15:33:15 -------
Мне удалось воспроизвести проблему, правда для этого мне пришлось выдёргивать
диски поочерёдно (до этого всё грузилось). После выдёргивания сначала второго,
возвращения его и выдёргивания первого диска (без efi этот номер проходит) я
получил очень похожее выпадание в (initramfs) с очень похожим mdstat.

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

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

Видимо, в make-initrd надо вставить mdadm --run (причём от лишнего его запуска
вреда не будет, кроме сообщения об ошибке) перед монтированием того, что лежит
на этом raid.
------- Comment #21 From 2013-08-15 15:40:53 -------
проблема в том, что в make-initrd-mdadm не видно никакого места, куда этот
mdadm --run можно было бы воткнуть..
------- Comment #22 From 2013-08-15 15:53:35 -------
> Запуск mdadm --run /dev/mdX переводит raid в состояние active,degraded, и,
> вероятно, с него можно было бы загрузиться, вручную смонтировав / и запустив
> init.
Таки да, если после mdadm --run /dev/mdX сделать
mount /dev/mdX /root
exec /root/sbin/init то загрузка проходит.
------- Comment #23 From 2013-08-16 05:53:58 -------
Created an attachment (id=5911) [details]
попытка активации
------- Comment #24 From 2013-08-16 05:55:20 -------
Created an attachment (id=5912) [details]
попытка запуска
------- Comment #25 From 2013-08-16 06:36:14 -------
Created an attachment (id=5913) [details]
попытка запуска №2, удачная
------- Comment #26 From 2013-08-16 08:15:30 -------
В чем разница между первой и второй попыткой я не понял, но система стартанула.
Причем, если систему опять перегрузить, то она стартует более-менее НОРМАЛЬНО
(см примечания) и при одном винте. Видимо надо, при аварийном запуске всего
лишь правильно перемонтировать райд и рестартовать систему.

Примечание 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 сервера. Проверял на двух
установках. Но, в итоге, эти пакеты все равно ставятся. Но в автозапуске не
стоят. Может и не стоит их устанавливать-то, раз нее просят.

Чуть позже отпишусь о попытке восстановления райда при подключении чистенького
винта.
------- Comment #27 From 2013-08-16 13:05:18 -------
Все восстановил по инструкции. После восстановления зеркала, ошибка подключения
свап раздела тоже пропала. Думаю это связанно с тем, что 
[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]
 у него разделы с разных винтов чередуются. И он, по ошибке, зачем-то пытался
свап поднять с отключенного винта. Но это только предположение.
------- Comment #28 From 2013-08-16 13:57:16 -------
(В ответ на комментарий №26)
> В чем разница между первой и второй попыткой я не понял, но система стартанула.
Разница в монтировании в /root md5 и md4 соответственно. Очевидно, что на /home
нет /sbin/init :D
------- Comment #29 From 2013-08-19 09:44:03 -------
Created an attachment (id=5914) [details]
доломал массив
------- Comment #30 From 2013-08-19 09:52:56 -------
Т.е. я восстановил райд, перепрописал загрузчик. Перегрузился, все работало.
Отключил ПЕРВЫЙ винт(тот, который оставался в массиве при первом опыте и с
которого все восстанавливалось).
Система не поднималась, как и в прошлый раз.
Проделываем финты:
mdadm --run /dev/md4 
mount /dev/mdX /root
exec /root/sbin/init
И получаем скрин.
------- Comment #31 From 2013-08-19 14:58:44 -------
Что интересно, если mdadm умышленно сказать, что какой-то из разделов в RAID
сбойный, то загрузка проходит нормально. Например:

mdadm /dev/md0 -f /dev/sda1

Но, если отключить диск физически, тогда такая же ошибка, что выше описали.
------- Comment #32 From 2013-08-20 09:34:01 -------
Отключал по очереди sda, sdb. Не грузится никак. Только парно. Жестко как-то.
------- Comment #33 From 2013-10-14 21:14:33 -------
(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...
------- Comment #34 From 2013-10-15 10:41:45 -------
Проверил на своей конфигурации, тоже не загружается. По умолчанию установка
загрузчика предлагалась на sda, очевидно, на sdb он не прописался. У меня /boot
на отдельном /dev/md0 (правда, я ещё и EFI не использую), наверное, стоило
предлагать установку туда по-умолчанию. И, сразу, восстанавливать mbr на всех
дисках, на всякий случай.
------- Comment #35 From 2013-10-15 11:28:43 -------
И bootable flag на sdb1 не поставился...
Кстати, может второй баг создать с такой же темой, для обсуждения инсталлятора
? А то мои комментарии к initrd отношения не имеют...
------- Comment #36 From 2013-10-15 13:58:37 -------
(В ответ на комментарий №34)
> Проверил на своей конфигурации, тоже не загружается. По умолчанию установка
> загрузчика предлагалась на sda, очевидно, на sdb он не прописался.
Очевидно, куда сказано, туда и встал.

> У меня /boot на отдельном /dev/md0 (правда, я ещё и EFI не использую)
С EFI пока известно, что не работает (и не совсем понятно, что с этим делать). 
Этот баг -- именно о том.  О другом стоит и вешать другой.
------- Comment #37 From 2013-10-15 16:49:17 -------
(In reply to comment #36)

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

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

Очевидно. Но не очень правильно в плане выбора. :-) Bug 29480.
И из исходного сообщения тут Bug 29481.
------- Comment #38 From 2013-10-15 22:29:26 -------
(В ответ на комментарий №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 на обоих дисках и грузится. Но только с двумя хардами. При
отключении одного из них я и поймал этот баг с зеркалами. Жду, может починят.
------- Comment #39 From 2013-11-28 09:37:58 -------
(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 странно выглядят.
------- Comment #40 From 2014-01-10 22:33:13 -------
На чем остановилось дело?

Обновлял в начале уже этого года сервер с софтверным 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. Это вообще актуальный компонент?
------- Comment #41 From 2014-01-22 09:10:36 -------
Поймал вчера на другой машине, уже std-pae, i586. Помогла загрузка с флешки
удаление умершего диска из рейда.

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

Непонятно тогда, зачем нужен такой рейд, что ничего делать на одном диске не
дает без ручного вмешательства.
------- Comment #42 From 2014-01-22 13:36:48 -------
Надо воспроизводить на стенде и думать, что делать.  Боюсь, до конференции
(ближайшие выходные) маловероятно.
------- Comment #43 From 2014-01-31 19:34:26 -------
(В ответ на комментарий №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 повесить другую.
------- Comment #44 From 2014-02-01 02:35:19 -------
(В ответ на комментарий №21)
> проблема в том, что в make-initrd-mdadm не видно никакого места, куда этот
> mdadm --run можно было бы воткнуть..
features/raid/data-extra/etc/udev/rules.d/64-md-raid.rules ?
------- Comment #45 From 2014-02-01 03:05:12 -------
(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.

Можно каким-нибудь образом добыть версии пакетов, с которыми "все еще
работало",
и версии пакетов, с которыми перестало работать?
------- Comment #46 From 2014-02-03 19:38:42 -------
Похоже, это действительно про --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> т.е. лучше догрузиться, пока это возможно, и дальше уже пытаться обратить
внимание
------- Comment #47 From 2014-02-06 02:50:05 -------
(В ответ на комментарий №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
------- Comment #48 From 2014-02-06 05:12:47 -------
Предлагается полумасляный вариант с участием кусков 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).
------- Comment #49 From 2014-02-06 12:34:21 -------
(В ответ на комментарий №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 и смотреть на устройства раз уж ты всё
равно двигаешься по всем рейдам ?
------- Comment #50 From 2014-02-08 01:00:59 -------
В общем, с этим вот безобразием грузится (/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
------- Comment #51 From 2014-02-08 01:02:21 -------
Собственно, безобразие:
http://git.altlinux.org/people/mike/packages/?p=make-initrd.git;a=commitdiff;h=0942f589ae16eb7a987eecdc84775c751f97f61d
------- Comment #52 From 2014-02-10 21:28:10 -------
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).
------- Comment #53 From 2015-05-31 20:31:54 -------
(В ответ на комментарий №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 не встал на место и как
теперь это чинить? Проблема еще в том, что я могу только удаленно что-то
делать.
------- Comment #54 From 2015-05-31 20:34:34 -------
http://forum.altlinux.org/index.php/topic,29917.0.html