Логика portage при обновлении сторонних ядерных модулей

Зарегистрированные в системе модули останутся только под версию ядра выбранную через eselect kernel.

Т.к. слотов у данных пакетов нет, подозреваю что не только зарегистрированные, но и вообще.

Зарегистрированные в системе модули останутся только под версию ядра выбранную через eselect kernel.

Значит не я дурак а "так и задумано" ™

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

Тут да, согласен, боль без заранее подстеленного FEATURES=«buildpkg»

Тут да, согласен, боль без заранее подстеленного FEATURES=«buildpkg»

FEATURES="buildpkg" ничем не поможет потому-что текущий бинпакет блоба тоже будет под новую версию ибо бин пакет обновится после обновления блоба под новое ведро. В том-то и дело что это тоже фэйл.

Что имеется в виду блобы?? Драйвера для версии ядра кладутся в /lib/modules/... и успешно загружаются при заданной версии ядра. Можете хоть 100500 версий ядер хранить.

функционирующего конфига не осталось потому как под старое (рабочее) ядро блобов уже нет.

как нет? блобы в /lib/modules/староеведро остаются лежать, ничего с ними не происходит.

Ты определись что ты под рабочей версией подразумеваешь? Работающее у тебя на машине? Последнее стабильное/нестабильное?

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

gvtlor, nepank читаем внимательно отсюда:

https://www.linux.org.ru/forum/general/13916737?cid=13916775 © Pinkbyte

Зарегистрированные в системе модули останутся только под версию ядра выбранную через eselect kernel.

…и до обеда. Перевожу на понятный - после описанных манипуляций блобы останутся исключительно только под 4.14.9. Не под старое 3.2.96 и не под обе версии одновременно.

При обновлении пакета что происходит? Правильно старая версия удаляется а новая записывается в систему. Соответственно из старого ядра блоб должен удалится а останется исключительно только под новое ядро.

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

Pinkbyte ну хоть ты не тупи то а! FEATURES="buildpkg" в данном случае не поможет ничем. Смотри было у тебя ядро 3.2.96 (старое) прилетело тебе 4.14.9 (новое) и был у тебя пусть nvidia-drivers это не важно. Ты переключился eselect kernel на новое ядро, собрал его а после этого пересобрал блоб nvidia уже под новое ядро. До момента обновления блоба nvidia под новое ядро твой бинпакет nvidia был… правильно под старое ядро так-же как и сам блоб. А после пересборки блоба под новое ядро старый бинпакет, который был под старое ведро, перезапишется новым который уже стал под новое ведро. Таким образом и будет именно так как написано в твоей цитате вон выше ^. Два бинпакета блоба могут сосуществовать только в одном случае если кроме версии ядра менялась и версия блоба однако в постановке условия вопроса об этом не было ни строчки.

Ээээ... Сам блоб останется под обе версии ядра. Он же лежит в /lib/modules/kernel-version/ и никуда не девается при сборке нового ядра.

Тут проблема в другом, насколько я понимаю. После пересборки nvidia-drivers пересоберутся ещё и opengl'ные и прочие библиотеки, которые лежат в /usr/lib/ и едины для всех ядер. Т.е. ты сможешь загрузиться в старое ядро, старый блоб тоже загрузится, но вот иксы благополучно рухнут, потому как библиотеки, необходимые для их работы, собраны с другой версией ядра и блоба.

Про broadcom и прочих ничего не скажу - не знаю, нужно ли им что-нибудь за пределами /lib/modules/.

Правда, одно уточнение. Я ядро собираю руками без genkernel и не использую initrd. Возможно, там ситуация несколько иная, не знаю.

Он же лежит в /lib/modules/kernel-version/ и никуда не девается при сборке нового ядра.

Сфигли? Выяснили же только что - блоб останется только под ту версию ядра которая выбрана в eselect kernel. И как это блоб «никуда не девается» если он привязан к версии ведра?

Что ты подразумеваешь под словом блоб в данном случае? Я лично - nvidia.ko, модуль ядра. Он никуда не денется, пока ты не почистишь /lib/modules/.

А eselect kernel я не использую, когда приходит новое ядро, иду в /usr/src/linux/ и компиляю его с помощью make && make install. После чего пересобираю сторонние модули (в моём случае - это только nvidia-drivers, раньше ещё vbox-что-то-там было). Так как модули при сборке смотрят в /usr/src/linux/ они собираются уже под новое ядро, поэтому дополнительных телодвижений не требуется.

Может быть eselect как-то чистит /lib/modules/, но это было бы странно.

Он никуда не денется, пока ты не почистишь /lib/modules/.

