Перестройка / Обновление модуля ядра - PullRequest
0 голосов
/ 28 февраля 2011

Привет, следующая проблема: я использую довольно странный дистрибутив 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] undefined!

Ответы [ 2 ]

0 голосов
/ 02 апреля 2011

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

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

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

0 голосов
/ 28 февраля 2011

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

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

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

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

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

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

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

...