аля dkms для Gentoo

накидай
а компилять для Х ядра просто

• akmods при загрузке проверяет, для каких блобов нужно собирать модули (в RPM-Fusion'е предлагается либо устанавливать готовые kmod'ы [модули], либо генерировать их в своей системе akmods'ом). akmods смотрит, какие пакеты akmod-<blob_name>-<blob_version> установлены,— для таких блобов и генерит kmod'ы. В случае Gentoo'ы, наверное, проще, т.к. дополнительных пакетов [с сорцами собирамой части блоба, чем, по сути, и является akmod-<blob_name>-<blob_version>] не нужно — всё есть в портэже / оверлее (или как оно у вас правильно называется). Т.е. фича заключается в том, чтобы, зная, какие блобы установлены в системе, генерить модули именно и только для них.
• akmods помнит, для какой версии блоба и под какое ядро сборка модуля в прошлый раз закончилась неудачно. По умолчанию в следующий раз akmods пропустит сборку такого модуля. Чтобы форсировать сборку такого модуля, существует ключ --force.
• Ключ --akmod <blob_name> означает, что нужно производить сборку модуля только для определённого блоба.
• akmods совместим с несколькими системами инициализации (upstart, systemd и, возможно, с той, которая была до них).
• При загрузке системы для запуска akmods должен быть выполнен ряд условий: не должна стартовать графика (нужно для модулей nvidia, catalyst, etc.); проверка диска уже должна состояться (понятно зачем); если есть какой-либо автоматически запускаемый сервис для поднятия сети, то его запуск должен осуществляться после работы akmods (нужно для модулей wl, rtXXXX, etc.).
• В случае, если при загрузке системы akmods не просто убедился в наличии всех модулей [для текущего ядра], за которые он отвечает, но и сгенерировал какие-либо из них, он автоматически регистрирует «свежие» модули в системе и подгружает их.
• Из сказанного выше, наверное, и так уже понятно, что akmods может использоваться и как сервис, и как обычная текстовая тулза.

Что вспомнил (помимо указанных в предыдущих постах), то написАл. Может, конечно, что и подзабыл, но основное сказал.

Ещё вспомнил:
akmods автоматически отрабатывает после апдейта ядра.

ну это точно лишнее
да и требует демона - нафиг

до сети - это не айс
не факт что сорсы доступны

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

так при обновлении ядра или при загрузке с новым ядром? ;)

А... В генте же сорцы в интернетах! Просто в Fedor'е необходимые сорцы (или заголовочные файлы, не помню точно) от ядра ― в пакете kernel-devel, а от блоба ― в akmod-<blob_name>, т.е. если используется akmods, то всё необходимое уже есть на HDD.

И так, и так, а также если в консоли написать # akmods.

Внесу ясность: демон запускается во время загрузки. Во время нормальной работы системы демон не фунциклирует. Во время апдейта ядра YUM'ом (или надстройками над ним) akmods также запускается самостоятельно, а после завершения своей работы ― «помирает».

он постоянно висит в памяти или кем-то запускается
это явно избыточно

по-моему, это элементарный баш-скрипт

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

Не, в памяти постоянно не висит. Только что проверил.
Мне кажется, оно как-то встраивается в YUM.
Собственно, вот сам пакет: посмотри,― может, чего интересного высмотришь.

а теперь перечитай ещё раз и больше не пори чушь

что перечитать?

тред
в нём расписано почему пересборка всех таких пакетов совсем не то, что нужно

а что нужно?

читай тред!
хватит флудить

читай тред!

оно мне надо? впрочем, мне и твоё поделие, в сущности, не надо, так что хрен с тобой

Тоже как-то думал над подобным скриптом, но так как ещё более ленив, сделал себе такой вот алиас: [code] alias kernel_build=«make && make modules && make modules_install && make install && emerge nvidia-drivers && emerge app-emulation/virtualbox-modules && grub2-mkconfig > /boot/grub2/grub.cfg» [/code]

Изначально хотел ещё добавить туда zcat /proc/config.gz > /usr/src/linux/.config && cd /usr/src/linux, но потом отказался, так как всё-равно нередко конфиг нового ядря просматриваю бегло перед сборкой через make menuconfig.

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

 alias kernel_build="make && make modules && make modules_install && make install && emerge nvidia-drivers && emerge app-emulation/virtualbox-modules && grub2-mkconfig > /boot/grub2/grub.cfg" 

dkms-gentoo-2

#!/bin/bash

. /etc/init.d/functions.sh

DKMS_DB="/var/lib/portage/dkms_db"
KERNEL="$(uname -r)"

case ${1} in

--check ) check(){
  if [ -f "${DKMS_DB}" ];then
	while read PKG MOD PKG_FILE;do
	  MOD_FILE="/lib/modules/${KERNEL}/${MOD}"
	  if [ -f "${MOD_FILE}" ];then
		MOD_VER="$( modinfo "${MOD_FILE}" | awk '/^version/ {print $2}' )"
		PKG_VER="$( modinfo "${PKG_FILE}" | awk '/^version/ {print $2}' )"
		if [ "${PKG_VER}" != "${MOD_VER}" ];then
		  FAILED+=" ${PKG}" 
		  echo "${MOD#*/}" && eend 1
		else
		  echo "${MOD#*/}" && eend 0
		fi
	  else
		FAILED+=" ${PKG}" 
		echo "${MOD#*/}" && eend 1
	  fi
	done < ${DKMS_DB}
	if [ -n "${FAILED}" ];then
	  eselect kernel set linux-${KERNEL}
	  emerge -1 $(echo -e "${FAILED// /\n}" | sort -u) && rm -f /var/tmp/dkms_failed || touch /var/tmp/dkms_failed
	fi
  else
	echo -e "dkms_db not found!\nyou need run:\ndkms-gentoo --db" && return 1
  fi
 }
