/etc/conf.d/modules

Как сделать, чтобы список загружаемых автоматически модулей ядра (“modules_3=…”) не сбрасывался к содержимому переменной os_install_kernel_cpufreq при каждом обновлении calculate-sources?.

1. Настроить

/etc/conf.d/modules

2. Сохранить настройки как clt

cp /etc/conf.d/modules /etc/conf.d/modules.clt

Или такой вариант уже не проходит?

.clt не проходит. В версиях 9-12 это работало, теперь нет

настроить… каждый раз писать руками или копировать из файла можно (тот же modules.clt), можно сделать шаблон /var/calculate/templates/3.1/3_ac_install_live/1-live/sys-apps/openrc/conf.d/modules и из консоли Calculate запускать настройку пакета openrc, но хочется обойтись без подобных дополнительных телодвижений.

Такое ощущение, что всегда применяется шаблон из оверлея, а шаблон из /var/calculate/templates игнорируется, либо же я неправильно его размещаю и он просто не должен в данном случае применяться.

Шаблон из оверлея применяется в любом случае, все ручные действия бессмысленны.

PIT Rider wrote:

  1. Настроить
    […]
  2. Сохранить настройки как clt
    […]

Или такой вариант уже не проходит?

Такой вариант работает и получившийся шаблон modules.clt при установке openrc полностью перепишет /etc/conf.d/modules.
Но это противоречит концепции шаблонов.
Требуется только лишь изменить состояние выбранной переменной. У меня работает следующий код для переменной modules_3.

/etc/conf.d/modules.clt:

_# Calculate format=openrc
modules_3=“acpi-cpufreq cpufreq_conservative cpufreq_powersave cpufreq_userspace mperf speedstep-lib vboxdrv”_

