/etc/conf.d/modules

modules.clt при этом игнорируется

у меня при обновлении системы портежей через eix-sync постоянно спрашивает “использовать новую версию или старую?”
это касается xorg.conf, modules, hwclock и т.д.

сколько обновляюсь ни разу не спросил про modules, сносит втихую все что там прописано при перезагрузке после обновления

Кстати, может кому-то будет интересно.
Я для решения вопроса автопогрузки нужных модулей сделал такой костыль:

# cat /etc/conf.d/modules

for f in /etc/modules_autoload/*; do
        [ -f "${f}" ] || continue
        modules_3="${modules_3} $(/bin/sed -re 's/\s*(#.*$)?//' -e '/^$/d' < "${f}")"
done

С учетом того, что конфиги в /etc/conf.d это просто bash-скрипты, которые исполняются при импорте - в них можно вставлять в т.ч. и такие конструкции.
Далее, просто создаю нужные конфиги для нужных мне модулей, вроде этого:

# cat /etc/modules_autoload/VirtualBox

 # VirtualBox modules
vboxpci
vboxnetflt
vboxnetadp
vboxdrv

И этот файл, при желании, можно спокойно генерировать из шаблона, к примеру так:
cat /var/calculate/templates/3.1/3_ac_install_live/1-live/app-emulation/virtualbox-modules/modules_autoload.sh

 # Calculate exec=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
echo "# VirtualBox modules" >/etc/modules_autoload/VirtualBox
qlist app-emulation/virtualbox-modules| xargs -I \{\} basename \{\} .ko >>/etc/modules_autoload/VirtualBox

Раньше об этом костыле не писал, т.к. собирался его красиво оформить, и интегрировать прямо в /etc/init.d/modules
Но, как говорится, нет ничего постояннее чем что-то временное.
И коль руки не доходят допилить - может он и так кому-то пригодится, а может и до ума доведете.

PS
Такой вариант, наверно, удобнее для настройки шаблонами, и вообще - более gentoo-way или даже calculate-way, чем забивать в один файл /etc/conf.d/modules.clt модули имеющие разное назначение.

Да Михаил, красивое решение, спасибо!

Alexander Tratsevskiy wrote:

Да Михаил, красивое решение, спасибо!

Александр, рад что вам понравилось.
Если будете интегрировать это или подобное решение в апстрим, если не тяжело, анонсируйте это в т.ч. в этой ветке.
Новости я просматриваю часто “по диагонали”, и могу не заметить об этом.
А костыли мои неплохо будет убрать, когда подобное решение будет из коробки.

Приятно видеть свое решение работающим

Но по реализации есть парочка вопросов:
# cat /etc/conf.d/modules

<code class="bash">
 # ...
if ls /etc/modules-load.d/*.conf &>/dev/null;then
        for f in /etc/modules-load.d/*.conf;do
                [ -d "${f}" ] && continue
                modules="${modules} $(/bin/sed -re 's/\s*([#;].*$)?//' -e '/^$/d' "${f}")"
        done
fi
</code>

ИМХО, тут два лишних изменения:
# Конструкция if ls /etc/modules-load.d/*.conf видимо необходима чтоб ничего не делать в случае когда ни одного файла отвечающего этой маске нет.
# [ -d "${f}" ] && continue - понятный пропуск директорий либо симлинков на директории.

Теперь рассмотрим мой вариант:

for f in /etc/modules_autoload/*; do
        [ -f "${f}" ] || continue
        modules_3="${modules_3} $(/bin/sed -re 's/\s*(#.*$)?//' -e '/^$/d' < "${f}")" 
done

<<<стыдно>>>
В ходе написания этого ответа обнаружил досадную опечатку У СЕБЯ-ЖЕ ломающую возможность задавать модули по нескольку в строке разделенные пробелом.
А это будет не лишним (к примеру если есть пачка модулей в переменной шаблонов, к примеру как в #-os_install_kernel_cpufreq-#)
Плюс конструкцию с continue и кодом завершения можно заменить еще красивее.
Ниже исправленный вариант.
<<</стыдно>>>
Под условие [ -f "${f}" ] подходят ТОЛЬКО файлы и симлинки на файлы (что нам и нужно).
Все остальные варианты отсекаются: [ -f "${f}" ] || continue

В т.ч. отсекается и вариант при котором файлов не существует.
В этом случае переменная $f просто не пройдет проверку.
Выполнится continue и цикл завершится с кодом завершения 0 (точнее 0 - код ошибки команды continue, последней команды в цикле, и цикл его и вернет).

ИМХО - без лишнего if-а эта конструкция выглядит красивее, при том не теряя функциональность.
Да и вполне логичным видится проверять $f на валидность, а не перебирать все что невалидно (кроме симлинков, файлов и директорий существуют также устройства, пайпы и сокеты)

По поводу переименования директории - абсолютно согласен.
Да и прибавление конфигам расширения .conf выглядит вполне логичным.
Поддерживаю, так оно более эстетично смотрится.

Таким образом вот [<мой конечный вариант>>]{style=“text-align:left;”} /etc/conf.d/modules

for f in /etc/modules-load.d/*.conf; do
    [ -f "${f}" ]  && modules="${modules} $(/bin/sed -re 's/\s*(#.*)?$//' -e '/^$/d' < "${f}")" || :
done

Тут, если $f не файл, то выполнится команда :
Чем всегда обеспечивается код завершения 0 (чтоб не поломать загрузку службы /etc/init.d/modules)


Следующий вопрос по поводу реализации этого:
# cat /var/lib/layman/calculate/profiles/templates/3.1/2_ac_install_merge/app-emulation/virtualbox-modules/virtualbox.conf

 # Calculate comment=# path=/etc/modules-load.d
vboxdrv
vboxnetflt
vboxnetadp

мне кажется забивать жостко список модулей в конфиг плохая идея по двум причинам:
# Во первых - вы забыли про модуль vboxpci, который кому-то очень может пригодиться, но по зависимостям другими модулями не тянется
смотрите сами:
$ for m in vboxdrv vboxnetadp vboxnetflt; do modinfo $m; done |grep vboxpci
Но ошибка понятна - до какой-то версии virtualbox-modules этого модуля небыло, а что будет если в следующей версии модулей список также изменится? хранить несколько шаблонов для разных версий? можно ведь проще.
# Решение получается не очень универсальное.
Лично мне хотелось-бы видеть решение которое можно скопипастить для любого другого пакета, по возможности, ничего не меняя.

Мой вариант так-же не отвечает второму требованию.
Сейчас я бы его привел к следующему виду:

 # Calculate exec=/bin/bash
/usr/bin/qlist app-emulation/virtualbox-modules| /bin/sed -nre 's:^/lib/modules/.*/([^/\.]+)\.ko:\1:p' >/etc/modules-load.d/app-emulation-virtualbox-modules.conf