shell-script т.е. виноват крайний - пакетный манагер (portage) который при пересборке обновлении nvidia-drivers со старого ядра под новое ядро оставляет в системе старую версию nvidia-drivers под старое ядро?

Этот твой вымысел забавен и приятен однако у меня работет как описал Pinkbyte.

Я сейчас не за гентой, поэтому проверить не могу. Вечером доберусь до своего компа посмотрю. Возможно (сейчас придумываю на ходу, надо проверять), nvidia-drivers при установке кладёт собранные файлы не по жёстко заданным путям, а по сгенерированным в зависимости от версии ядра, и потом при обновлении вместо того, чтобы сделать rm на все установленные в прошлый раз файлы и только потом положить новые, просто заново копирует все новые файлы, перезаписывая старые версии. Так как старая версия непосредственно nvidia.ko лежит по другому пути, она остаётся.

Я сейчас не за гентой, поэтому проверить не могу.

всё так и есть: блобы для старого ядра удаляются.

Что ты подразумеваешь под словом блоб в данном случае?

Под блобом я подразумевал nvidia-drivers а за одно и вообще любой сторонний модуль ядра не включенный в состав самого ядра а поставляемый отдельно от него и опакеченный в portage.

А eselect kernel я не использую, когда приходит новое ядро, иду в /usr/src/linux/ и компиляю его с помощью make && make install. После чего пересобираю сторонние модули (в моём случае - это только nvidia-drivers, раньше ещё vbox-что-то-там было).

eselect kernel заведует тем на что указывает твой симлинк /usr/src/linux поэтому ты понял да?

Правда, одно уточнение. Я ядро собираю руками без genkernel и не использую initrd. Возможно, там ситуация несколько иная, не знаю.

genkernel вообще не нужен. Но это к разговору не имеет отношения. Разницы genkernel или если руками собирать не будет никакой.

С initrd единственное что возможно так это если в него были упакованны и модули ядра… то да это спасёт. Но в вопросе об этом не было ни слова. Меня интерисует стандартное поведение portage я его узнал и мало того оно такое-же как я наблюдаю на своеё машине следовательно вывод таракан оглох модули будут под единственное ядро.

всё так и есть: блобы для старого ядра удаляются.

Спасибо.

У меня в Gentoo модули ядра не удаляются. Например:

--- cfgpro   obj /lib/modules/4.14.8-gentoo-r1/misc/vboxpci.ko
--- cfgpro   obj /lib/modules/4.14.8-gentoo-r1/misc/vboxnetflt.ko
--- cfgpro   obj /lib/modules/4.14.8-gentoo-r1/misc/vboxnetadp.ko
--- cfgpro   obj /lib/modules/4.14.8-gentoo-r1/misc/vboxdrv.ko
--- cfgpro   dir /lib/modules/4.14.8-gentoo-r1/misc
--- cfgpro   dir /lib/modules/4.14.8-gentoo-r1

Тут важно ключевое слово «cfgpro».

Смотрим man make.conf

       UNINSTALL_IGNORE = [space delimited list of fnmatch patterns]
              This variable prevents uninstallation of files that match specific fnmatch(3) patterns. In order to  ignore
              file  collisions  with  these files at install time, the same patterns can be added to the COLLISION_IGNORE
              variable.
              Defaults to "/lib/modules/*".

И, собственно, вот оно:

$ grep -r 'UNINSTALL_IGNORE' /usr/portage/profiles/
/usr/portage/profiles/base/make.defaults:UNINSTALL_IGNORE="/lib/modules/* /var/run /var/lock"

UNINSTALL_IGNORE

точно же, я ж обнулил эту фигню, вот модули и удаляются.

Логика portage при обновлении сторонних ядерных модулей (комментарий)

У меня в Gentoo модули ядра не удаляются.

eselect profile show?

И да COLLISION_IGNORE, UNINSTALL_IGNORE которые, кроме прочего, присвоены "/lib/modules/*" это способ portage стрельнуть себе в пятку поскольку sys-kernel/любой-sources здесь ключевое слово sources. В генте ядро опакечено так-же круто как шрифты, к примеру, а те переменные нужны именно для того чтобы на первый взгляд всё выглядело благопристойно а не как в SlackWare/LFS.

точно же, я ж обнулил эту фигню, вот модули и удаляются.

