Created attachment 8510 [details] dmesg log При сборке RAID ещё не появились устройства от внешнего контроллера и RAID собирается в битом виде. Порядок в dmesg такой: [ 8.568518] scsi 5:0:0:0: Direct-Access ATA WDC WD1001FALS-0 1D05 PQ: 0 ANSI: 5 [ 8.570999] sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/466 GiB) ... [ 8.812807] md/raid1:md10: active with 1 out of 2 mirrors [ 8.813668] md10: detected capacity change from 0 to 500106723328 ... [ 13.040681] scsi host9: ioc0: LSISAS1068E B3, FwRev=01210000h, Ports=1, MaxQ=483, IRQ=34 [ 13.080163] mptsas: ioc0: attaching sata device: fw_channel 0, fw_id 6, phy 0, sas_addr 0x857f3322a091938d [ 13.085145] scsi 9:0:0:0: Direct-Access ATA WDC WD1001FALS-0 1D05 PQ: 0 ANSI: 5 [ 13.085489] scsi 9:0:0:0: Power-on or device reset occurred [ 13.095582] mptsas: ioc0: attaching sata device: fw_channel 0, fw_id 4, phy 1, sas_addr 0x73853822a4a69892 [ 13.100668] scsi 9:0:1:0: Direct-Access ATA WDC WD1003FBYX-0 1V01 PQ: 0 ANSI: 5 [ 13.101408] scsi 9:0:1:0: Power-on or device reset occurred [ 13.103662] sd 9:0:0:0: [sde] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB) Лог загрузки приложен. Буду признателен за совет по объезду и по правильному решению проблемы.
Проверено, что если initrd не пересоздать после добавления нового массива в /etc/mdadm.conf, то он не будет создан с определённым /dev/mdX в initrd, а соберётся позже как /dev/md127 (из двух дисков). Это опровергает гипотезу, что массив не собирается потому что некорректно разобран при выключении. Остаётся неясным, а) почему никто не ждёт появления всех дисков, чтобы начать сборку б) почему диски не добавляются в массив по мере появления.
покажите что у вас в /etc/mdadm.conf ?
(Ответ для Alexey Gladkov на комментарий #2) > покажите что у вас в /etc/mdadm.conf ? # cat /etc/mdadm.conf ... MAILADDR root PROGRAM /sbin/mdadm-syslog-events DEVICE partitions ARRAY /dev/md4 metadata=1.2 UUID=48a8b4f6:6d48dd85:350c1fb0:166832ef ARRAY /dev/md6 metadata=1.2 UUID=dbb58427:c345cb5e:88ad6810:fc79d73e ARRAY /dev/md5 metadata=1.2 UUID=bb3614d5:7c6833c1:e7a1971f:f4840b10 ARRAY /dev/md1 metadata=0.90 UUID=24dabf5a:c5a6ae9a:af9c670f:4765e0d1 ARRAY /dev/md2 metadata=0.90 UUID=4897d400:9291ba6b:8bd99fc9:de48af39 #INACTIVE-ARRAY /dev/md122 metadata=0.90 UUID=0687566e:d65f5ca6:db6af4b1:307d278e ARRAY /dev/md10 metadata=0.90 UUID=56eda4e4:1a0cbc55:4c46a314:a514544e ARRAY /dev/md3 level=raid1 num-devices=2 metadata=1.2 UUID=7a646703:65bee733:d06d7682:7e44a9a3
ну, кажется, понятно. У вас много рейдов в конфиге, а initrd не ждёт всех. Он по умолчанию ждёт только рут.
(Ответ для Alexey Gladkov на комментарий #4) > ну, кажется, понятно. У вас много рейдов в конфиге, а initrd не ждёт всех. > Он по умолчанию ждёт только рут. Тем не менее, он собирает рут на одном диске, хотя их три в массиве. Если ему нужен только рут, зачем он собирает остальные. Я не просто не понимаю, как выбраться из этой ситуации. В p8 с make-initrd-0.8.16-alt3 такой проблемы нет. Здесь p9 и make-initrd-2.4.0-alt1
(Ответ для Vitaly Lipatov на комментарий #5) > Тем не менее, он собирает рут на одном диске, хотя их три в массиве. > Если ему нужен только рут, зачем он собирает остальные. Если речь о том, зачем initrd собирает все остальные рейды, то initrd в момент загрузки не знает какой рейд собирать. udev видит диски с вызывает mdadm пока не появится девайс с файловой системой и запрашиваемым в root= UUID/LABEL. Как только рутовый раздел становится доступен initrd прекращает сборку рейдов и передаёт управление системному init. > Я не просто не понимаю, как выбраться из этой ситуации. Попробуйте сделать для initrd свой отдельный mdadm.conf с только рутовым массивом. > В p8 с make-initrd-0.8.16-alt3 такой проблемы нет. Здесь p9 и > make-initrd-2.4.0-alt1
(Ответ для Alexey Gladkov на комментарий #6) > (Ответ для Vitaly Lipatov на комментарий #5) > > Тем не менее, он собирает рут на одном диске, хотя их три в массиве. > > Если ему нужен только рут, зачем он собирает остальные. > > Если речь о том, зачем initrd собирает все остальные рейды, то initrd в > момент загрузки не знает какой рейд собирать. udev видит диски с вызывает > mdadm пока не появится девайс с файловой системой и запрашиваемым в root= > UUID/LABEL. Как только рутовый раздел становится доступен initrd прекращает > сборку рейдов и передаёт управление системному init. Но в итоге он собирает массив из одного диска, потому что остальные диски появляются секундой позже. > > > Я не просто не понимаю, как выбраться из этой ситуации. > > Попробуйте сделать для initrd свой отдельный mdadm.conf с только рутовым > массивом. Это явно поможет, но там где-то произойдёт автосборка (причём опять же в initrd?), и массивы будут с левыми номерами.
(Ответ для Vitaly Lipatov на комментарий #7) > Но в итоге он собирает массив из одного диска, потому что остальные диски > появляются секундой позже. Я полагаю, что диски у вас инициализируются дольше, чем таймаут, после которого выполняется mdadm -IR. Тут тонкий момент с таймаутами. Если не пытаться грузиться с деградированным рейдом, то при выходе из строя диска загрузится не получится вообще. Но если диски инициализируются достаточно долго, то может вот такая ситуация, когда диски не успевают вовремя появиться. > > Попробуйте сделать для initrd свой отдельный mdadm.conf с только рутовым > > массивом. > Это явно поможет, но там где-то произойдёт автосборка (причём опять же в > initrd?), и массивы будут с левыми номерами. Интересно. Вроде бы mdadm не должен делать автодетект делать без разрешения. На всякий случай, можете показать содержимое /var/lib/initrd/`uname -r`.initrd/features ?
(Ответ для Alexey Gladkov на комментарий #8) > (Ответ для Vitaly Lipatov на комментарий #7) > > Но в итоге он собирает массив из одного диска, потому что остальные диски > > появляются секундой позже. > > Я полагаю, что диски у вас инициализируются дольше, чем таймаут, после > которого выполняется mdadm -IR. Судя по логу, у меня это 5 секунд. > Тут тонкий момент с таймаутами. Если не пытаться грузиться с деградированным > рейдом, то при выходе из строя диска загрузится не получится вообще. Но если Согласен, пытаться нужно, это правильно. > диски инициализируются достаточно долго, то может вот такая ситуация, когда > диски не успевают вовремя появиться. Может быть, таймаут настраивается? Примерно как rootdelay. > > > > Попробуйте сделать для initrd свой отдельный mdadm.conf с только рутовым > > > массивом. > > Это явно поможет, но там где-то произойдёт автосборка (причём опять же в > > initrd?), и массивы будут с левыми номерами. > > Интересно. Вроде бы mdadm не должен делать автодетект делать без разрешения. > > На всякий случай, можете показать содержимое /var/lib/initrd/`uname > -r`.initrd/features ? # uname -r 5.4.17-un-def-alt1 # cat /var/lib/initrd/`uname -r`.initrd/features add-modules buildinfo cleanup compress kbd mdadm network rdshell rootfs system-glibc ucode
Я совершенно согласен, что это очень неприятная регрессия. Я постараюсь как можно оперативнее придумать решение.
Можете проверить бранч[1] с предполагаемым фиксом ? [1] http://git.altlinux.org/people/legion/packages/make-initrd.git?p=make-initrd.git;a=shortlog;h=refs/heads/fix-mdadm-timeout
В сизиф ушёл make-initrd-2.5.0-alt1. В нём применяется скользящий таймаут т.е. таймаут отсчитывается от последнего инициализированного диска (raid_member). По умолчанию этот таймаут 10 секунд, но его можно изменить через параметр загрузки raid-member-delay=<SECS>.
(Ответ для Alexey Gladkov на комментарий #11) > Можете проверить бранч[1] с предполагаемым фиксом ? > > [1] > http://git.altlinux.org/people/legion/packages/make-initrd.git?p=make-initrd. > git;a=shortlog;h=refs/heads/fix-mdadm-timeout При сборке: warning: Installed (but unpackaged) file(s) found: /usr/libexec/make-initrd/mi-file Поставил пакеты, в /etc/sysconfig/grub2 вписал ожидание -GRUB_CMDLINE_LINUX_DEFAULT='panic=30 splash' +GRUB_CMDLINE_LINUX_DEFAULT='panic=30 raid-member-delay=5' выполнил # make-initrd # update-grub и сборка прошла успешно Перезагрузил — RAID собрался полностью. Работает!
Created attachment 8652 [details] dmesg успешной загрузки
(Ответ для Vitaly Lipatov на комментарий #13) > При сборке: > warning: Installed (but unpackaged) file(s) found: > /usr/libexec/make-initrd/mi-file Спасибо большое! Я проглядел это.
Created attachment 8825 [details] dmesg md/raid1:md0: active with 1 out of 3 mirrors Снова натолкнулся на то, что массив собирается раньше, чем появятся все его диски. Причём при горячей перезагрузке этого нет. Время примерно такое, то есть без пауз: ... [ 2.424628] sd 4:0:1:0: [sda] Attached SCSI disk [ 2.438645] ata4: SATA link down (SStatus 0 SControl 300) [ 2.441554] md: Autodetecting RAID arrays. [ 2.441834] md: autorun ... [ 2.441860] md: running: <sda1> [ 2.445033] md/raid1:md0: active with 1 out of 3 mirrors ... [ 2.593610] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ... [ 2.874187] md: md0 already running, cannot run sdb1 make-initrd-2.5.0-alt1 ядро 4.19.84-std-def-alt1
(Ответ для Vitaly Lipatov на комментарий #16) > Создано вложение 8825 [details] [подробности] > dmesg md/raid1:md0: active with 1 out of 3 mirrors > > Снова натолкнулся на то, что массив собирается раньше, чем появятся все его > диски. Причём при горячей перезагрузке этого нет. Время примерно такое, то > есть без пауз: > > ... > [ 2.424628] sd 4:0:1:0: [sda] Attached SCSI disk > [ 2.438645] ata4: SATA link down (SStatus 0 SControl 300) > [ 2.441554] md: Autodetecting RAID arrays. > [ 2.441834] md: autorun ... > [ 2.441860] md: running: <sda1> > [ 2.445033] md/raid1:md0: active with 1 out of 3 mirrors > ... > [ 2.593610] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) > ... > [ 2.874187] md: md0 already running, cannot run sdb1 > > > make-initrd-2.5.0-alt1 > ядро 4.19.84-std-def-alt1 Интересно. А до этого работало ?
(Ответ для Alexey Gladkov на комментарий #17) ... > > [ 2.874187] md: md0 already running, cannot run sdb1 > > > > > > make-initrd-2.5.0-alt1 > > ядро 4.19.84-std-def-alt1 > > Интересно. А до этого работало ? Я почти уверен, что причина в том, что рейд развален аварийным выключением, поэтому и не собирается. Просто из этого лога не видно, почему он так поспешил собраться. Поскольку глючность компьютера подтвердилась, проблемы нет, разве что в информативности.
