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