check;;

--db ) db_rebuild(){
  DB="/var/db/pkg/"
  TARGETS="$(grep "/lib/modules/.*.ko\>" ${DB}*/*/CONTENTS)"

  while read line;do
	MODULE="$(awk '{print $2}' <<< ${line})"
	KO="${MODULE#/*/*/*/}"
	PKG_FULL="${line%/CONTENTS*}"
	export "$(bzgrep "declare -x CATEGORY=" ${PKG_FULL}/environment.bz2 | awk '{print $3}')"
	export "$(bzgrep "declare -x PN=" ${PKG_FULL}/environment.bz2 | awk '{print $3}')"
	DATA+="${CATEGORY//'"'/}/${PN//'"'/} ${KO} ${MODULE}\n"
  done <<< "${TARGETS}"

  echo -e "${DATA%\\n}" | column -t > ${DKMS_DB}
  }
db_rebuild;;

--list )
  if [ -f "${DKMS_DB}" ];then
	awk '{print $1,$2}' ${DKMS_DB} | column -t
  else
	echo "database not found!"
  fi;;

* ) echo \
"Usage: dkms-gentoo [option]
available options:
--db     rebuild database.
--list   display database.
--check  check modules.";;

esac

akmods помнит, для какой версии блоба и под какое ядро сборка модуля в прошлый раз закончилась неудачно

тоже подумал об этом
пока запилил проверку времени изменения базы пакетов и базы dkms
т.к. разница по времени между такой проверкой и пересозданием базы большая - в ~10 раз с чистым кэшем
потому пересоздавать базу при каждом init{0,6} явно оверхед

Обрастает потихоньку фичами ;)

Всё-таки через сравнение времени делаешь?
Хочется надеяться, что не будет лагать в случае сбоев.

сравнение это только для «пересоздавать базу или нет»
а сами модули через modinfo
ну не считать же хэши всех баз, ну!? :3

// Дело в том, что с BASH'ем (как, впрочем, и с любым другим языком) я на «уважаемый» (разве что в консоли иногда чего творю, но скрипты не пишу). Поэтому понять что-либо из гольного кода мне «сложновато».

Ну, раз через modinfo (примерно догадываюсь, что это), то OK.

carasin, короче так:
1. имеем одну базу моделей
2. обновляется она только если база установленных пакетов обновлялась после обновления базы dkms
3. при загрузке проверяется наличие всех модулей для загруженного ядра и соответствие их версий версиям модулей из базы пакетов
4. если модуля нет или версия не та, что в базе пакетов, пересобираем
5. при ошибке сборки создаётся файлик вида «/var/tmp/dkms_failed-`uname -r`»
и при завершении работы база не обновляется, т.к. она станет некорректной
6. при загрузке другого ядра, успешной проверке и обновлённой базе пакетов база dkms обновится
...
чорд, я уже запутался и хз как изложить работу этого скриптика ^_^

да, оно тут поселилось

т.к. она станет некорректной

опа, а вот это не так...надо пофиксить инит скрипт

так что думаешь в свете последних изменений?

Нужен ещё один пункт:

• Перед своей работой скрипт должен проверить «/var/tmp/dkms_failed-`uname -r`» и действовать в зависимости от результатов проверки этого файла.

неа
в этом и фишка
т.к. после фэйла сборки при загрузке я могу руками собрать этот модуль
и при следующей загрузке всё будет пучком

если же НЕ пересоберу, то при следующей загрузке dkms само попытается пересобрать опять
вот так

А зачем тогда вообще «/var/tmp/dkms_failed-`uname -r`» нужен?

Дык оно в любом случае попытается [пере]собрать, если раньше сфейлило: т.е. если был фейл, то либо модуля по-прежнему нет, либо он от старой версии блоба ― т.е. достаточные условия для того, чтобы скрипт начал работать.

вот именно
потому и не надо ничего особенного делать при фейле

да, теперь оно точно лишнее стало
пойду потру

Лучше не тереть, а сделать уведомлялку после логина. Но это уже сложнее.

не, я сделаю из него лог
туда запилить сфэйлившийся пакет и модуль

Ну или так. Это я про то, чтобы не выкидывать уже имеющиеся фичи.

ха, а портаж просто так не отдаёт эту инфу

а по одному собирать...это долго и костыльно

А не лучше kernel брать из выхлопа eselect, или выцеплять по ссылке /usr/src/linux
У тебя вроде (не вчитывался сильно в скрипт) предполагается, что ты уже поставил новое ядро и ребутнулся .
Если еще не ребутался, то сборка будет для текущеего, версию которого ты определяешь по KERNEL=«$(uname -r)», не ?

да, сборка для текущего всегда
пока в планах нет сборки пакетов под нетекущее ядро

и да - dkms как раз для автоматической пересборки отсутствующих/устаревших модулей при загрузке
а если до этого, то есть eselect и module-rebuild

Не понял, какую инфу?

какой именно пакет сфейлился

Ничего не понял.

Определять, сборка какого модуля не удалась, разве не твой скрипт должен?

Или ты имеешь в виду, что твой скрипт обращается к портэжу за инфой об установленном блобе, а тот партизанит?

Определять, сборка какого модуля не удалась, разве не твой скрипт должен?

пока что нет
пока его задача просто пересобрать отсутствующие/устаревшие