Bug 34880

Summary:	Актуализировать списки модулей, попадающие во все загрузочные образы
Product:	Sisyphus	Reporter:	Leonid Krivoshein <klark.devel>
Component:	mkimage-profiles	Assignee:	Антон Мидюков <antohami>
Status:	CLOSED FIXED	QA Contact:	qa-sisyphus
Severity:	normal
Priority:	P3	CC:	antohami, mike
Version:	unstable
Hardware:	all
OS:	Linux
URL:	https://www.altlinux.org/Mkimage/Profiles/m-p/objects

Description Leonid Krivoshein 2018-05-03 21:31:47 MSK

Формализация в багзилле по настоянию руководства.

$ cat sub.in/stage1/modules features.in/*/stage1/modules.d/* | wc -l
428

Списки модулей в m-p давно не пересматривались. Их необходимо пересматривать регулярно, в соответствии с выпускаемыми ядрами. Вопрос обсуждался, в том числе, с Антоном Бояршиновым, Михаилом Шигориным и Алексеем Гладковым. Основная проблема заключается сейчас в том, что в наши универсальные загрузочные носители попадают не все доступные модули и прошивки. В результате на каком-то оборудовании наши диски могут просто не загрузиться.

На днях аналогичную работу провёл Алексей Гладков для make-initrd/v2+ -- там появились фичи modules-networks, modules-filesystems, modules-nfs, modules-virtio. Но на p8 это, наверное, бэкпортировать будет не очень просто, тогда как стабильная загрузка требуется, в первую очередь, на p8.

Чтобы актуализировать списки, полагаю, достаточно сравнить всё, что есть сейчас в актуальном ядре, с тем, что попадает в initrd из m-p. Можно перенастроить списки более тонко, ориентируясь на аналогичную информацию из других дистрибутивов. Но работа кропотливая, требует времени и тщательного подхода. Могу этим заняться, но лучше бы найти добровольца.

Кроме того, (предположительно) mkmodpack из пропагатора может не учитывать softdeps, которые лишь на днях научился делать make-initrd, то есть риск непопадания всех нужных модулей в initrd есть ещё и с этой стороны.

Comment 1 Michael Shigorin 2018-05-07 19:52:35 MSK

(В ответ на комментарий №0)
> Списки модулей в m-p давно не пересматривались. Их необходимо пересматривать
> регулярно, в соответствии с выпускаемыми ядрами.
Хорошо бы конкретный пример патча -- там вообще-то не зря шаблоны по путям.

> Кроме того, (предположительно) mkmodpack из пропагатора может не учитывать
> softdeps, которые лишь на днях научился делать make-initrd, то есть риск
> непопадания всех нужных модулей в initrd есть ещё и с этой стороны.
А вот это хорошо бы на него отдельно повесить; применительно к m-p это означает необходимость выявления и прибивания гвоздиком всех нужных модулей вроде crc32c -- ср. bug 34854, bug 34865.

Comment 2 Leonid Krivoshein 2018-05-08 00:48:11 MSK

(В ответ на комментарий №1)
> Хорошо бы конкретный пример патча -- там вообще-то не зря шаблоны по путям.

Там есть конкретные имена модулей тоже. Шаблоны работают не так, как я ожидал (по предложению legion@). Например, MODULES_ADD += .*/drivers/.* складывает отнюдь не все модули. Навскидку -- нет целой поддиректории gpu. Чтобы сделать такой патч, очевидно, придётся проделать ту кропотливую работу, сравнивая по результатам попадания в initrd, но тогда этот патч будет уже не очень нужен. :)

> > Кроме того, (предположительно) mkmodpack из пропагатора может не учитывать
> > softdeps, которые лишь на днях научился делать make-initrd, то есть риск
> > непопадания всех нужных модулей в initrd есть ещё и с этой стороны.
> А вот это хорошо бы на него отдельно повесить; применительно к m-p это означает

Это я в любом случае собирался повесить на make-initrd-propagator, предварительно данную версию проверив. Если в конечном итоге вызывается make-initrd, тогда беспокоиться не о чем. Или если там используется та же версия depinfo из kmod.

Comment 3 Антон Мидюков 2023-04-17 08:57:33 MSK

Списки модулей были пересмотрены в версии 1.4.27 в коммите 7a2f65f9598f23b1cba39a3281007abc31c19ce1