Всем здравствуйте! Столкнулся вот с такой проблемой- при старте не стартует RAID1. Система- Centaur 7.0.2 x64, созданы следующие разделы / 100 гбайт RAID10 /var 200 гбайт RAID10 /boot 5 гбайт RAID1 При старте системы она выпадает в консоль с сообщением о неработоспособности RAID. При проверке выясняется, что RAID1 в состоянии inactive. Если массив "дернуть"- mdadm -S /dev/md0 mdadm -A /dev/md0 он нормально стартует. В dmesg сообщение - md: personality for level 1 is not loaded! Я так понимаю, не подгружен модуль RAID1, который загружается позже. Аналогичная ситуация, если в качестве раздела для /boot указать RAID5.
Обновляли систему и ядро до текущего p7?
Да, система обновлена до текущего P7
Решил вопрос предзагрузкой модуля RAID1 в initrd. Заметил, что при запуске make-initrd в списке модулей присутствует только RAID10. Отредактировал initrd.mk: AUTODETECT = all MODULES_ADD +=raid1 MODULE_PRELOAD +=raid1 FEATURES +=add-modules Еще раз запустил make-initrd, на этот раз в выхлопе присутствовал RAID1. На перезагрузке массив без проблем стартовал.
Думаю, что проблема в make-initrd и, скорее всего, общая в Сизифе и в p7.
(В ответ на комментарий №4) > Думаю, что проблема в make-initrd и, скорее всего, общая в Сизифе и в p7. Мне известна проблема с рейдами (возможно это новая проблема) и у меня есть лишь временное решение. В каких-то бранчах mike@ делал изменения в make-initrd для сборки рейда, которых нет в сизифе.
> В каких-то бранчах mike@ делал изменения в make-initrd для сборки рейда, > которых нет в сизифе. Тут, насколько я понимаю, проблема не в сборке как таковой, а в автоугадаве модулей -- модуль raid1 не попадает в initrd.
asket@, приложите пожалуйста результат команды "make-initrd bug-report".
[root@PTG ~]make-initrd bug-report cp: cannot stat ?/etc/blkid.tab? :no such file or directory make: *** [bug-report] Error 1
(В ответ на комментарий №8) > [root@PTG ~]make-initrd bug-report > cp: cannot stat ?/etc/blkid.tab? :no such file or directory > make: *** [bug-report] Error 1 Эээ... Первый раз вижу машину у которой нет /etc/blkid.tab Утилита blkid что говорит ?
[root@PTG-SS ~]# blkid /dev/sda1: UUID="ef68da5f-824c-f25e-2e47-f50042486179" UUID_SUB="4993c973-6602-8c01-f60a-ad177516f764" LABEL="md4" TYPE="linux_raid_member" /dev/sda2: UUID="7be9132a-9c56-6e28-ca18-8b60cfaffb2c" UUID_SUB="48826849-e62f-3e78-b383-fd2080cbc46a" LABEL="md0" TYPE="linux_raid_member" /dev/sda3: UUID="37d02c72-506a-a979-d1b2-8b7a42b5414a" UUID_SUB="3adeaf10-6ab6-6c0a-63f9-ea3961428820" LABEL="md6" TYPE="linux_raid_member" /dev/sda5: UUID="7fccb456-b92c-806b-0d4c-815f4baa6422" UUID_SUB="d9fcdf37-7cdd-937a-611b-de6160cfcb05" LABEL="md7" TYPE="linux_raid_member" /dev/sdb1: UUID="ef68da5f-824c-f25e-2e47-f50042486179" UUID_SUB="16b15c59-d233-6d3f-c5e2-3855352f4353" LABEL="md4" TYPE="linux_raid_member" /dev/sdb2: UUID="7be9132a-9c56-6e28-ca18-8b60cfaffb2c" UUID_SUB="d770d240-30cc-8c73-d24d-7e6c3c5a5152" LABEL="md0" TYPE="linux_raid_member" /dev/sdb3: UUID="37d02c72-506a-a979-d1b2-8b7a42b5414a" UUID_SUB="b1b8e415-3697-dc75-89e6-317595684559" LABEL="md6" TYPE="linux_raid_member" /dev/sdb5: UUID="7fccb456-b92c-806b-0d4c-815f4baa6422" UUID_SUB="e179532d-eca2-4e06-fc52-142d184a801f" LABEL="md7" TYPE="linux_raid_member" /dev/sdc1: UUID="ef68da5f-824c-f25e-2e47-f50042486179" UUID_SUB="0be51458-e973-0617-9903-e10f2144a96f" LABEL="md4" TYPE="linux_raid_member" /dev/sdc2: UUID="7be9132a-9c56-6e28-ca18-8b60cfaffb2c" UUID_SUB="3302e561-7452-984f-d727-561d5f476c3d" LABEL="md0" TYPE="linux_raid_member" /dev/sdc3: UUID="37d02c72-506a-a979-d1b2-8b7a42b5414a" UUID_SUB="f13a9a35-a191-030c-d750-fe5d3f12de79" LABEL="md6" TYPE="linux_raid_member" /dev/sdc5: UUID="7fccb456-b92c-806b-0d4c-815f4baa6422" UUID_SUB="3d0df87f-ce05-a027-5bff-c16977eba710" LABEL="md7" TYPE="linux_raid_member" /dev/sdd1: UUID="ef68da5f-824c-f25e-2e47-f50042486179" UUID_SUB="2764d80f-4702-780b-d29d-f13b28a4a954" LABEL="md4" TYPE="linux_raid_member" /dev/sdd2: UUID="7be9132a-9c56-6e28-ca18-8b60cfaffb2c" UUID_SUB="cbe77f18-871d-0146-625b-79cd1f59de04" LABEL="md0" TYPE="linux_raid_member" /dev/sdd3: UUID="37d02c72-506a-a979-d1b2-8b7a42b5414a" UUID_SUB="a222f97b-343b-f769-c8a3-1520e002d03d" LABEL="md6" TYPE="linux_raid_member" /dev/sdd5: UUID="7fccb456-b92c-806b-0d4c-815f4baa6422" UUID_SUB="38bc0c32-bef8-ac23-d82d-3031ea74f147" LABEL="md7" TYPE="linux_raid_member" /dev/md4: UUID="4d0397b9-e3dd-496e-9134-e27c68abe9d1" TYPE="ext4" /dev/md6: UUID="551fa77b-9256-49ff-8b88-190c1ceefd76" TYPE="ext4" /dev/md0: UUID="d96e95f3-a6f0-4e7c-82fb-98a24253ef42" TYPE="ext4" /dev/md7: UUID="1a2c18cb-a8f6-41c3-915c-362d5f1d5097" TYPE="ext4"
Ну и как бы на моих серверах я этого файла не нахожу. Centaur 7.0.0 : [asket@bud-ss ~]$ ls /etc | grep blkid [asket@bud-ss ~]$ Simply 7.0.1 : [asket@collect ~]$ ls /etc | grep blkid [asket@collect ~]$
НО: Centaur 6.0 [root@kmvi_server ~]# ls /etc | grep blkid blkid.tab blkid.tab.old [root@kmvi_server ~]#
(В ответ на комментарий №12) > НО: > Centaur 6.0 Он у вас скорее всего в /run/blkid/blkid.tab
(В ответ на комментарий №13) > (В ответ на комментарий №12) > > НО: > > Centaur 6.0 > > Он у вас скорее всего в /run/blkid/blkid.tab В общем-то не у меня, а в P7. А make-initrd, получается, ищет его по прежнему в /etc.
(In reply to comment #6) > > В каких-то бранчах mike@ делал изменения в make-initrd для сборки рейда, > > которых нет в сизифе. В p7/branch: http://git.altlinux.org/people/mike/packages/?p=make-initrd.git;a=commitdiff;h=5db62d63d23bf798fde8b0f040b959bf869e24c3 > Тут, насколько я понимаю, проблема не в сборке как таковой, а в автоугадаве > модулей -- модуль raid1 не попадает в initrd. Угу. (In reply to comment #13) > Он у вас скорее всего в /run/blkid/blkid.tab (на всякий: и смотрит туда только tools/bug-report)
Да, забыл: make-initrd-0.8.6-alt1.M70P.1 на root raid1 тестировал, ничего подобного не наблюдал. У Вас несколько оригинальный вариант разбивки, хотя, разумеется, не криминальный :)
asket@ вы сможете подправить скрипт и прислать bug-report или лучше для вас подготовить сборку ?
(В ответ на комментарий №16) > Да, забыл: make-initrd-0.8.6-alt1.M70P.1 на root raid1 тестировал, ничего > подобного не наблюдал. У Вас несколько оригинальный вариант разбивки, хотя, > разумеется, не криминальный :) Не вижу ничего оригинального - обычный вариант отказоустойчивой системы с 4 винчестерами. Если root на raid1 проблем не возникает, глюки только с монтированием /boot на RAID1 или RAID5.
(В ответ на комментарий №17) > asket@ вы сможете подправить скрипт и прислать bug-report или лучше для вас > подготовить сборку ? Если скажете что именно подправить вполне смогу.
--- /usr/share/make-initrd/tools/bug-report 2014-02-20 16:12:39.020296344 +0400 +++ /usr/share/make-initrd/tools/bug-report 2014-02-20 16:13:12.153842619 +0400 @@ -37,7 +37,6 @@ cp -a \ /etc/fstab \ - /etc/blkid.tab \ "$reportdir"/etc/ blkid -c /dev/null >"$reportdir"/etc/blkid.out
(In reply to comment #18) > обычный вариант отказоустойчивой системы с 4 винчестерами. Так и понял, но в 100Gb попасть бэдом или ещё каким повреждением легче, чем в корень на 1..10Gb. Но это уж зависит от того, как используется корень и где существенные объёмы кода/данных (у меня обычно код в контейнерах, а они, как и данные, на отдельном массиве). Это напрямую к баге не относится, понятное дело.
(In reply to comment #3) > Решил вопрос предзагрузкой модуля RAID1 в initrd. Заметил, что при запуске > make-initrd в списке модулей присутствует только RAID10. Похоже, надо смотреть не только по /, а и как минимум по /boot -- типовой случай с зеркалированием обоих явно маскировал варианты вроде описанного здесь.
Ещё актуально ?
(In reply to Alexey Gladkov from comment #23) > Ещё актуально ? Если ориентироваться на тему, то да. Прямо вот вчера и сегодня: https://lists.altlinux.org/pipermail/sysadmins/2021-February/038341.html Но причины могут уже теперь и различаться. Вкратце: есть ядро 4.9.194-std-def-alt0.M80P.1 с соответствующим initrd, который собран 22/09/2019 не знаю, какой версией make-initrd и без mdadm внутри, с которым система грузится, и есть несколько ядер, initrd для которых сделаны более новыми make-initrd (включая актуальный из p9), с наличием mdadm, с которыми система не грузится. Во всех случаях присутствует модуль raid10 и отсутствует raid1. кроме того, есть несколько новых ядер, для которых initrd собраны с MODULES_ADD += raid1. С ними тоже грузится. Конфигурация в моём случае /dev/sd[abcd]1 - raid1 (Version : 0.90.00) /boot /dev/sd[abcd]3 - raid10 LVM всё остальное (корень и /usr разные тома, если важно). Корень монтируется в любом случае.
вы можете показать свой mdadm.conf ? предположу, что в нём описан /boot и поэтому mdadm в initrd так себя ведёт.
(In reply to Alexey Gladkov from comment #25) > вы можете показать свой mdadm.conf ? предположу, что в нём описан /boot и > поэтому mdadm в initrd так себя ведёт. Как ARRAY да, /dev/md0, как раз, /boot == MAILADDR root PROGRAM /sbin/mdadm-syslog-events DEVICE partitions ARRAY /dev/md0 UUID=75361cdf:b17a3dc7:7c2a9d01:85d820ef ARRAY /dev/md1 UUID=b83c3ad4:e5bc7533:bfe78010:bc810f04 == Но, кстати, раз 22/09/2019 всё работало, то исходно этот баг был исправлен видимо, а сейчас в наличии другой с таким же проявлением.
(In reply to Alexey Gladkov from comment #25) > предположу, что в нём описан /boot и поэтому mdadm в initrd так себя ведёт. Речь именно об "ARRAY /dev/md0 ...", или о чём-то другом? Я попробовал убрать (с пересборкой initrd), но ничего не изменилось.
(Ответ для Sergey Y. Afonin на комментарий #27) > (In reply to Alexey Gladkov from comment #25) > > > предположу, что в нём описан /boot и поэтому mdadm в initrd так себя ведёт. > > Речь именно об "ARRAY /dev/md0 ...", или о чём-то другом? Я попробовал > убрать (с пересборкой initrd), но ничего не изменилось. Речь была о том, чтобы оставить в initrd в mdadm.conf только то, что отвечает за рут. Если это не срабатывает, то я буду пробовать воспроизвести это поведение в тестах и разбираться.
(In reply to Alexey Gladkov from comment #28) > Если это не срабатывает, то я буду пробовать воспроизвести это поведение в > тестах и разбираться. Сейчас в mdadm.conf раскомментировано MAILADDR root PROGRAM /sbin/mdadm-syslog-events DEVICE partitions ARRAY /dev/md1 UUID=b83c3ad4:e5bc7533:bfe78010:bc810f04 на md1 lvm, и там том main-root, который корень. mdadm.conf в initrd этот же, в fstab только корень: UUID=285d36a2-f6af-4fa6-8c11-a6a1ba746025 / ext4 rw,relatime,stripe=16 0 0 Загрузка встаёт с сообщением о недоступности /boot, корень исправно монтируется. Лечится добавлением модуля raid1 в initrd. Ну или можно nofail для /boot добавить в fstab и собирать md0 по необходимости.
(Ответ для Sergey Y. Afonin на комментарий #29) > Сейчас в mdadm.conf раскомментировано > > MAILADDR root > PROGRAM /sbin/mdadm-syslog-events > DEVICE partitions > ARRAY /dev/md1 UUID=b83c3ad4:e5bc7533:bfe78010:bc810f04 > > на md1 lvm, и там том main-root, который корень. mdadm.conf в initrd этот > же, в fstab только корень: > UUID=285d36a2-f6af-4fa6-8c11-a6a1ba746025 / ext4 > rw,relatime,stripe=16 0 0 > Загрузка встаёт с сообщением о недоступности /boot, корень исправно > монтируется. Лечится добавлением модуля raid1 в initrd. Ну или можно nofail > для /boot добавить в fstab и собирать md0 по необходимости. Так. Давайте проясним. Когда вы говорите о сообщении о недоступности /boot, то имеете в виду уже сообщение из живой системы (не из initrd) ?
Created attachment 9210 [details] Остановка загрузки с несмонтированным /boot > Так. Давайте проясним. Когда вы говорите о сообщении о недоступности > /boot, то имеете в виду уже сообщение из живой системы (не из initrd) ? Видимо да, так как корень уже смонтирован и переведён в rw. Фото под руками несколько обрезанное, но читаемо. Встаёт на красной линии. Остальное там после enter.
Ок. Так, это сообщение уже из живой системы (судя по всему у вас sysv). Дело в том, что я сделал тест c /boot (raid1) + / (raid5) и он проходит до системного init, но я не проверяю состояние md после запуска /sbin/init.
Я попробовал вот так: / на RAID1 /boot на RAID5 Не знаю конечно, есть ли смысл иметь /boot на RAID5, но получилось примерно то же самое, только теперь в guess_module попадает лишь raid1. Получается, автоугадывальщик и не пытается ничего угадывать помимо корня?
(Ответ для Slava Aseev на комментарий #33) > Я попробовал вот так: > / на RAID1 > /boot на RAID5 > > Не знаю конечно, есть ли смысл иметь /boot на RAID5, но получилось примерно > то же самое, только теперь в guess_module попадает лишь raid1. > Получается, автоугадывальщик и не пытается ничего угадывать помимо корня? Конечно не пытается.
(In reply to Slava Aseev from comment #33) > /boot на RAID5 Это какой загрузчик так умеет? Или это фишки EFI?
(In reply to Alexey Gladkov from comment #32) > Ок. Так, это сообщение уже из живой системы (судя по всему у вас sysv). Да, sysv > Дело в том, что я сделал тест c /boot (raid1) + / (raid5) и он проходит до > системного init, но я не проверяю состояние md после запуска /sbin/init. В общем понятно и, с какой-то точки зрения, разумно. Только вопрос, чей это баг в итоге. С одной стороны, раз /sbin/init запустился, то ему и разбираться дальше. С другой - до появления make-initrd-mdadm всё работало. А с третьей добавление raid1.ko в initrd проблему сейчас решает.
(Ответ для Sergey Y. Afonin на комментарий #36) > В общем понятно и, с какой-то точки зрения, разумно. Только вопрос, чей это > баг в итоге. С одной стороны, раз /sbin/init запустился, то ему и > разбираться дальше. С другой - до появления make-initrd-mdadm всё работало. > А с третьей добавление raid1.ko в initrd проблему сейчас решает. make-initrd-mdadm копирует из mdadm: /lib/udev/rules.d/63-md-raid-arrays.rules /lib/udev/rules.d/64-md-raid-assembly.rules Они и делают всю работу по сборке /dev/md[0-9]. Есть два варианта: 1. Либо эти правила делают с linux_raid_member что-то такое, что мешает потом собрать рейд в sysv. Собрать его в initrd не получается так как соответствующий модуль в образ не попадает. Когда вы добавляете модуль в образ, вы даёте initrd собрать рейд (/boot) и это чудесным образом срабатывает. Чудесным образом, потому что initrd не ждёт завершения сборки рейда. Он ждёт только рейда для корневого раздела и может перейти к загрузки системы до того как успеет собраться /boot. В этом случае виноваты правила для udev. 2. Либо виноват скрипт [1], который позволяет загрузится с деградированным рейдом. Чтобы это проверить нужно при загрузке передать параметр raid-member-delay=0. [1] https://github.com/osboot/make-initrd/blob/master/features/mdadm/data/lib/uevent/handlers/md-raid-member/100-timeout Вы не могли бы проверить второй вариант ?
(Ответ для Alexey Gladkov на комментарий #37) > (Ответ для Sergey Y. Afonin на комментарий #36) > Когда вы добавляете модуль в > образ, вы даёте initrd собрать рейд (/boot) и это чудесным образом > срабатывает. Чудесным образом, потому что initrd не ждёт завершения сборки > рейда. Он ждёт только рейда для корневого раздела и может перейти к загрузки > системы до того как успеет собраться /boot. В этом случае виноваты правила > для udev. Получается, что это всегда работает "чудесным образом". Т.е. если корень и /boot будут оба на raid1, то модуль будет доступен и initrd соберет raid /boot. И это значит, что добавление модулей (raid456/raid10) в образ ничего не поломает (все уже сломано?) Поправьте, если я ошибаюсь.
(Ответ для Slava Aseev на комментарий #38) > Получается, что это всегда работает "чудесным образом". Т.е. если корень и > /boot будут оба на raid1, то модуль будет доступен и initrd соберет raid > /boot. Сейчас это срабатывает именно так. > И это значит, что добавление модулей (raid456/raid10) в образ ничего не > поломает (все уже сломано?) Что сломано пока не понятно. Нужно проверить описанный выше второй вариант. > Поправьте, если я ошибаюсь. После исправления должно быть так: initrd собирает только рейд отвечающий за корень и отдавать остальное на откуп живой системе, которая если захочет сможет смонтировать остальные рейды.
(Ответ для Alexey Gladkov на комментарий #39) > (Ответ для Slava Aseev на комментарий #38) > Что сломано пока не понятно. Нужно проверить описанный выше второй вариант. raid-member-delay=0 не помогает. Попробовал в initrd собрать вручную массив на raid5 c отсутствующим модулем raid456. При инкрементальной сборке mdadm --incremental --export вызывается для каждой ноды, и как только мы вызываем для последней ноды - mdadm пытается сделать ioctl RUN_ARRAY. Т.к. модуль raid456 отсутствует, RUN_ARRAY фэйлится (/dev/sdd1 attached to /dev/md127, but failed to start: Invalid argument), но при этом сам массив остается собранным в /dev/md[0-9] Последующие запуски mdadm --incremenal --export для каждой ноды выдают Device or resource busy и RUN_ARRAY уже никогда не вызовется. И вероятно такое происходит даже когда модуль raid456 уже доступен. Это и объясняет, почему после mdadm --stop /dev/md[0-9] массив уже благополучно собирается.
И если я правильно понял, то в initrd сборка всех массивов (а не только /) происходит именно потому что так работает /lib/udev/rules.d/64-md-raid-assembly.rules И получается вопрос тут в том, нужно ли вообще это правило в initrd или можно как-то собрать / на raid без него. Или стоит как-то модифицировать это правило, чтобы в initrd кроме корня ничего не собиралось.
(Ответ для Slava Aseev на комментарий #40) > > Что сломано пока не понятно. Нужно проверить описанный выше второй вариант. > > raid-member-delay=0 не помогает. Значит не этот мой код виноват. > Попробовал в initrd собрать вручную массив на raid5 c отсутствующим модулем > raid456. > При инкрементальной сборке mdadm --incremental --export вызывается для > каждой ноды, и как только мы вызываем для последней ноды - mdadm пытается > сделать ioctl RUN_ARRAY. Т.к. модуль raid456 отсутствует, RUN_ARRAY фэйлится > (/dev/sdd1 attached to /dev/md127, but failed to start: Invalid argument), > но при этом сам массив остается собранным в /dev/md[0-9] > > Последующие запуски mdadm --incremenal --export для каждой ноды выдают > Device or resource busy и RUN_ARRAY уже никогда не вызовется. И вероятно > такое происходит даже когда модуль raid456 уже доступен. Это и объясняет, > почему после mdadm --stop /dev/md[0-9] массив уже благополучно собирается. Спасибо за то, что разобрались в проблеме! Не уверен, что это правильный подход, но, возможно, перед переключением в систему нужно сделать mdadm --stop всем рейдам кроме тех что initrd попросили смонтировать. Или же нужно отказаться от стандартных udev-правил mdadm и делать mdadm --incremental только тем дискам, которые нужны.
Попробовал сделать путем модификации правила 64-md-raid-assembly.rules: http://git.altlinux.org/people/ptrnine/packages/?p=make-initrd.git;a=commit;h=00e6d1f830d2f200db9fb018fe903fcdbf4538fc В 64-md-raid-assembly.rules добавляется проверка на uuid. Если uuid не совпадает с uuid массива на корне, то происходит GOTO в конец и массив не собирается.
(Ответ для Slava Aseev на комментарий #43) > Попробовал сделать путем модификации правила 64-md-raid-assembly.rules: > http://git.altlinux.org/people/ptrnine/packages/?p=make-initrd.git;a=commit; > h=00e6d1f830d2f200db9fb018fe903fcdbf4538fc > > В 64-md-raid-assembly.rules добавляется проверка на uuid. Если uuid не > совпадает с uuid массива на корне, то происходит GOTO в конец и массив не > собирается. я не очень понял итог эксперимента. исправление правил не помогло ?
(Ответ для Alexey Gladkov на комментарий #44) > (Ответ для Slava Aseev на комментарий #43) > я не очень понял итог эксперимента. исправление правил не помогло ? Помогло, теперь система благополучно грузится. Подойдет ли такое решение, или стоит сделать как-нибудь по-другому?
(Ответ для Slava Aseev на комментарий #45) > > я не очень понял итог эксперимента. исправление правил не помогло ? > > Помогло, теперь система благополучно грузится. Отлично! > Подойдет ли такое решение, или стоит сделать как-нибудь по-другому? То что, делает fix_rules нужно делать не только для корня, но и всего, что находится в $(MOUNTPOINTS). Я бы предложил не пытаться модифицировать 64-md-raid-assembly.rules, а просто сгенерировать правила свои правила т.к. если в mdadm чуть-чуть изменят их, то fix-rules незаметно сломается. cat "$NEWRULE" <<EOF SUBSYSTEM!="block", GOTO="md_inc_end" ENV{ID_FS_TYPE}=="linux_raid_member", GOTO="md_inc" IMPORT{cmdline}="noiswmd" IMPORT{cmdline}="nodmraid" ENV{nodmraid}=="?*", GOTO="md_inc_end" ENV{ID_FS_TYPE}=="ddf_raid_member", GOTO="md_inc" ENV{noiswmd}=="?*", GOTO="md_inc_end" ENV{ID_FS_TYPE}=="isw_raid_member", GOTO="md_inc" GOTO="md_inc_end" LABEL="md_inc" $(add_uuid_filter) LABEL="md_uuid_ok" ACTION=="add|change", IMPORT{program}="/sbin/mdadm --incremental --export $devnode --offroot $env{DEVLINKS}" ACTION=="remove", ENV{ID_PATH}=="?*", RUN+="/sbin/mdadm -If $name --path $env{ID_PATH}" ACTION=="remove", ENV{ID_PATH}!="?*", RUN+="/sbin/mdadm -If $name" LABEL="md_inc_end" EOF Из них также можно выкинуть некоторые вещи, которые нужны anaconda и systemd. Не знаю насколько это будет удобно, но возможно попробовать для каждой mountpoint сгенерировать отдельный файл. Возможно, это нафиг не нужно.
(Ответ для Alexey Gladkov на комментарий #46) > То что, делает fix_rules нужно делать не только для корня, но и всего, что > находится в $(MOUNTPOINTS). Я бы предложил не пытаться модифицировать > 64-md-raid-assembly.rules, а просто сгенерировать правила свои правила т.к. > если в mdadm чуть-чуть изменят их, то fix-rules незаметно сломается. > > cat "$NEWRULE" <<EOF > SUBSYSTEM!="block", GOTO="md_inc_end" > ENV{ID_FS_TYPE}=="linux_raid_member", GOTO="md_inc" > > IMPORT{cmdline}="noiswmd" > IMPORT{cmdline}="nodmraid" > > ENV{nodmraid}=="?*", GOTO="md_inc_end" > ENV{ID_FS_TYPE}=="ddf_raid_member", GOTO="md_inc" > ENV{noiswmd}=="?*", GOTO="md_inc_end" > ENV{ID_FS_TYPE}=="isw_raid_member", GOTO="md_inc" > GOTO="md_inc_end" > > LABEL="md_inc" > > $(add_uuid_filter) > > LABEL="md_uuid_ok" > > ACTION=="add|change", IMPORT{program}="/sbin/mdadm --incremental --export > $devnode --offroot $env{DEVLINKS}" > ACTION=="remove", ENV{ID_PATH}=="?*", RUN+="/sbin/mdadm -If $name --path > $env{ID_PATH}" > ACTION=="remove", ENV{ID_PATH}!="?*", RUN+="/sbin/mdadm -If $name" > > LABEL="md_inc_end" > EOF > > Из них также можно выкинуть некоторые вещи, которые нужны anaconda и systemd. > > Не знаю насколько это будет удобно, но возможно попробовать для каждой > mountpoint сгенерировать отдельный файл. Возможно, это нафиг не нужно. Переделал, теперь правила генерируются для всех MOUNTPOINTS: http://git.altlinux.org/people/ptrnine/packages/?p=make-initrd.git;a=blob;f=features/mdadm/bin/fix_rules;h=ea6d3c4cce4a7c518afbafdb5f681fc8b34cfb90;hb=4af6ba05980ab7c3c4ad5fc09752628947f7aa04 Для каждой точки монтирования на raid теперь генерируется отдельное правило. Вы же это имели в виду? Также изменил чуть момент с UUIDами. Теперь UUID получается через mdadm --detail --export, потому что с /sys/dev/block/$MIN:$MAJ/md/uuid происходят странные метаморфозы и в зависимости от версии суперблока у UUIDа может быть разный порядок байт Проверял с одним и несколькими MOUNTPOINTS, работает нормально
Почти идеально! Я смерджил ваш коммит, поправил форматирование и добавил проверку на рейд. В MOUNTPOINTS могут не только рейды. Их нужно пропускать. Также есть небольшая бага, что скрипт будет выполняться несколько раз.
(Ответ для Alexey Gladkov на комментарий #48) > В MOUNTPOINTS могут не только рейды А. Точно :D Спасибо за оперативную помощь. Скажите, скоро ли это попадет в сизиф?
(Ответ для Slava Aseev на комментарий #49) > Спасибо за оперативную помощь. Скажите, скоро ли это попадет в сизиф? 2.13.0 уже в сизифе.
(In reply to Alexey Gladkov from comment #50) > 2.13.0 уже в сизифе. Я сделал задание 267576 для p9 с копированием, и что-то у меня вообще система не загрузилась: ... Loading modules: Starting udevd service: Network up (lo): rdshell: The waiting time expired! (initramfs)$ И USB-клавиатура под рукой только, драйвер не заработал почему-то. Хотя она отключена была в момент загрузки, но это вроде не мешало раньше. По модулям при генерации криминала вроде нет (5.10.19-un-def): [00:00:14] Used features: add-modules buildinfo cleanup compress depmod-image devmapper kbd lvm mdadm network rdshell rootfs system-glibc ucode [00:00:14] Packed modules: af_packet ahci dm-bufio dm-mod dm-snapshot hid hid-generic libahci libata raid10 scsi_mod sd_mod
(In reply to Sergey Y. Afonin from comment #51) > Я сделал задание 267576 для p9 с копированием, и что-то у меня вообще > система не загрузилась: > > ... > Loading modules: > Starting udevd service: > Network up (lo): > rdshell: The waiting time expired! > (initramfs)$ Прицепил туда консольку, можно поотлаживаться. Не собрался ни один RAID в этой ситуации. Баг этот переоткрыть, или новый сделать? Или в p9 просто так этот make-initrd нельзя копировать?
(Ответ для Sergey Y. Afonin на комментарий #52) > Прицепил туда консольку, можно поотлаживаться. Не собрался ни один RAID в > этой ситуации. Баг этот переоткрыть, или новый сделать? Или в p9 просто так > этот make-initrd нельзя копировать? В p9 я вообще не знаю, что происходит. Там мои полномочия всё. Если в сизифе не воспроизводится, то нужно смотреть на mdadm в p9.
(In reply to Alexey Gladkov from comment #53) > Если в сизифе не воспроизводится, то нужно смотреть на mdadm в p9. До Сизифа сервер обновлять не хотелось бы. Сначала попробую mdadm из Сизифа добавить, но завтра наверное уже: тут консолька может не помочь, если вдруг что.
(Ответ для Sergey Y. Afonin на комментарий #52) > (In reply to Sergey Y. Afonin from comment #51) > > > Я сделал задание 267576 для p9 с копированием, и что-то у меня вообще > > система не загрузилась: > > > > ... > > Loading modules: > > Starting udevd service: > > Network up (lo): > > rdshell: The waiting time expired! > > (initramfs)$ > > Прицепил туда консольку, можно поотлаживаться. Не собрался ни один RAID в > этой ситуации. Баг этот переоткрыть, или новый сделать? Или в p9 просто так > этот make-initrd нельзя копировать? В p9 таск с make-initrd (#267573) не пропустили, потому что с luks udev-правило для сборки массива не генерируется и массив, соответственно, не собирается. Вероятно, то же самое должно быть и с lvm. Я сейчас занимаюсь этой проблемой.
Попробовал сделать вот так: http://git.altlinux.org/people/ptrnine/packages/?p=make-initrd.git;a=commit;h=8fc8587e9e8d55b50ca6d55bbc307d8fa5318ec0 Теперь, если в mountpoint будет device mapper устройство, то для каждого raid в его таблице будет создано udev-правило для сборки. Т.е. все рейды-"дети" для точек монтирования с luks и lvm теперь будут нормально собираться. Текущая ситуация по сути является регрессом и актуальна не только для p9. Т.к. раньше собирались все рейды (а не только mountpoints) - такой проблемы не было. legion@, можете посмотреть правки, пожалуйста, как будет время?
(Ответ для Slava Aseev на комментарий #56) > Попробовал сделать вот так: > http://git.altlinux.org/people/ptrnine/packages/?p=make-initrd.git;a=commit; > h=8fc8587e9e8d55b50ca6d55bbc307d8fa5318ec0 > > Теперь, если в mountpoint будет device mapper устройство, то для каждого > raid в его таблице будет создано udev-правило для сборки. Т.е. все > рейды-"дети" для точек монтирования с luks и lvm теперь будут нормально > собираться. > > Текущая ситуация по сути является регрессом и актуальна не только для p9. > Т.к. раньше собирались все рейды (а не только mountpoints) - такой проблемы > не было. > > legion@, можете посмотреть правки, пожалуйста, как будет время? Да, это мы упустили. raid может быть не только на верхнем уровне, но и частью слоёного пирога рутовой файловой системы, порождённого фантазией админа. Идея в изменения правильная, но реализация в корне не верная. Реализация не учитывает, что raid может встретиться как составная часть btrfs (глупо, но возможно). На самом деле перечислять все мыслимые и не мыслимые конфигурации не нужно. Достаточно модифицировать generate-udev-rules и перенести его вызов в features/mdadm/guess/device. guess/device будет вызван для каждого узла в дереве sysfs от самого верха до его основания для всех mountpoints.
(Ответ для Alexey Gladkov на комментарий #57) > Да, это мы упустили. raid может быть не только на верхнем уровне, но и > частью слоёного пирога рутовой файловой системы, порождённого фантазией > админа. Идея в изменения правильная, но реализация в корне не верная. > > Реализация не учитывает, что raid может встретиться как составная часть > btrfs (глупо, но возможно). > > На самом деле перечислять все мыслимые и не мыслимые конфигурации не нужно. > Достаточно модифицировать generate-udev-rules и перенести его вызов в > features/mdadm/guess/device. guess/device будет вызван для каждого узла в > дереве sysfs от самого верха до его основания для всех mountpoints. Переделал, теперь вызывается из features/mdadm/guess/device: http://git.altlinux.org/people/ptrnine/packages/?p=make-initrd.git;a=commit;h=33b963ae5fcd8c75aad46f367c131f81c2b5e2d2 Правило теперь создается сразу в $ROOTDIR/lib/udev/rules.d Получается, скрипт будет выполняться только для raid и для mountpoint-устройств (либо для их slave-устройств в иерархии sysfs). И никакие проверки вообще не нужны, круто.
Так вышло, что с тех пор как я написал предыдущий коммент я уже сам реализовал это и уже нашёл, что так просто делать нельзя. Реализовывать нужно чуть-чуть хитрее. Идея та же, но несколько более сложная реализация. Я как закончу это отлаживать дам знать тут.
Как-то вот так получилось: http://git.altlinux.org/people/legion/packages/make-initrd.git?p=make-initrd.git;a=commitdiff;h=194fd4e56290f045feed14948c79b50455428782
(In reply to Alexey Gladkov from comment #60) > Как-то вот так получилось: Если достаточно только этот коммит добавить (и guess-functions обновть) к тому что в 267576 (копирование 2.13.0 из Сизифа), то у меня не заработало (корень на LVM, который на RAID10).
Этого коммита не достаточно. Нужны коммиты: 1f7e0703fd17d633e4b0f376ae641c4bfc0cba9a 194fd4e56290f045feed14948c79b50455428782
(In reply to Alexey Gladkov from comment #62) > Этого коммита не достаточно. Нужны коммиты: > > 1f7e0703fd17d633e4b0f376ae641c4bfc0cba9a > 194fd4e56290f045feed14948c79b50455428782 Загрузилось, /boot тоже есть без добавления raid1.ko
(Ответ для Sergey Y. Afonin на комментарий #63) > (In reply to Alexey Gladkov from comment #62) > > > Этого коммита не достаточно. Нужны коммиты: > > > > 1f7e0703fd17d633e4b0f376ae641c4bfc0cba9a > > 194fd4e56290f045feed14948c79b50455428782 > > Загрузилось, /boot тоже есть без добавления raid1.ko то есть работает как надо ?
(In reply to Alexey Gladkov from comment #64) > > Загрузилось, /boot тоже есть без добавления raid1.ko > > то есть работает как надо ? В моей конфигурации да, как надо. 2.13.0-alt1 плюс эти два коммита, и в p9.
(Ответ для Sergey Y. Afonin на комментарий #65) > В моей конфигурации да, как надо. 2.13.0-alt1 плюс эти два коммита, и в p9. 2.14.0 с этими изменениями ушёл в сизиф.
(In reply to Alexey Gladkov from comment #66) > 2.14.0 с этими изменениями ушёл в сизиф. Этот вариант у меня тоже работает.
Значит будем считать, что исправили.
(In reply to Alexey Gladkov from comment #68) > Значит будем считать, что исправили. Ещё один тест неожиданно получился, с выходом hdd из строя. Но решил отдельным багом завести: https://bugzilla.altlinux.org/40005
