[Comm] опыт апгрейда с ALM2.0 до ALM2.4 через ALM2.2.

[Denis G. Samsonenko]

Hi!

С выходом ALM2.4 решил наконец-то обновить один небольшой
сервачок на работе, на котором крутился на тот момент
ALM2.0. Обновить решил по двум причинам: во-первых апдейты
не выпускаются, во-вторых хотел настроить правильное
отключение сервера по кнопке питания на корпусе.

Процедуру эту произвёл в два этапа.

Этап первый: из ALM2.0 в ALM2.2. Этот этап я проходил
раньше на своей домашней машине. Сдесь же это было с одной
стороны проще, по скольку не было всяких там KDE и прочих
X-ов, с другой стороны огрёб некорое количество граблей по
поводу SCSI диска (sda5), на котором находился корневой
раздел.

После обновления системы и установки нового ядра решил на
свою голову перезагрузиться с этим новым (из ALM2.2) ядром
и тут же получил сообщение, что не может подмонтировать
корневую файловую систему. Оказалось, что сгенерённый
initrd оказался без модуля sym53c8xx, который был нужен
для работы SCSI диска.

Загрузившись с первого диска ALM2.2 в rescue режиме
(chroot /mnt) перегенерил initrd в /boot (на hda5).
Почему-то после этого не отработала команда reboot, и я
нажал на reset, забыв отмонтировать дисковые разделы, что
незамедлительно повлекло следующие грабли, а именно
зацикливание проверки корневой файловой системы, что
дождаться приглашения входа в систему я не смог.

Снова загрузившись в rescue режиме я попытался прогнать
fsck.ext2 вручную, но получил отлуп с сообщением, что
файловая система диске более новой версии, чем fsck на CD
от ALM2.2 (хотя в своё время я их как раз и создавал дома
на
машине с установленным ALM2.2).

Пришлось выдирать из соседней машины DVD привод, чтобы
загрузиться с DVD ALM2.4 с целью провести проверку
файловой системы уже заведомо новым fsck'ом. Но каково же
было моё удивление, когда я обнаружил, что мой SCSI диск
не определился и его разделы не видны, в то время, как при
загрузке с инсталляционного CD ALM2.2 всё было нормально.

Вариант modprobe sym53c8xx из консоли не дал результатов,
т.к. такого модуля не нашёл. Тут мне пришлось обратиться к
www.google.ru с запросом "sym53c8xx site:altlinux.ru". В
результате поиска я обнаружил, что искомый модуль теперь
называется sym53c8xx_2. Выполнив modprobe sym53c8xx_2 я
смог получить доступ к нужному диску и выполнить fsck.ext2
-p /dev/sda5. После чего благополучно загрузился.

Второй этап: из ALM2.2 в ALM2.4. Этот этап прошёл без
особых проблем. Сначала обновил apt и rpm, которые
потянули за собой glibc и прочее, затем обновил всё
остальное. Поправил конфиг samba и apache запустил их и
убедился в их работоспособности.

Проверка работоспособности fetchmail выявила слежующую
проблему: почему-то не резолвятся имена серверов. Данной
проблеме кроме fetchmail'а оказались подвержены lynx,
ping, traceroute, hostinfo etc. А вот для host этой
проблемы не существовало.

Провозившись с /etc/resolv.conf, /etc/host.conf,
update_chrooted и чтением книг, понял, что проблема скорее
всего в отсутствии какой-то из библиотек. Анализ вывода
"strace hostinfo www.ngs.ru" показал отсутствие в системе
библиотеки /lib/libnss_dns.so.2, содержащейся в пакете
glibc-nss. После установки этого пакета проблема с
резолвингом имён пропала.

Потратив на выше описанные пляски с бубном полтора дня я
оставил коллегу разбираться с horde/imp, а сам пошёл домой
описывать впечатления.

После всего выше описанного у меня осталось два вопроса:

1) почему инсталлятор ALM2.4 не подхватил мой SCSI диск, в
отлисие от инсталлятора ALM2.2;

2) почему при обновлении не установился пакет glibc-nss,
содержащий необходимую для успешного резолвинга имён
библиотеку, неужели она нигде не была прописана в
зависимостях?

Вот такие дела.

Best regards,

Denis.

----------
earthsea на ngs.ru
---------------------------------------------------------
http://mobile.ngs.ru/games - Java-игры для мобильников и не только...
http://love.ngs.ru - Знакомства в Новосибирске