К сожалению не нашел в документации переменной содержащей имя пакета (может плохо или не там искал)
В идеале я бы хотел видеть что-то вроде
/usr/bin/qlist #-CATEGORY-#/#-PN-#| ...
Возможно все просто, и можно использовать ${CATEGORY}/${PN} (лень было проверять )) ).
Кстати, это вопрос к разработчикам - как в шаблоне подставить категорию/имяпакета?


А в доки по шаблонам можно было-бы поместить что-то вроде:

  • Если вы хотите создавать свои шаблоны - то в директории /var/calculate/templates/ создайте структуру, на подобие той что в /var/lib/layman/calculate/profiles/templates/3.1
    И далее подробное описание этих подпапок, по сути копипста из README)
  • Если хотите подгружать модули из пакета автоматом - создайте в директории со своими шаблонами (тут ссылка на предыдущую доку) папки 2_ac_install_merge/${CATEGORY}/${PN}
    И поместите туда этот файл (содержимое файла для копирования, ссылка на скачивание)

PS

Все эти вопросы - по сути мелкие придирки (хоть и вылились чуть-ли не в статью)
По поводу vboxpci - может действительно не стоит его грузить? может с ним я и перемудрил, и он мало кому нужен.
В любом случае, приятно видеть принятие в апстирим того, что я считал костылем ))