Обнаружена следующая засада.
При обновлении мира (#emerge -uDN world) переписывается файл /etc/conf.d/modules
согласно базовому шаблону, т.е. фактически приходит в начальное состояние, и при этом всё происходит по тихому. Выясняется это когда внезапно оказывается, что не загружены нужные модули.
.
Мы знаем, что этот файл пренадлежит openrc.
$ equery b /etc/conf.d/modules
sys-apps/openrc-0.11.8 (/etc/conf.d/modules)
.
Но обновление согласно локальному .clt шаблону происходит только так:
#emerge -1 openrc
IMPORTANT: config file /etc/conf.d/modules needs updating
Кто знает почему?
У кого нибудь работает нормально?
.
Linux Calculate 3.9.4-calculate #1 SMP PREEMPT x86_64 Intel® Core™ i3-2350M CPU @ 2.30GHz GenuineIntel GNU/Linux

Да, все именно так и происходит

Господа, а нельзя ли сделать так, чтобы /etc/conf.d/modules.clt применялся бы и после установки нового ядра и\или module-rebuild, а не только openrc? Иначе, когда ручками, через cl-kernel, новое ядро ставлю, модули виртуалбокса из modules исчезают, несмотря на лежащий рядом шаблон. У меня виртуалка сразу стартует скриптом в фоне после загрузки, а модулей нет, нежданчик. Я из положения вышел, подгружаю его модули через local скрипт, но хочется штатного функционала.

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

Исходя из соображения, что после установки ядра, необходимо выполнять

module-rebuild -X rebuild

по которому пересоберутся virtualbox-modules

Я сделал шаблон по событию ac_install_merge для пакета app-emulation/virtualbox-modules

Так тоже можно, конечно. В идеале разработчикам надо снабдить каждый несущий свои модули пакет таким шаблоном. Идеологически правильнее было бы класть каждому приложению с модулем именной конфиг в какой нибудь каталог в /etc, например /etc/modules.autload/, и парсить его при запуске/останове /etc/init.d/modules. А в /etc/conf.d/modules не писать никакой автоматикой, оставить его для ручной настройки, для чего он, как и большинство конфигов в /etc/conf.d, и предназначен.

IMHO система шаблонов в текущей реализации неудачна и потенциально опасна. Приведу ещё один пример. С появлением в /etc/rc.conf rc_parallel=“YES” у меня стали появляться трудности с домашней машиной.

Я часто включаю и выключаю её удалённо, по сети, когда появляется необходимость забраться на неё с работы. Помимо стандартных на ней стартует уйма серверных демонов и несколько виртуалок в фоне. При параллельной загрузке всё это хозяйство непредсказуемо глючит. Как старый гентушник, баловавшийся этой “фичей” ещё миллион лет назад, первым делом я это отключил, как только увидел. Однако система, с упорством идиота, включила мне её обратно после обновления. Решил шаблоном, конечно же.

Мне одному такое поведение кажется странным? Почему мне надо писать шаблоны для таких вещей? Почему система считает себя умнее её админа и молча гадит ему в конфиги? Почему я должен писать конфиги для конфигов? Почему о том, что мне молча переписали конфиг и нужно бы родить пользовательский шаблон, я узнаю после уже случившегося нежданчика?

Когда то в конце прошлого века я выбрал Slakware, именно за отсутствие вспомогательных конфигуряторов и неестественного интеллекта. Затем, мучаясь по долгу службы с виндой и RedHat на серверах, основной своей системой сделал Gentoo, именно по причине бережного отношения к моим конфигам и наличия etc-update, то есть, по сути, за уважение к моему труду. Чисто психологически мною, старым гентушником, то что сейчас вытворяет Calculate воспринимается как оскорбление идеалов, лол.

PS. Ещё раз: всё написаное выше IMHO. Пока плюсы системы перевешивают минусы. Извините, наболело.

То есть если Вы в ручную поменяли в /etc/rc.conf параметр rc_parallel, а утилиты правят сам файл, не создавая ._cfg0000_rc.conf ? А что у Вас содержится в /etc/calculate/calculate.env . Какая версия calculate утилит у используется?

Сейчас уже создаст, наверное, а вот раньше не создавала. Столкнувшись с подобным поведением я сразу же создал свой cfg шаблон. И сейчас создаю их уже на рефлексах :slight_smile:

Вышенаписанный крик души возник после очередной битвы с modules, после в очередной раз проигнорированного системой modules.cfg. А так сейчас уже почти терпимо стало, после того как утилиты начали вопросы хотя бы задавать, переписать мне конфиг или нет.

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

Пример clt-шаблона /etc/rc.conf.clt:

 # Calculate format=openrc
rc_parallel="NO"

Я делаю .clt шаблоны, но утилиты не всегда воспринимают их и часто переписывают конфиги не создавая файлов типа ._cfg0000_rc.conf. Как все таки заставить утилиты создавать их всегда?

Есть ли утилита, которая пройдется по системе, чтобы применить локальные .clt шаблоны к уже существующим конфигам?
Т.к. бывает не понятно, какие конфиги успели переписаться без предупреждения, какие нет.

стоит cl_autoupdate_set = off

Есть некоторые файлы, для которых не создаются ._cfg файлы:

  • env.d/02locale
  • make.conf
  • timezone

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

Машина доменная или нет?

Все таки шаблоны пока живут своей жизнью. Это напрягает - вот последовательность действий и результат:

  1. обновлен пакет calculate-utilities
  2. компьютер перезагружен
  3. загружены модули из списка modules_3=“acpi-cpufreq cpufreq_conservative cpufreq_powersave cpufreq_userspace mperf speedstep-lib vboxdrv
  4. система прогружается чуть дольше обычного
  5. проверяем /etc/conf.d/modules: modules_3=“acpi-cpufreq cpufreq_conservative cpufreq_powersave cpufreq_userspace mperf speedstep-lib”
  6. Что произошло во время загрузки после обновления? /etc/conf.d/modules был изменен именно после перезагрузки.

Почему система восстановила переменную modules_3, забив на modules.clt, и вообще без предупреждения?

Машина не в домене. Установлен CLD-13.6.

такая же проблема исчезает загрузка модуля ndiswrapper, до ребута в файлике все на месте после перезагрузки уже модуль не загружается и сети естественно нет.

Вопрос остается открытым - при каждом обновлении calculate-utilities содержимое файла /etc/conf.d/modules сбрасывается к виду шаблона по умолчанию для openrc, т.е. modules_3=os_install_kernel_cpufreq. Это работает и на серверном, и на клиентских дистрибутивах. Каков смысл скрипта fix0penrc?