LINUX.ORG.RU

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

 , ,


0

1

Предположим был установлен =sys-kernel/vanilla-sources-3.2.96::gentoo и x11-drivers/nvidia-drivers или net-wireless/broadcom-sta любой из них и версия любая на выбор. Затем ядро обновили, к примеру, до =sys-kernel/vanilla-sources-4.14.9::gentoo, собрали новое ядро и пересобрали x11-drivers/nvidia-drivers, net-wireless/broadcom-sta под него.

Внимание вопрос - после проделанных выше манипуляций под какую именно версию ядра (старую, новую или под обе?) остались рабочие блобы nvidia, broadcom?

★★★★★

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

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

Pinkbyte ★★★★★ ()
Ответ на: комментарий от Pinkbyte

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

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

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

init_6 ★★★★★ ()
Ответ на: комментарий от Pinkbyte

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

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

init_6 ★★★★★ ()
Ответ на: комментарий от init_6

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

gvtlor ()
Ответ на: комментарий от init_6

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

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

Deleted ()
Ответ на: комментарий от init_6

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

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

Pinkbyte ★★★★★ ()

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 был… правильно под старое ядро так-же как и сам блоб. А после пересборки блоба под новое ядро старый бинпакет, который был под старое ведро, перезапишется новым который уже стал под новое ведро. Таким образом и будет именно так как написано в твоей цитате вон выше ^. Два бинпакета блоба могут сосуществовать только в одном случае если кроме версии ядра менялась и версия блоба однако в постановке условия вопроса об этом не было ни строчки.

init_6 ★★★★★ ()

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

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

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

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

shell-script ★★★★★ ()
Ответ на: комментарий от shell-script

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

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

init_6 ★★★★★ ()
Ответ на: комментарий от init_6

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

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

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

shell-script ★★★★★ ()
Ответ на: комментарий от shell-script

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

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

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

init_6 ★★★★★ ()
Последнее исправление: init_6 (всего исправлений: 1)
Ответ на: комментарий от init_6

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

shell-script ★★★★★ ()
Ответ на: комментарий от shell-script

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

Под блобом я подразумевал 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 я его узнал и мало того оно такое-же как я наблюдаю на своеё машине следовательно вывод таракан оглох модули будут под единственное ядро.

init_6 ★★★★★ ()
Ответ на: комментарий от init_6

У меня в 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"

Aegir ()
Ответ на: комментарий от Aegir

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

eselect profile show?

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

init_6 ★★★★★ ()
Последнее исправление: init_6 (всего исправлений: 1)
Ответ на: комментарий от Deleted

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

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

init_6 ★★★★★ ()
Ответ на: комментарий от init_6

Этот твой вымысел забавен и приятен однако у меня работет как описал 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.

Black_Shadow ★★★★★ ()
Ответ на: комментарий от init_6

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

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

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

Pinkbyte ★★★★★ ()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от Black_Shadow

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

init_6 ★★★★★ ()
Ответ на: комментарий от Pinkbyte

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

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

init_6 ★★★★★ ()
Ответ на: комментарий от Black_Shadow

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

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

init_6 ★★★★★ ()
Ответ на: комментарий от init_6

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

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

Pinkbyte ★★★★★ ()
Ответ на: комментарий от init_6

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

Black_Shadow ★★★★★ ()
Последнее исправление: Black_Shadow (всего исправлений: 1)
Ответ на: комментарий от Black_Shadow

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

Чё? О чём ты?

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

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

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

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

init_6 ★★★★★ ()
Ответ на: комментарий от Black_Shadow
 ➜ 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)

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

init_6 ★★★★★ ()
Ответ на: комментарий от init_6

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

gvtlor ()
Ответ на: комментарий от gvtlor

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

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

init_6 ★★★★★ ()