From: Алексей Барабанов <alekseybb@mail.ru.>
Newsgroups: http://www.barabanov.ru
Date: Mon, 12 Jun 2005 18:21:07 +0000 (UTC)
Subject: Обновление SuSE Linux 9.0 до 9.1 с помощью apt.
Предлагаемый способ апгрейда версии установленного SuSE линукс имеет
ценность не только для любителей apt, но и в некоторых случаях
позволяет обойти ограничения, накладываемые рабочей средой. Самым
важным качеством обновления через apt является то, что процесс
полностью контролируем. Хотя обновление через YaST оставляет
возможность наблюдения за процессом с другой консоли, но в случае
возникновения проблем с обновлением нужно нешуточно постараться, чтобы
не упустить момент, когда его следует поправить или срочно прекратить.
Отказ от ответственности !
Автор не несет ответственность за возможные негативные последствия
из-за применения изложенных в статье рекомендаций. И не консультирует
по вопросам восстановления поврежденных систем даже за вознаграждение.
Итак, в исходном состоянии имеется установленный SuSE Linux 9.0 в
дефолтной конфигурации. Все это работает под управлением VMware
workstation 4.0.5.
Целью будем считать обновление этой системы до версии 9.1 с
использованием apt.
Загрузка и инсталляция пакетов клиентской части apt.
Здесь для примера приводится способ загрузки пакетов apt из
Интернета. Но ничего не мешает поместить их на локальный диск
и иначе. Суммарный объем не превышает 1.4 Мбайт, что
позволяет перенести их на обычной дискете.
Если пакеты не найдены на указанном ftp, то их можно поискать
через RPM Search (http://rpm.pbone.net/).
Если есть уверенность, что в текущей директории нет более
иных rpm файлов, то чтобы не набирать длинные имена можно
просто :
# rpm -ivh *.rpm
Подключение репозитория на дистрибутивном dvd.
Конечно, установка с настроенного репозитория с дистрибутивного
dvd не исчерпывает всего богатства возможностей выбора источников
в apt. Можно воспользоваться уже существующими в Сети аналогичными
репозиториями, можно создать собственный в локальной сети, можно
просто примонтировать тот же apt репозиторий на dvd к корню
локально сервера ftp. Все эти варианты оставим за рамками
настоящей статьи. Здесь будем считать, что апгрейд производится с
apt репозитория на dvd, подготовленного, так как описано в
кратком руководстве, размещенном на этом же сайте
(http://www.barabanov.ru/arts/how-to-prepare-suse-apt-cd.html).
Тем самым мы укажем точку монтирования cdrom, принятую в
SuSE, и уничтожим все доступные предустановленные в apt
источники обновления.
2. Подключим репозиторий на диске.
# apt-cdrom add
Далее надо будет вставить диск с репозиторием, подтвердить
это нажатием Enter и, после нахождения индексов программой,
ввести наименование полученного источника. Название можно
выбрать произвольно. Один из вариантов диалога может
выглядеть так :
Using CD-ROM mount point /media/cdrom/
Unmounting CD-ROM
Please insert a Disc in the drive and press enter
Mounting CD-ROM
Identifying.. [db1517f20d230e65a5be165a2686f110-2]
Scanning Disc for index files.. Found 1 package indexes and 1 source indexes.
Please provide a name for this Disc, such as 'Distribution Disk 1':
SuSE 9.1 Prof Side A
This Disc is called:
'SuSE 9.1 Prof Side A'
Reading Indexes... Done
Reading Indexes... Done
Writing new source list
Source List entries for this Disc are:
rpm cdrom:[SuSE 9.1 Prof Side A]/ apt/SUSE/9.1/i586 origin
rpm-src cdrom:[SuSE 9.1 Prof Side A]/ apt/SUSE/9.1/i586 origin
Repeat this process for the rest of the CDs in your set.
Апгрейд.
Некоторые из предложенных далее шагов имеют неочевидное
происхождение. Можно поэкспериментировать с вариантами. Следует
только не забывать о мере ответственности при таких экспериментах
на работающей системе. Процесс нельзя прерывать и нельзя
перегружать систему "на ходу". Если система работает в условиях
ненадежной сети питания, стоит позаботиться об источнике
аварийного питания. Но если все-таки в результате фатального
стечения обстоятельств была получена поврежденная незагружаемая
система, то для ее "ремонта" надо будет загрузиться с
дистрибутивного диска, выбрав в загрузочном меню "rescue disk".
Если загрузка спасательного диска потребует дополнительно указания
языка, а в SuSE это именно так, то следует его указать. И здесь
лучше выбрать предложенное по умолчанию US. Далее, после получения
приглашения к логину ввести имя привилегированного бюджета root и
выйти в консоль. Описание процесса восстановления не входит в
задачу этой статьи, но в качестве примера приведем типичный набор
команд для перехода из среды спасательного диска в среду локальной
системы :
# mount /dev/hda2 /mnt
# chroot /mnt /bin/sh
# mc
Предполагается, что /dev/hda2 является дисковым разделом с корнем
системы. Если это не так, то рекомендуется запомнить
действительное расположение корня системы заранее, чтобы потом
сократить число попыток монтирования наугад.
Итак, апгрейд.
1. Пробуем апгрейд в режиме dry-run.
# apt-get -s dist-upgrade >dist-upgrade.txt 2>&1
Выдача этой команды будет очень большой. Поэтому сразу же
перенаправляем ее в файл. Один из результаты работы на
тестовой системе приведены в отдельном [3]файле, который не
включен непосредственно в текст из-за его объема. Важная для
работы строка находится грепом :
# grep "newly installed" dist-upgrade.txt
436 upgraded, 33 newly installed, 13 replaced, 20 removed and 10 not upgraded.
Это резюме говорит о том, что apt "берется" за апгрейд и
предполагает его успех.
2. Производим апгрейд всерьез.
# apt-get dist-upgrade
После оценки объемов установок и обновлений apt предложит
выразить согласие с его рекомендациями, построенными на
основе изучения зависимостей в rpm репозитории SuSE. Нужно
ответить точно так, как это требует apt. В данном случае
заглавным "Y". На экране это выглядит примерно так :
[...]
436 upgraded, 33 newly installed, 13 replaced, 20 removed and 10 not upgraded.
Need to get 0B/427MB of archives.
After unpacking 83.1MB of additional disk space will be used.
Do you want to continue? [Y/n] Y
Дополнительно здесь сообщается тот объем, который займет
процесс обновления на локальной файловой системе. В данном
случае это более полугигобайта. Следует позаботиться о
наличии свободного места на обновляемой системе.
Не надо удивляться, что после длительного копирования пакетов
в кеш apt, апгрейд прервется из-за конфликта в пакете
man-pages. Увы, нет совершенства во взаимосвязях rpm SuSE, в
чем не раз придется убедиться.
[...]
Checking GPG signatures...
Committing changes...
Preparing...
file /usr/share/man/man3/getspnam.3.gz from install of man-pages-1.66-3
8 conflicts with file from package shadow-4.0.3-182
file /usr/share/man/man5/passwd.5.gz from install of man-pages-1.66-38
conflicts with file from package shadow-4.0.3-182
E: Error while running transaction
Конфликтный пакет придется установить насильно и с помощью
средств более низкого уровня. Воспользуемся тем, что он уже
загружен в кеш. Обратите внимание на некоторую модификацию
разделителей в наименовании пакета.
И после этой правки повторим апгрейд еще раз. В зависимости
от исходного набора установленных пакетов могут потребоваться
ручные установки других пакетов, например,
yast2-installation-2.9.57-1.noarch.rpm. Но так или иначе,
после очередной правки команда полного апгрейда должна
выполнится.
# apt-get dist-upgrade
При повторе apt не загружает пакеты в кеш, а после
перепроверки зависимостей и получения подтверждения сразу же
начинает установку. Но так как некоторые пакеты уже
установлены, то калькуляция объемов может быть иной :
[...]
435 upgraded, 33 newly installed, 13 replaced, 20 removed and 10 not upgraded.
Need to get 0B/423MB of archives.
After unpacking 80.8MB of additional disk space will be used.
Do you want to continue? [Y/n] Y
Checking GPG signatures...
Committing changes...
Preparing...
3. Основные исправления.
В результате предыдущего шага был произведен апгрейд системы.
Но не факт, что apt, пользуясь только информацией из rpm,
смог обновить систему правильно. Опытным путем была
установлена необходимость как минимум двух дополнительных
правок до получения системы, которая готова к перезагрузке.
Потеряный mingetty.
"Слабое место" rpm репозитория SuSE в наличии блуждающей
программы mingetty. Без этой программы в стандартной
настройке inittab нет возможности залогиниться с
локальных консолей. В 9.0 mingetty располагался в
sysvinit, а в 9.1 был перемещен в одноименный пакет.
Забыли только связи соответственно поправить. К слову
сказать, проблемы с mingetty сопровождают SuSE очень
давно. Поэтому безропотно добляем этот пакет вручную.
# apt-get install mingetty
Неправильно собранный initrd.
Вторая проблема, которая может помешать загрузке
обновленной системы, это ошибка при сборке initrd.
Несмотря на повышенную "интеллектуальность" установочных
скриптов, включенных в rpm ядер, ошибки в них происходят
постоянно. В общем случае апдейт ядра в настроенной
системе SuSE происходит автоматически. Точно также
автоматически и распознается установленный загрузчик. И
даже если в системе использован lilo, то он будет
запущен после обновления ядра. Но так как установка
нового ядра очень ответственная часть, то следует
подстраховаться и вручную произвести все необходимые
действия или хотя бы перепроверить их результаты.
Контролем может служить то, как изменится объем initrd
после ручной установки. Увеличение длины файла
свидетельствует об ошибке автоматического обновления.
Кстати, в данном случае внимательное наблюдение за
процессом апгрейда позволяет обнаружить среди сообщений
следующий фрагмент :
[...]
grep: /etc/modules.conf: No such file or directory
Root device: /dev/hda2 (mounted on / as reiserfs)
Module list: reiserfs
Kernel version: 2.6.4-52-default (i386)
Kernel image: /boot/vmlinuz-2.6.4-52-default
Initrd image: /boot/initrd-2.6.4-52-default
Shared libs: lib/ld-2.3.3.so lib/libc.so.6
Cannot determine dependencies of module reiserfs. Is modules.dep up to date?
Modules:
none
[...]
Толковать это можно так, что к моменту создания initrd
не произведено обновление зависимостей модулей и из-за
чего собственно модуль, необходимый для корневой
файловой системы, в initrd не включен.
Чтобы исправить initrd для начала следует убедиться, что
правильно произведено построение зависимостей модулей
ядра.
# ls -als /lib/modules/*/modules.dep
232 -rw-r--r-- 1 root root 237456 Jun 1 16:04 /lib/modules/2.6.4-52-default/modules.dep
Файл должен иметь ненулевую длину, иначе построитель
initrd не сможет найти нужные модули. Если он 0-ой длины
или вообще отсутствует, то его следует построить
специально.
# depmod 2.6.4-52-default -a
Далее создадим initrd, указав в качестве загружаемых
модулей те, что нужны для монтирования корневой файловой
системы. Внимание:при работе со стандартно собранным
ядром SuSE использование initrd обязательно. Обычно
скрипт mkinitrd использует системную переменную, где
указаны нужные модули. Эта переменная устанавливается
YaST-ом автоматически. Можно проверить ее значение, в
котором должно присутствовать имя модуля для работы с
корневой файловой системой.
Строка "pcilib: Cannot open /sys/bus/pci/devices" не
является важной для поставленной задачи ошибкой. Она
сообщает о том, что выполнение программы происходит в
среде новой glibc, собранной с поддержкой sysfs, а
поскольку пока еще вся система работает под управлением
старого ядра, то никакой sysfs нет.
Здесь интересно упомянуть о возможности точно также
через apt установить SuSE 9.1, но сохранить старое ядро
от SuSE 9.0. Для этого надо указать пакет k_deflt, как
придержанный в операторе Hold в apt.conf. При этом все
установится как надо, но появится упомянутая выше
строчка "pcilib: Cannot open /sys/bus/pci/devices" при
работе очень многих программ. Т.е. секрет обратной
адаптации SuSE 9.1 к семейству ядер 2.4 заключается еще
и в пересборке glibc для работы без sysfs.
В реальном апгрейде, как правило, оказывается
достаточным просто вновь пересобрать initrd даже без
указания дополнительных параметров.
# mkinitrd
Поскольку в дефолтной установке SuSE использован как
загрузчик Grub, то не требуется производить
дополнительную перенастройку загрузчика. При работе с
lilo, его следовало бы обновить lilo -v.
Теоретически после этого система может быть перезагружена.
Т.е. все минимально необходимые действия по обновлению
произведены. Но как показывает практика, этого недостаточно.
Для тех же, кто не поверит и пожелает перебутиться
немедленно, напомню, что при запуске SuSE 9.1 под VMware
нужно взвести в Virtual Machine Control Panel на закладке
Options в меню Advanced флаг Disable acceleration.
Перезагрузка в этой точке обновления не помешает продолжить
процесс, как описано далее.
Дополнительные замечания и исправления.
1. Настройка сети.
В новом SuSE Linux изменились стартовые скрипты и настройки
сети. Возможные ошибки могут возникать все из-за того же
запоздалого разрешения зависимостей модулей ядра, что
приводит к ошибкам переноса автоматической загрузки модулей
сетевых карт из старой системы в новую. Ситуацию может
изменить принудительное прописывание загрузки в sysinit,
например для VMware так :
Или сеть следует настроить заново через YaST. Как правило,
достаточно указать нужный модуль в загрузке, после чего сеть
должна стартовать без проблем. И можно считать что для SuSE
Linux, используемого в качестве сетевого рутера, все
необходимые действия по обновлению произведены.
2. Настройка Х.
В обновленной системе X не сможет стартовать из-за отсутствия
libusb-x.x.so. Исправить это можно установкой
соответствующего пакета.
# apt-get install libusb
После этой установки можно запустить X. Но в запущенном KDE
будут отсутствовать многие экранные элементы, например
настроенный Taskbar, некоторые стилевые элементы KDE и вообще
все меню. Исследование этого вопроса приводит к необходимости
следующей поправки. Но после установки libusb можно сказать,
что SuSE Linux, используемый в качестве десктопа, в первом
приближении полностью обновился до версии 9.1.
3. Настройка десктопа KDE.
Если считать, что ключевым пакетом с настройками и
предустановленными элементами KDE является kdebase3-SuSE, то
попытка его установить "в лоб" приводит к сообщениям о
неразрешимых для apt зависимостях. В конце концов,
путешествие по цепочке связанных пакетов приводит к
openldap2-client, из-за которого, как кажется, все и не
ставится. Но проблема в том, что установка пакета
openldap2-client требует удаления пакета shadow, прописанного
существенно важным в настройках apt и многих других, например
openssh. Не шутка, да ? Попутно выясняется, что в новой
версии пакета shadow нет вовсе, а его программы сосредоточены
в пакете pwdutils. Все это успокаивает и придает решимости
ответить утвердительно на требование apt не просто
подтвердить согласие односложно - "Y/n" , а детально
скопировать целое предложение в знак согласия продолжить
удаление и соответствующую установку, а именно "Yes, do as I
say!".
# apt-get install openldap2-client
Теперь возможно удастся поставить нужный пакет kdebase3-SuSE
сразу же, а может так случиться, что возникнуть новые
проблемы. Путь их разрешения весьма прост. Например, если
попытка установки kdebase3-SuSE завершилась ссылкой на
отсутствие libhd.so.8, как показано ниже :
# apt-get install kdebase3-SuSE
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
Since you only requested a single operation it is extremely likely that
the package is simply not installable and a bug report against
that package should be filed.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
kdebase3-SuSE: Depends: libhd.so.8
E: Broken packages
Другими словами, ищем то, чего не хватает, и потом ставим
это, если нашлось. Попутно заметим, что установка именно
hwinfo приводит к удалению всего многочисленного семейства
пакетов YaST. Но на работоспособности уже настроенной системы
это никак не сказывается.
Так или иначе, должны быть установлены элементы KDE и весьма
важный пакет ssh со всеми утилитами должен быть восстановлен
также.
Теперь все работает почти на 100%. Но SuSE Linux не SuSE если
в нем нет фирменного YaST. Кстати сказать, если бы не
пришлось устанавливать hwinfo, то в системе остался бы старый
YaST, так как в репозитории нет соответствующих ссылок для
непременного обновления этого пакета.
4. Очевидное : обновление YaST.
Казалось бы, какие могут возникнуть проблемы с установкой
пакета такой важности, поскольку и проработанность его тоже
ожидаемо должна быть безупречной. Но это лишь на первый
взгляд. Увы, случайно или нарочно, но разработчики SuSE
именно в той версии, что идет на дистрибутивных диска 9.1, и
даже в появившихся фиксах YaST, установили зависимость
пакетов семейства YaST от libpopt.so.0. Своего рода "дежа вю"
или "Призрак отца Гамлета", поскольку даже в 9.0 в пакетах
YaST уже в зависимостях присутствует libpopt.so.1, т.е именно
та библиотека, что и поставляется в реальном пакете popt, как
в том, что идет с 9.0, так и в том, что размещен на
дистрибутивных дисках SuSE 9.1. Интересно, что исправление
этого бага произошло не в пакетах YaST, а путем добавления
нужной библиотеки в пакет popt, который уже выложен в
апдейтах на FTP. Вероятно, разработчики исходили из
соображений экономии объема обновления. Правда остается
загадкой, как в системе, установленной с диска, на котором
непофиксенная версия popt и соответственно отсутствует
libpopt.so.0, все-таки YaST запускается и в ncurses режиме
тоже. Но, так или иначе, все вышесказанное лишний раз
доказывает, что зависимости в SuSE пишутся "от балды", а
чудодейственный YaST ставит, что надо, даже не глядя на
требования rpm и попутно исправляя все ошибки сборщиков
пакетов. Поэтому у нас остаются два пути, чтобы поставить
нужный YaST. Или поступить так, как делает сам YaST, или
сделать все правильно. В первом случае надо будет выполнить
что-то вроде :
Наверное, все поставится. И, наверное, даже будет работать.
Скорее всего точно будет ! Ибо SuSE AG не продает того, что
не работает. Но тогда придется распрощаться с apt. Поэтому
воспользуемся тем способом, который принят в дистрибуциях,
где пакетные зависимости используются по назначению, а не для
объема, и где apt применяется, как установочный инструмент.
Создадим псевдопакет, обеспечивающий недостающие зависимости.
Для этого можно его построить по тривиальному спеку
(http://www.barabanov.ru/arts/yast2-trick.spec), выполнив следующее:
Полученный тем или иным способом пакет после установки
автоматически создаст нужные линки и предоставит требуемые
зависимости для дальнейшей работы apt. Для контроля
сопроводим его установку проверками целостности связей в apt
кеше.
# apt-cache unmet
Package yast2-core-devel version 2.9.79-3 has an unmet dep:
Depends: yast2-core (= 2.9.79)
Package yast2-core version 2.9.90-0.2 has an unmet dep:
Depends: libpopt.so.0
Package yast2-packagemanager-devel version 2.9.37-0 has an unmet dep:
Depends: yast2-packagemanager (= 2.9.37)
Package yast2-packagemanager version 2.9.42-0.2 has an unmet dep:
Depends: libpopt.so.0
# rpm -ivh yast2-trick-1.0-ab1.noarch.rpm
# apt-cache unmet
Package yast2-core-devel version 2.9.79-3 has an unmet dep:
Depends: yast2-core (= 2.9.79)
Package yast2-packagemanager-devel version 2.9.37-0 has an unmet dep:
Depends: yast2-packagemanager (= 2.9.37)
Оставшиеся "подвисшие" требования не помешают установке yast.
Что и будет сделано в один прием :
# apt-get install yast2-packager
Теперь YaST вопреки всему установлен и должен запускаться в
консольном варианте. Это значит, что все недостающее уже
можно через упомянутый YaST и установить. Или продолжит
делать это далее опять же через apt, попутно преодолевая
несуразные зависимости пакетов SuSE Linux.
5. Невероятное : обновление modutils.
Завершающий сюрприз от SuSE. Поскольку в 9.1 используется
ядро 2.6, то для манипуляций динамическими модулями ядра
применяется специальный module-init-tools. Этот пакет призван
заменить modutils, который работал с ядрами 2.4. Вполне
ожидаемо то, что на этот пакет не указывают никакие
зависимости от новых ядер 9.1, думаю что к бардаку внутри
rpm-репозитория SuSE можно привыкнуть и считать его элементом
свободы, но настоящим сюрпризом оказывается, что старый
modutils от дистрибутива 9.0 прекрасно работает как с ядрами
2.4 так и с новой веткой 2.6. Так как все описанные
построения initrd идут именно с modutils. Это особенно
удивительно на фоне того, как старательно сопровождается
каждая обновленная сборка ядра для 9.1 соответствующим
module-init-tools с указанием в прилагаемом info на основание
для такого обновления как "Support new fractional kernel
release number". Вероятно, надо понимать так, что в
новаторские module-init-tools внесены такие изменения против
универсальных modutils, которые не позволяют использовать их
с другии ядрами, чем идущие с дистрибутивом. Т.е. те, кто
желает модернизировать ядра SuSE 9.1 по своему усмотрению,
должны будут оставить старые modutils или "починить" новые.
Но так как нашей целью является апгрейд, то обновим все, что
надо, даже вопреки логике самосохранения :
# apt-get install module-init-tools
Этой установкой поставим точку в процессе обновления.
Конечно, детальное сравнение перечня установленных пакетов
"rpm -qa | sort" в обновленной системе и в установленной
через YaST укажет на определенные расхождения. Но это
следствие неполноты пакетных зависимостей в SuSE оставим как
домашнее задание педантам.
# apt-get clean
# reboot
Замечание, которое следует учесть тем, кто возмется за обновление SuSE
9.0 до 9.1, вне зависимости от того, что будет взято за
инструментарий, apt или YaST. В новую glibc разработчиками SuSE Linux
внесены модернизации в расчете на использование мультикастного DNS в
рамках технологий zeroconfig. В качестве штатного мультикастного
респондера предполагается использовать OpenSLP. Поэтому тех, у кого
используется в качестве корневого локального домена ".local", ждет
сюрприз - новая система не сможет резолвить локальные ресурсы, или,
вернее, будет искать их не там.
Рекомендации SuSE : перед тем как апгрейдить следует измененить
конфликтные локальные домены на новые.
1316 Прочтений • [Обновление SuSE Linux 9.0 до 9.1 с помощью apt. (suse linux upgrade apt)] [08.05.2012] [Комментариев: 0]
Vova