Всё правильно сделал! А то у нас вся система опакечена и ничего же ш своими шаловливыми ручками мы не ставим вот только на «/lib/modules/*» мы скромно закрываем глаза? Зашибись.

а если б оставил по умолчанию, то удаляться не будут.

Этот твой вымысел забавен и приятен однако у меня работет как описал Pinkbyte.

$ find /lib/modules -name nvidia.ko
/lib/modules/4.12.14-gentoo/video/nvidia.ko
/lib/modules/4.14.8-gentoo-r1/video/nvidia.ko

И как же так? Драйвер ставил только с помощью emerge.

всё так и есть: блобы для старого ядра удаляются.

А почему у меня не удаляются?

ты ветку ниже не читал, похоже

Ну вот, похоже, это ты себе в ногу выстрелил.

Ага. Сами наковыряли.

мне-то как бы пофиг, у меня из сторонних модулей только модули ВиртуалБокса.

Выяснили же только что - блоб останется только под ту версию ядра которая выбрана в eselect kernel

Я сказал что зарегистрирован в системе останется только блоб под новую версию ядра. Уточняю - я не уверен удалит ли portage старый файл .ko, о чём тебе и пытается намекнуть shell-script. Есть неиллюзорный шанс, что portage переведет файл в orphaned(что тоже не круто, но учитывая что бинарными файлами в /boot и /lib/modules рулит юзер - приемлимо). Или возможно так было раньше, в старом eclass-е, а потом это «оптимизировали»

Я банально не помню как это делается, потому что это долбанная автоматика, а я последний раз очень давно неудачно обновлял ядро.

Black_Shadow вопрос то обоюдоострый. Если удаляется то «ой в старой версии ядра нету модуля а новое ядро не работает беда печаль». А если не удаляется во первых помойка, фу так делать и слакою пахнет а во вторых обновляется зачастую закрывая баги а у тебя там «ой дырявая версия».

Я сказал что зарегистрирован в системе останется только блоб под новую версию ядра.

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

Ну так ты уж определись. Можно удалять, можно не удалять. Тебе как надо? Возможны оба варианта.

Тебе как надо?

Мне надо правильно а не так как есть. А правильно, по моему, это когда UNINSTALL_IGNORE="/var/run /var/lock" и COLLISION_IGNORE="*.py[co] *\$py.class" и при этом любой сторонний модуль ядра будет под всё версии ядра какие установлены и заведовать ими будет portage а не кривые ручки. Но это уже совсем другой разговор и к теме отношения не имеет.

при этом любой сторонний модуль ядра будет под всё версии ядра какие установлены

Идея неплоха, но требует серьезной доработки соответствующих eclass-ов. А в случае сторонних модулей ядра(ради которых весь сыр-бор) «stable api nonsense» не сильно помогает.

Я хз как там у вас, но у меня не удаляются. И да, я специально ничего не настраивал.

UPD. Ок, уже всё объяснили.

Может быть, так как ты хочешь, и правильно, но тогда всё содержимое /var/lib/modules должно принадлежать своим пакетам, а оно никому не принадлежит. Так же, как и /boot. В данном случае, собранные модули ни чем не лучше пакета с исходниками ядра.

Может быть, так как ты хочешь, и правильно, но тогда всё содержимое /var/lib/modules должно принадлежать своим пакетам, а оно никому не принадлежит.

Чё? О чём ты?

 ➜ file /var/lib/modules
/var/lib/modules: cannot open `/var/lib/modules' (No such file or directory)

Это что за покемон такой? И почему меня должно волновать что-то непринадлежащее ничему да ещё и не существующее у меня?

В данном случае, собранные модули ни чем не лучше пакета с исходниками ядра.

В данном случае либо мы о дистрибутиве с пакетным манагером который и заведует всём либо о слаке/lfs.

/lib/modules конечно

 ➜ equery b /lib/modules/4.14.9-bentoo
 * Searching for /lib/modules/4.14.9-bentoo ... 
app-emulation/virtualbox-modules-5.2.4 (/lib/modules/4.14.9-bentoo)
sys-kernel/bentoo-kernel-4.14.9 (/lib/modules/4.14.9-bentoo)

Ещё есть такие-же глупые вопросы?

$ equery b /lib/modules/4.12.14-gentoo/kernel/drivers/pci/pci-stub.ko 
 * Searching for /lib/modules/4.12.14-gentoo/kernel/drivers/pci/pci-stub.ko ... 
$

Ещё есть такие же глупые ответы?

И что ты хотел этим сказать кроме того что ты неосилятор?

Я неосилятор? С чего вдруг?

init_6 Чувак, ты сам себе злобный буратино. Если не изменять UNINSTALL_IGNORE, то модули ядра останутся под обе версии ядра и можно, а иногда и нужно, спокойно загрузится. Если тебе не нравится, что об этих модулях portage уже ничего не знает, это исключительно твоя проблема, к которой остальные не имеют отношение.

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

Если не изменять UNINSTALL_IGNORE, то portage будет насрать на /lib/modules что неприемлимо в дистрибутиве 21-го века управляемом пакетным манагером. Остальное не более чем твои заблуждения.