forum.lissyara.su

На днях, столкнулся с проблемой при обновлении ядра в RedHat EL 5.1. Хотел бы попросить знающих людей просветить по поводу... Может Adekamer подтянется - он кажется RedHat занимается?

Суть проблемы - клиенту был отдан сервак с установленой RHEL. Данный сервак подключается к SAN через фибероптические карточки от Qlogic. Сам сервак от IBM и HBA Qlogic карточки тоже от них (их FRU). Драйвера для HBA качались с сайта IBM. Сами драйвера - tar архив с исходниками/бинарниками и make файлом. Процесс их установки что-то вроде make && make install которые надо выполнить в распакованой директории драйверов (был readme в комплекте как что делать).

В общем засада у меня получилась в том, в процессе установки этих замечательных дров, происходит создание нового init image с новоустановленными драйверами-модулями. Это потом надо было прописать в /boot/grub/menu.list. Все было заебись до тех пор пока сам клиент не сделел yum update. Йум, сцуко, услужливо скачал новое редхатовское ядро, поставил его, и перезапустил mkinitrd создав для нового ядра его init образ, в котором, естественно, модулей для HBA уже небыло!

В результате море удовольствия я получил. Спасибо - было круто... Но тема не об этом. Я - убогий БСДшник и признаюсь в этом. Я привык, что, если модули ядра поклажены в /boot/modules и прописаны в /boot/loader.conf то на этом все заканчивается. У нас mkinitrd никто не занимается - инит у нас хавает не скормленный ему img, а парсит conf файлы... Вот такой культурный шок я испытал. Пришлось повторить установку драйверов с нуля (благо отпакованный tar с ними так и остался лежать где надо).

Как быть в такой ситуации? Можно ли вынести такие модули куда-либо вне /usr/lib/[версия кернела]/modules/ как у нас в /boot/modules? Как это автоматизировать? Если (т.е. когда) в очередной раз кто-нибудь запустит update сново придется хвататься за жо@# и бежать исправлять? Посоветуйте что-нибудь, люди добрые

Я убогий виндузятник, но рискну предположить следующее: если добавить нужный модуль в /etc/modules.conf (вот только слова правильные, которые вписывать -- не скажу, это надо в доках вендора порыться), то следующий вызов mkinitrd пересоберет инитрамдрайв с нужными модулями. Но вот не начнет ли yum менять modules.conf при обновлении мне неизвестно. Думаю что не начнет. Кстати, система наверняка сделана по умному -- грузится с обычного раида или диска, а данные лежат в SAN. В такой схеме, наверно есть смысл поковыряться чтобы все работало без создания собственного инитрамдрайва.
ЗЫ
А вообще, извините за банальный совет, если система уже настроена в продакшн -- удалите yum (или лучше переименуйте, или проведите беседу о недопустимости безответственного обновления системы, если нет четкого понимания зачем оно надо), иначе обновление системы будет похоже на русскую рулетку.

да...
а ещё gcc, make и прочие утилиты ))

поставь нелецензионный рхел и живи без проблем ))

Осталось добавить:

убей себя ап стену

убей себя ап стену

Сервак в одну руку, клиента в другую, DVD с RHEL в зубы и фпиред?

отвечаю:
ничего не поделаешь - инитрд - эта такая фенька - которая загружает нужные ядру модули до загрузки всех модулей которые уже дергаются через модпробе или инсмод
инитрд в рхеловом обновлении идет вместе с кернелом (вмлинух) и другими фишками
те делая юм и пользуя новое ядро - флаг руки и барабан на шею - это как в 1це - после обновления - все ваши изменения по кастомации идут лесом
как вариант можно через модпробе в рцлокал или создать свой скрипт - который будет дергать из нужного вам места дергать нужный модуль - но стремно - более того - монтировать тогжа нужные вам устройства придется через автофс
а это своя трабла - тк монтирование производиться только при первом обрашении к каталогу и вообще автофс штука весьма та еще глючная

Спасибо за ответ!
Видимо так и скажу, чтобы они учитывали это в будущем. Составлю описание процесса цепляния дров после апдейта (налабаю им sh скрипт) и все на этом...