RPM/kernel-modules/blacklist: различия между версиями
< RPM
Vt (обсуждение | вклад) Нет описания правки |
Vt (обсуждение | вклад) (примеры для других ошибок) |
||
(не показаны 3 промежуточные версии этого же участника) | |||
Строка 3: | Строка 3: | ||
Есть тонкости запаковки черных списков из-за того, что много пакетов с одним и тем же модулем, но разных версий могут быть установлены одновременно (см. секцию <code>Allow-Duplicated</code> в <code>/etc/apt/apt.conf</code>). | Есть тонкости запаковки черных списков из-за того, что много пакетов с одним и тем же модулем, но разных версий могут быть установлены одновременно (см. секцию <code>Allow-Duplicated</code> в <code>/etc/apt/apt.conf</code>). | ||
# Если известно, что черный список '''не будет меняться''' в будущем, то "проще" запаковать один файл вида <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. | ||
Другие проблемы возникающие с blacklists: | |||
# Некоторые пользователи ставят все доступные внешние модули в систему (<code>update-kernel -a</code>). Поэтому, '''в случае ошибки''' с одним из модулей, который он (пользователь) может даже не использовать, он может или потерять функциональность (если черный список запрещает модуль, который он реально использовал) или не может обновится из-за файловых конфликтов (если мейнтейнер ошибочно поменял файл с черным списком). 🔍 Пример - модуль bcmwl. | |||
# Когда черный список становится '''не нужен''' (скажем модуль стал включен я ядро) - мы не можем его удалить пока остались старые модули в системе. 🔍 Пример - модуль e1000e. | |||
Текущая версия от 17:28, 9 сентября 2023
В случае если внешний (out of tree) модуль конфликтует с внутренним (in tree) модулем ядра иногда делается черный список (см. man modprobe.d
про blacklist
) запрещающий загрузку внутреннего модуля.
Есть тонкости запаковки черных списков из-за того, что много пакетов с одним и тем же модулем, но разных версий могут быть установлены одновременно (см. секцию Allow-Duplicated
в /etc/apt/apt.conf
).
- Если известно, что черный список не будет меняться в будущем, то "проще" запаковать один файл вида
/etc/modprobe.d/blacklist-%module_name.conf
. Так как файл не будет меняться (ни содержимое, ни права на него), то множество пакетов могут иметь один и тот же файл. Если файл в будущем поменяется (или содержимое, или права), то возникнет неразрешимый файловый конфликт. - Если известно, что черный список может меняться в будущем можно заранее запаковать его в отдельный пакет, а у модуля поставить на него зависимость. Таким образом пакет с черным списком будет в системе один и его можно будет менять не порождая файловый конфликт. 🔍 Пример - модуль r8168.
- Если черный список в одном пакете с модулем, но неожиданно поменялся, то можно запаковать новый список с новым именем файла. Минус в том, что старые записи не удалить пока есть пакеты со старыми версиями модуля (но это может быть и не нужно).
- Если внешний модуль должен полностью перекрывать функционал внутреннего модуля, то делать черный список не нужно — а нужно запаковать модуль (.ko файл) в
/lib/modules/%kversion-%flavour-%krelease/updates/
с тем же именем, что и перекрываемый модуль — модули вupdates
имеют наивысший приоритет (см.man depmod.d
описание значения директивыsearch
по умолчанию). Но есть тонкость, что новый модуль должен перекрывать старый и по алиасам. 🔍 Пример - модуль ixgbe.
Другие проблемы возникающие с blacklists:
- Некоторые пользователи ставят все доступные внешние модули в систему (
update-kernel -a
). Поэтому, в случае ошибки с одним из модулей, который он (пользователь) может даже не использовать, он может или потерять функциональность (если черный список запрещает модуль, который он реально использовал) или не может обновится из-за файловых конфликтов (если мейнтейнер ошибочно поменял файл с черным списком). 🔍 Пример - модуль bcmwl. - Когда черный список становится не нужен (скажем модуль стал включен я ядро) - мы не можем его удалить пока остались старые модули в системе. 🔍 Пример - модуль e1000e.