Добрый день! Установил бету 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 и перезагрузка.
Насколько я понимаю, это скорее к 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
