RPM/kernel-modules/blacklist: различия между версиями

Материал из ALT Linux Wiki
< RPM
(Новая страница: «В случае если внешний (out of tree) модуль конфликтует с внутренним (in tree) модулем ядра иногда делается черный список (см. <code>man modprobe.d</code> про <code>blacklist</code>) запрещающий загрузку внутреннего модуля. Есть тонкости запаковки черных списков из-за того, что много п...»)
 
Нет описания правки
Строка 4: Строка 4:


# Если известно, что черный список '''не будет меняться''' в будущем, то "проще" запаковать один файл вида <code>/etc/modprobe.d/blacklist-%module_name.conf</code>. Так как файл не будет меняться, то множество пакетов могут иметь один и тот же файл. Если файл в будущем поменяется, то возникнет неразрешимый файловый конфликт.
# Если известно, что черный список '''не будет меняться''' в будущем, то "проще" запаковать один файл вида <code>/etc/modprobe.d/blacklist-%module_name.conf</code>. Так как файл не будет меняться, то множество пакетов могут иметь один и тот же файл. Если файл в будущем поменяется, то возникнет неразрешимый файловый конфликт.
# Если известно, что черный список '''может меняться''' в будущем можно заранее запаковать его в отдельный пакет, а у модуля поставить на него зависимость. Таким образом пакет с черным списком будет в системе один и его можно будет менять не порождая файловый конфликт. Пример - модуль r8168.
# Если известно, что черный список '''может меняться''' в будущем можно заранее запаковать его в отдельный пакет, а у модуля поставить на него зависимость. Таким образом пакет с черным списком будет в системе один и его можно будет менять не порождая файловый конфликт. 🔍 Пример - модуль r8168.
# Если черный список в одном пакете с модулем, но неожиданно поменялся, то можно запаковать новый список '''с новым именем файла'''. Минус в том, что старые записи не удалить пока есть пакеты со старыми версиями модуля (но это может быть и не нужно).
# Если черный список в одном пакете с модулем, но неожиданно поменялся, то можно запаковать новый список '''с новым именем файла'''. Минус в том, что старые записи не удалить пока есть пакеты со старыми версиями модуля (но это может быть и не нужно).
# Если внешний модуль должен полностью перекрывать функционал внутреннего модуля, то делать черный список '''не нужно''' — а нужно запаковать модуль (.ko файл) в <code>/lib/modules/%kversion-%flavour-%krelease/updates/</code> с тем же именем, что и перекрываемый модуль — модули в <code>updates</code> имеют наивысший приоритет (см. <code>man depmod.d</code> описание значения директивы <code>search</code> по умолчанию). Пример - модуль ixgbe.
# Если внешний модуль должен полностью перекрывать функционал внутреннего модуля, то делать черный список '''не нужно''' — а нужно запаковать модуль (.ko файл) в <code>/lib/modules/%kversion-%flavour-%krelease/updates/</code> с тем же именем, что и перекрываемый модуль — модули в <code>updates</code> имеют наивысший приоритет (см. <code>man depmod.d</code> описание значения директивы <code>search</code> по умолчанию). Но есть тонкость, что новый модуль должен перекрывать старый и по алиасам. 🔍 Пример - модуль ixgbe.
 


{{Category navigation|title=RPM|category=RPM}}
{{Category navigation|title=RPM|category=RPM}}
[[Категория:RPM]]
[[Категория:RPM]]
[[Категория:Devel]]
[[Категория:Devel]]

Версия от 01:32, 8 сентября 2023

В случае если внешний (out of tree) модуль конфликтует с внутренним (in tree) модулем ядра иногда делается черный список (см. man modprobe.d про blacklist) запрещающий загрузку внутреннего модуля.

Есть тонкости запаковки черных списков из-за того, что много пакетов с одним и тем же модулем, но разных версий могут быть установлены одновременно (см. секцию Allow-Duplicated в /etc/apt/apt.conf).

  1. Если известно, что черный список не будет меняться в будущем, то "проще" запаковать один файл вида /etc/modprobe.d/blacklist-%module_name.conf. Так как файл не будет меняться, то множество пакетов могут иметь один и тот же файл. Если файл в будущем поменяется, то возникнет неразрешимый файловый конфликт.
  2. Если известно, что черный список может меняться в будущем можно заранее запаковать его в отдельный пакет, а у модуля поставить на него зависимость. Таким образом пакет с черным списком будет в системе один и его можно будет менять не порождая файловый конфликт. 🔍 Пример - модуль r8168.
  3. Если черный список в одном пакете с модулем, но неожиданно поменялся, то можно запаковать новый список с новым именем файла. Минус в том, что старые записи не удалить пока есть пакеты со старыми версиями модуля (но это может быть и не нужно).
  4. Если внешний модуль должен полностью перекрывать функционал внутреннего модуля, то делать черный список не нужно — а нужно запаковать модуль (.ko файл) в /lib/modules/%kversion-%flavour-%krelease/updates/ с тем же именем, что и перекрываемый модуль — модули в updates имеют наивысший приоритет (см. man depmod.d описание значения директивы search по умолчанию). Но есть тонкость, что новый модуль должен перекрывать старый и по алиасам. 🔍 Пример - модуль ixgbe.


RPM