Перестройка / Обновление модуля ядра

Question

Привет, следующая проблема: я использую довольно странный дистрибутив linux здесь на работе (Centos 5), который, кажется, имеет более старое ядро ​​(или, по крайней мере, некоторые различия в ядре), и вы не можете просто обновить его. Программа, которую мне нужно установить, нуждается в функции crypto_destro_tfm (и, вероятно, еще немного, но это единственная ошибка на данный момент), которая включена в файл linux/crypto/api.c - поэтому я предполагаю, что она находится в модуле ядра crypto_api. Проблема в том, что в моем дистрибутиве у меня даже нет crypto / api.c, и хотя у меня есть модуль crypto_api.ko, похоже, что этой функции там нет.

Мой план следующий: возьмите crypto_api из более нового дистрибутива Linux, а затем скомпилируйте его и загрузите модуль в мои centos.

Теперь я надеюсь, что некоторые из вас скажут мне, что мне нужно сделать, чтобы перестроить и заменить этот модуль. Конечно, у меня есть все исходные файлы из более нового ядра. (Напоминаю: я не могу просто перекомпилировать и использовать более новое ядро, b/c centos отстой таким образом) Спасибо

FWIW: вот точная ошибка

ВНИМАНИЕ: "crypto_destroy_tfm" [/home/Chris/digsig-patched/digsig_verif.ko] не определено!

Answer 1

Существует большая вероятность того, что обратное изменение API в старом ядре приведет к каскаду проблем. Предположим, вы вернули crypto api версии 2.6.Y на локальную версию 2.6.X

Теперь у вас следующая ситуация:

• модуль crypto api export 2.6.Y функции
• Ваш внешний модуль может быть доволен этой ситуацией
• все другие модули, которые зависят от версии 2.6.X крипто API, будут жаловаться.

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

Если вы не можете обновить ядро ​​CentOS, потому что в ядре CentOS есть много пользовательского кода, который вы боитесь потерять при работе с "ванильным" ядром, то вы можете обнаружить, что проще "понизить" версию своего внешнего модуль:

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

В любом случае вы не сможете заменить ядро ​​на ванильное, но вы должны хотя бы уметь его перестраивать, а затем исправлять, перестраивать и т. Д. Если вы не можете выполнить эту простую задачу тогда я не думаю, что бэкпортирование чего-либо будет успешным.

Answer 2

Попробуйте загрузить RPC-версию SRC из более новой версии CentOS, в которой есть модуль, и перекомпилируйте RPM-версию на CentOS 5:

rpmbuild --rebuild kernel-X.XX-X.src.rpm

У меня нет копии CentOS для сравнения, поэтому вы можете прочитать страницу руководства в rpm / rpmbuild, но я обнаружил, что перекомпилировать весь пакет, включающий ядро ​​и все его модули, безопаснее, чем просто попытаться портирование одного модуля из более нового ядра. Я делаю это иногда в Debian/Ubuntu, когда мне нужен более новый пакет для чего-либо.