После установки системы с /usr на lvm на raid6, при первом запуске raid6 не поднялся. Массив был в состоянии active not running, он не поднимался по mdadm --assemble --scan с кодом возврата 2, даже после принудительной загрузки незагруженного модуля raid456, однако поднимался как mdadm --run /dev/sdb. Проблему решило перегенерация initrd, туда включился модуль raid456. инсталлятор почему-то это не сделал. с другой стороны, вроде он для /usr не особо нужен в initrd, может, какие-нибудь заморочки с udev c передачей устройств из initrd. Это был старый добрый sysV-init.
С ядром 3.8.12-std-def-alt1 и udev-201-alt1 все рейды оказываются подняты раньше, чем выполняется /etc/rc.d/scripts/raidstart, который всё равно выполняется. Возможны races, с вываливанием ошибки инициализации рейдов.
(В ответ на комментарий №1) > Возможны races, с вываливанием ошибки инициализации рейдов. точнее массив не успевает до конца инициализироваться, он поднят, но в состоянии inactive. И натравливание на него mdadm -As в таком состоянии ведёт к ошибке (кажется, 2), и невозможности дальнейшего поднятия массива через --run. А у этого свои побочные эффекты - не подцепляются внешние bitmaps. Если в raidstart в функцию start_raid_using_mdadm добавить диагностику с значительной паузой: if [ -x "$f" ]; then echo -n "(using mdadm) " echo "debug" cat /proc/mdstat echo --------- sleep 10s cat /proc/mdstat echo --------- "$f" --assemble --scan return $? fi то мы увидим картину, как в приложенном скриншоте
Created attachment 5820 [details] скриншот долгой инициализации массива
милая особенность моей конфигурации: 4 из 8 дисков, входящих в массив, контролируются модулем isci, который отличается долгой инициализацией. Если его не включать в initrd, то нужно делать долгую паузу перед инициализацией массива. Если его включить в initrd, то всё долго тормозит там ("loop: Running md_run handler"). и на ядре std-def-3.8.10 это даже приводило к аварийной консоли из-за (initrd): Stage 'killall' failed
