Формализация в багзилле по настоянию руководства. $ 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 есть ещё и с этой стороны.
(В ответ на комментарий №0) > Списки модулей в m-p давно не пересматривались. Их необходимо пересматривать > регулярно, в соответствии с выпускаемыми ядрами. Хорошо бы конкретный пример патча -- там вообще-то не зря шаблоны по путям. > Кроме того, (предположительно) mkmodpack из пропагатора может не учитывать > softdeps, которые лишь на днях научился делать make-initrd, то есть риск > непопадания всех нужных модулей в initrd есть ещё и с этой стороны. А вот это хорошо бы на него отдельно повесить; применительно к m-p это означает необходимость выявления и прибивания гвоздиком всех нужных модулей вроде crc32c -- ср. bug 34854, bug 34865.
(В ответ на комментарий №1) > Хорошо бы конкретный пример патча -- там вообще-то не зря шаблоны по путям. Там есть конкретные имена модулей тоже. Шаблоны работают не так, как я ожидал (по предложению legion@). Например, MODULES_ADD += .*/drivers/.* складывает отнюдь не все модули. Навскидку -- нет целой поддиректории gpu. Чтобы сделать такой патч, очевидно, придётся проделать ту кропотливую работу, сравнивая по результатам попадания в initrd, но тогда этот патч будет уже не очень нужен. :) > > Кроме того, (предположительно) mkmodpack из пропагатора может не учитывать > > softdeps, которые лишь на днях научился делать make-initrd, то есть риск > > непопадания всех нужных модулей в initrd есть ещё и с этой стороны. > А вот это хорошо бы на него отдельно повесить; применительно к m-p это означает Это я в любом случае собирался повесить на make-initrd-propagator, предварительно данную версию проверив. Если в конечном итоге вызывается make-initrd, тогда беспокоиться не о чем. Или если там используется та же версия depinfo из kmod.
Списки модулей были пересмотрены в версии 1.4.27 в коммите 7a2f65f9598f23b1cba39a3281007abc31c19ce1