PPS

В новости сказано

В процессе миграции будут пропущены модули управления частотой процессора, т.к. они подгружаются автоматически при изменении параметров частоты.

Можно поподробнее расписать на каком этапе и чем они подгружаются?
Сам я по этому поводу ничего не нашел.

Конструкция if ls /etc/modules-load.d/*.conf видимо необходима чтоб ничего не делать в случае когда ни одного файла отвечающего этой маске нет.

Иначе init.d/modules разваливается приводя систему в нерабочее состояние.

В ходе написания этого ответа обнаружил досадную опечатку У СЕБЯ-ЖЕ ломающую возможность задавать модули по нескольку в строке разделенные пробелом.

ИМХО По одному модулю на строке выглядят лучше: модули в одной строке будут смотреться как параметры модуля. К тому же в этом варианте остается совместимость с systemd на будущее.

А это будет не лишним (к примеру если есть пачка модулей в переменной шаблонов, к примеру как в #os_install_kernel_cpufreq#)

Здесь можно воспользоваться функцией replace.

Но ошибка понятна - до какой-то версии virtualbox-modules этого модуля небыло, а что будет если в следующей версии модулей список также изменится? хранить несколько шаблонов для разных версий? можно ведь проще.

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

Можно поподробнее расписать на каком этапе и чем они подгружаются? Сам я по этому поводу ничего не нашел.

Подгрузка необходимых модулей выполняется при выполнении команды cpufreq-set (а так же при модификации параметров процессора напрямую через sysfs), ondemand устанавливается init.d/cpufrequtils.

К сожалению не нашел в документации переменной содержащей имя пакета (может плохо или не там искал)

Имя пакета и категорию можно получить только при выполнении cl-core-setup: core.cl_core_pkg_name, core.cl_core_pkg_category.

В ходе написания этого ответа обнаружил досадную опечатку У СЕБЯ-ЖЕ ломающую возможность задавать модули по нескольку в строке разделенные пробелом.

Не нашел опечатку, но в скрипте исправил возможность указания нескольких модулей в одной строке. -e 's/^(\S+)\s.*/\1/'

 # Calculate comment=# path=/etc/conf.d

 # autoload modules from /etc/modules-load.d/*.conf files
if ls /etc/modules-load.d/*.conf &>/dev/null;then
    for f in /etc/modules-load.d/*.conf;do
        [ -d "${f}" ] && continue
        modules="${modules} $(/bin/sed -re 's/\s*([#;].*$)?//' -e 's/^(\S+)\s.*/\1/' -e '/^$/d' "${f}")" || :
    done
fi

Конструкция if ls /etc/modules-load.d/*.conf видимо необходима чтоб ничего не делать в случае когда ни одного файла отвечающего этой маске нет.
Иначе init.d/modules разваливается приводя систему в нерабочее состояние.
Таким образом вот мой конечный вариант /etc/conf.d/modules

for f in /etc/modules-load.d/*.conf; do
    [ -f "${f}" ]  && modules="${modules} $(/bin/sed -re 's/\s*(#.*)?$//' -e '/^$/d' < "${f}")" || :
done

Тут, если $f не файл, то выполнится команда :
Чем всегда обеспечивается код завершения 0 (чтоб не поломать загрузку службы /etc/init.d/modules)

Разваливается, если код завершения отличен от нуля. Если использовать конструкцию ||: то этой проблемы нет.

Не нашел опечатку, но в скрипте исправил возможность указания нескольких модулей в одной строке. -e ‘s/^(\S+)\s.*/\1/’

