Кастрация genkernel

Конечно. /usr/share/genkernel/arch/${arch}/modules_load

Интересное другое есть ли более навороченный genkernel который генерирует конфиг ядра зависимости от оборудования
по lspci, lsusb и т.д. ??

Еще раньше и неоднократно задавался похожими вопросами по средствам автоматизации конфигурации ядра, кажется многие меня даже не совсем понимают, не только как но и вообще зачем. Почему то воспринимается что рукоковыряние это норма и единственно верное решение. Но это не так, сейчас ручная настройка - практически единственный возможный на данный момент метод, так как информация очень сильно разбросана и разрозненна, и ее способен корректно (и то не всегда) интерпретировать только человек (ну, искусственный интеллект еще никто не взялся учить под эту задачу).

Проблема в том, что информация о назначении той или иной опции ядра практически никак не формализована, это просто текстовая информация, причем была бы она размещена только в одном месте, так нет, нужно рыть не только сообщения kconfig и linux/Documentation, но и просторы интернета, чтобы понять, что для такого то функционала необходимы такие то технологии, некоторые из них реализуются таким то ПО, для которого нужны такие то настройки. Чувствуете кривую зависимость? т.е. зависимости ядра не от задач, а как требования ПО, решающих задачи. Добавьте сюда постоянное изменение всей этой информации во времени и далеко не всегда корректное её отслеживание на страницах в интернете, плюс устаревание технологий, плюс практически гарантированные заблуждения и привычки.

Для универсального решения (как серверные так и десктопные сборки) можно закрыть глаза на лишние модули, лишние секунды загрузки и лишние мегабайты оперативки, а так же лишние минуты компиляции, это не существенно, но вот при сборке конечного решения, особенно в условиях ограниченных ресурсов, подобные проблемы с информацией ой как мешают, приходится изучать то, что по уму изучать совсем не обязательно.

Приведу аналогию, - это как обычному домашнему пользователю, для того, чтобы установить плеер, вместо нажатия чекбоксика в синаптике, пришлось бы изучать скриптовые языки bash, формат deb/rpm, вручную копаться в зависимостях, выискивая необходимые версии библиотек и т.д (кстати, именно этим приходится заниматься пользователю, пожелавшему получить версию программы, отличную от того, что предлагают мейнтейнеры дистрибутива).

А теперь представьте, если бы настройка ядра была бы так же красиво формализована как система портежей, USE-флагов, зависимостей и т.д. я не имею в виду что необходимо именно такую систему вводить в ядро, но такую же гибкую очень бы хотелось!