Обновляли систему и ядро до текущего 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