-re 's/\s*([#;].*$)?//' тут проблема в том, что подтираются ВСЕ ПРОБЕЛЫ, а также пробелы (если есть) и следующие за ними комментарии
Т.е. запись содержащая следующие строки

moudle_1 module_2 module_3 ## to make the world a better

## to make people a kinder
module_4 module_5

Преобразуется в

moudle_1module_2module_3
module_4module_5

Таким образом даже частично мир никогда не станет лучше, а люди добрее не будет подгружен хотя-бы один модуль из этого списка.

ИМХО По одному модулю на строке выглядят лучше: модули в одной строке будут смотреться как параметры модуля. К тому же в этом варианте остается совместимость с systemd на будущее.

Ну ОК, совместимость с systemd, пусть и не полная (не проверяются файлы в /{run,usr}/modules-load.d/) - это стоящая вещь.
Но все-равно
# удалять все пробелы плохая идея, имхо
# проверять надо не на “отличие $f от директории”, а на соответствие оного файлу.
# если проверять на соответствие файлу (что более соответствует логике вещей), и использовать || : в ином случае, то конструкция if ls ... будет совершенно лишней.

‘s/\s*([#;].*$)?//’ тут проблема в том, что подтираются ВСЕ ПРОБЕЛЫ

Это если указан модификатор g

удалять все пробелы плохая идея, имхо

Игнорируется все что с права от названия модуля

проверять надо не на “отличие $f от директории”, а на соответствие оного файлу.

Для совместимости с systemd поддерживается симлинк на /dev/null

if ls … будет совершенно лишней

Конструкция рабочая

modules="${modules} $(/bin/sed -re 's/\s*([#;].*$)?//' -e 's/^(\S+)\s.*/\1/' -e '/^$/d' "${f}")" || :

во время загрузки система не может найти /bin/sed и загружает 0 модулей.

 # rc-service modules restart
modules          | * WARNING: you are stopping a boot service
modules          |/bin/sed: can't read : No such file or directory
modules          |/bin/sed: can't read : No such file or directory
modules          | * Autoloaded 0 module(s)

Хотя sed есть:

 # /bin/sed
Usage: /bin/sed [OPTION]... {script-only-if-no-other-script} [input-file]...

Прав не хватает или еще чего?

sed есть - это он ругается, что файла такого-то нет
не покажете что у вас в /etc/modules-load.d/ ?
# ls -lA /etc/modules-load.d/

А также дайте-ка содержимое вашего /etc/conf.d/modules
# cat /etc/conf.d/modules

 # ls -lA /etc/modules-load.d/
total 8
-rw-r--r-- 1 root root  30 Dec 10 10:49 migrate.conf
-rw-r--r-- 1 root root 452 Dec 16 01:44 virtualbox.conf

 # cat /etc/conf.d/modules
#------------------------------------------------------------------------------
 # Modified Calculate-core 3.1.9.1
 # Processed template files:
 # /var/lib/layman/calculate/profiles/templates/3.1/2_ac_install_merge/sys-apps/openrc/modules
 # /etc/conf.d/modules.clt
 # /etc/conf.d/modules.clt
 # For modify this file, create /etc/conf.d/modules.clt template.
#------------------------------------------------------------------------------

 # autoload modules from /etc/modules-load.d/*.conf files
                modules="${modules} $(/bin/sed -re 's/\s*([#;].*$)?//' -e 's/^(\S+)\s.*/\1/' -e '/^$/d' "${f}")" || :

Почитал предыдущие ответы. Почему-то в modules не вписался цикл…

for f in /etc/modules-load.d/*.conf; do
done

# /etc/conf.d/modules.clt

Почитал предыдущие ответы. Почему-то в modules не вписался цикл…

for f in /etc/modules-load.d/*.conf; do
done

Полагаю, у вас есть шаблон /etc/conf.d/modules.clt
который наложился каким-то диким образом на получившийся файл /etc/conf.d/modules после шаблона /var/lib/layman/calculate/profiles/templates/3.1/2_ac_install_merge/sys-apps/openrc/modules