Наши партнеры

UnixForum






Книги по Linux (с отзывами читателей)

Библиотека сайта rus-linux.net

Заметки пользователя Linux. В новый год - с обновленной системой

(C) В.А.Костромин, kos @ rus-linux dot net

30 декабря 2003 г., последние изменения внесены 2 января 2004 г.

Предыдущая заметка

В последние дни уходящего года задумал я обновить Линукс на компьютере, установленном на моем рабочем месте. Если судить по содержимому файла /etc/redhat-release, то до сих пор он у меня работал под управлением Red Hat Linux версии 7.1, а команда uname -a сообщала, что версия ядра имела номер 2.4.2-2. Кроме того, на нем была установлена система виртуальных машин VMware версии 2, с помощью которой я запускал в виртуальном компьютере ОС Windows NT 4.0. Этот виртуальный компьютер был подключен к локальной вычислительной сети учреждения и я выполнял в нем свои производственные функции. Функции эти сводятся в основном к редактированию различных служебных документов с помощью текстового процессора MS Word, обмену этими документами с коллегами по работе посредством MS Outlook и печати документов, которую я выполнял с помощью сетевого принтера. Я долго не решался трогать хорошо работающую систему. Дело в том, что все мои производственные задачи с ее помощью успешно решаются, а из своего прошлого опыта я знаю, что всякое обновление выбивает из обычного рабочего ритма как минимум на неделю. Вот и в этой системе у меня был печальный опыт, когда после очередного пропадания питания (которые случаются несмотря на все меры предосторожности и наличие двухуровневой защиты источниками бесперебойного питания) ОС Windows NT в виртуальном компьютере выдала "синий экран смерти" и перестала загружаться (кстати Линукс тот удар выдержал). К счастью я не стал форматировать виртуальный диск, а создал новый, установил на него заново Windows NT, а старый виртуальный диск подключил потом как второй. Информация на нем сохранилась, только система с него грузиться отказалась. С тех пор у моего виртуального компьютера два виртуальных диска. И хотя ущерб от этого случая в части потери информации был минимальным, но потери времени были значительными, ибо возился я с этим долго!

Ну а уж переустанавливать заново две системы у меня и вовсе желания не возникало! Но время идет, появилось уже ядро 2.6.0, да и я поднабрался кой какого опыта как в обновлении Линукса (я рассказывал об этом в своих заметках [2-3]), так и в части установки новой версии VMware Workstation 4, причем с сохранением информации со старого виртуального компьютера [4]. К тому же меня как-то уже не устраивала работа с KDE версии 2.1.2, когда уже выпущена версия 3.2. Поэтому, сдав годовой отчет и имея в запасе два относительно свободных дня до наступления нового года, я решился посвятить их обновлению системы на своем рабочем месте.

Перейти я задумал на ASP Linux 9.0, причем путем использования стандартной процедуры обновления, предлагаемой программой инсталляции дистрибутива. Хотя в своих предыдущих заметках я и утверждал, что наилучший способ обновления состоит в том, чтобы полностью переустановить систему, однако полной уверенности в истинности этого утверждения у меня как-то не было. Слишком малое число раз я проделывал такую процедуру, чтобы со 100% уверенностью говорить о ее непригодности в практической ситуации. К тому же полная переустановка заведомо более трудоемка, но всегда существует как последний путь для отступления. Так что я решился еще раз провести процедуру обновления и обо всех обнаруженных подводных камнях рассказать в этой своей заметке.

Прежде чем перейти собственно к рассказу, приведу картину разбиения моего жесткого диска:

[root@kos3 /]# /sbin/sfdisk -l -x /dev/hda 
Disk /dev/hda: 2498 cylinders, 255 heads, 63 sectors/track
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start     End   #cyls   #blocks   Id  System
/dev/hda1   *      0+    382     383-  3076416    b  Win95 FAT32
/dev/hda2        383     498     116    931770    b  Win95 FAT32
/dev/hda3        499     626     128   1028160    83  Linux
/dev/hda4        627    2497    1871  15028807+   f  Win95 Ext'd (LBA)
 
/dev/hda5        627+    659      33-   265041   82  Linux swap
    -            660    1170     511   4104607+   5  Extended
    -            627     626       0         0    0   Empty
    -            627     626       0         0    0   Empty
 
/dev/hda6        660+   1170     511-  4104576   83  Linux
    -           1171    2497    1327  10659127+   5  Extended
                start: (c,h,s) expected (1023,254,63) found (1023,0,1)
    -            660     659       0         0    0    Empty
    -            660     659       0         0    0    Empty
 
/dev/hda7       1171+   2497    1327- 10659096   83  Linux
                start: (c,h,s) expected (1023,254,63) found (1023,1,1)
    -           1171    1170       0         0    0    Empty
    -           1171    1170       0         0    0    Empty
    -           1171    1170       0         0    0    Empty
Как видите, два первых раздела у меня заняты предустановленной системой (это была ОС Windows 2000), а четыре следующих - отданы Линукс. О том, каким образом смонтированы разделы, сообщает команда df:
[root@kos3 /]# df
Filesystem           1k-blocks      Used   Available Use% Mounted on
/dev/hda3              1012056    371832    599100  39% /
/dev/hda1              3070400   1257136   1813264  41% /mnt/win
/dev/hda2               928126    770954    157172  84% /mnt/win2
/dev/hda7             10490424   8691484   1372580  87% /home
/dev/hda6              4040256   1520540   2355536  40% /usr 

Что еще стоит отметить перед изложением результатов, так разве что то, что в качестве загрузчика у меня использовался LILO версии 21.4-4.

Итак, я выключил виртуальный компьютер, вставил в дисковод первый диск дистрибутива ASP Linux 9 и нажал кнопку перезагрузки. Инсталляция пошла вроде бы нормальным образом: выбрал раскладку клавиатуры, определилась мышка, указал точки монтирования разделов, нажал кнопку "Далее". И тут ...

... появилось сообщение "Ошибка восстановления точек монтирования или определения базы данных RPM". И как я ни пытался правильно задать точки монтирования, ничего у меня из этого не получилось. Несколько раз доходил до этого места и то же самое сообщение об ошибке появлялось заново. Вообще-то, как видно из приведенного выше листинга команды sfdisk, с разбиением у меня не все в порядке. Но в чем причина и как это поправить, я что-то не представляю. И все же идти на первый вариант обновления (см.[2]) я пока не решился. Надумал я предварительно попробовать другой дистрибутив. Действительно, ведь у меня стоял Red Hat, почему бы не попытать его, тем более что у меня есть версии 7.3, 8 и 9. Но начать, конечно, надо с версии 7.3, как более близкой к существующей конфигурации. Надумано - сделано!

Ставлю первый диск дистрибутива и перезагружаюсь еще раз. Запускается программа инсталляции. Выбираю 105-клавишную клавиатуру, заменяю предлагаемую трех-кнопочную мышь на 2-кнопочную, и, естественно, выбираю вариант "Обновить существующую систему". Далее программа спрашивает - уточнить пакеты для обновления. Ставлю галочку "Уточнить". И тут снова появляется сообщение об ошибке, только на этот раз другая: "Ошибка монтирования устройства sda1 как usb. No such device or adress. Нажмите OK для перезагрузки системы". После перезагрузки уперлись в тот же столб!

Тогда я удалил загрузочный CD-ROM, загрузил старую систему и удалил из файла /etc/fstab запись о монтировании usb. После этого программа инсталляции успешно миновала точку преткновения и пошла дальше. Обнаружив 254 МБ ОЗУ и swap-раздел объемом 258 МБ, она сообщила, что этого маловато и предложила создать swap-файл в корневой файловой системе объемом 254 МБ. Я согласился.

Следующим ее предложением было преобразовать файловые системы на всех разделах из ext2 в ext3. Я принял это предложение для корневого раздела и раздела /usr, а раздел /home оставил без изменения. Потом мне было предложено выбрать загрузчик, вернее было предложено на выбор три варианта: "Обновить, но оставить загрузчик LILO (рекомендуется)", "Заменить загрузчик" и какой-то еще третий вариант. Хоть я и предпочитаю в последнее время GRUB, но тут я решил выбрать рекомендуемый вариант (об установке GRUB вместо LILO я еще собираюсь рассказать отдельно).

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

Группа пакетов Добавил пакеты в список пакетов для обновления Удалил пакеты из предлагаемого списка
-kernel-doc, kdeaddons-konquerorman-pages.fr, sawfish
Архиваторыunarjcdrecord, rmt (работа с ленточными накопителями)
Интернет-elinks, kit, netscape
Мультимедиаxmms-skinscdparanoia, cdda2wav
Обработка текстаrecode-
Редакторыnedit, quantaemacs, khexedit (я этим не пользуюсь)
Системаethtool, sudo, usbview-
Игры-fortune-mod

Я, конечно, согласился с тем, чтобы были установлены пакеты, необходимые для разрешения зависимостей. Далее пошел перенос пакетов на жесткий диск, подготовка к установке и собственно установка, которая заняла примерно 16 минут. Что характерно, не было настройки графического режима, система не просила ввести пароль суперпользователя и завести еще каких-либо пользователей, не выполнялась настройка сети и прочие настройки. А вот загрузочный диск было предложено изготовить заново. Это, впрочем, естественно, - ядро-то меняется. Через 16 минут лоток CD-ROM выдвинулся и система пошла на перезагрузку. Забыл я было убрать загрузочную дискету из дисковода, поэтому вначале ход загрузки вызвал у меня удивление, пока я не опомнился и не нажал известную комбинацию из трех пальцев (дискету при этом, конечно, убрал).

После этого ход загрузки системы стал привычным. Правда следил я за этим процессом внимательнее, чем обычно, а поэтому успел заметить, что промелькнули два сообщения об ошибках. В первом случае сообщалось, что "SMB connection FAILED", а во втором - о том, что "Connection to VMware failed". Второе сообщение ожидалось, поскольку известно, что при смене ядра система VMware отказывается работать без дополнительной переконфигурации.

По команде startx (которая, между прочим, сохранилась в истории команд, как и вся остальная история), запустилась графическая оболочка KDE 3.0.0-10 и появилось окно мастера ее настройки. Как потом оказалось, это окно скрыло окно с сообщением о сбое в загрузке драйвера звуковой платы: "Error while initializing sound driver. Device /dev/dsp not found". Сообщение это я потом отключил. А пока я прошел все этапы настройки KDE, хотя ничего и не менял, просто соглашался с предложениями мастера.

Когда мастер закончил свою работу пришлось заново настроить эмулятор терминала и программу Midnight Commander. Почтовый клиент Kmail обновился до версии 1.4.1, но обнаружил все старые письма в ранее созданных папках. Запустив Konqueror я убедился, что видны наши Интранетовсие сервера, то есть локальная сеть тоже работает. А вот с переключением раскладок клавиатуры возникли некоторые проблемы - не мог нащупать, какими клавишами осуществляется переключение раскладки. Работало только переключение с помощью щелчка по иконке на панели KDE. Я отключил этот переключатель с помощью Центра управления KDE, одновременно задав там горячие клавиши для переключения (Alt-Shift), после чего смог переключать раскладку с клавиатуры. Между прочим, в файле /etc/X11/XF86Config опция, задающая клавиши переключения групп тоже не указана. И вообще, файл /etc/X11/XF86Config мне показался созданным заново - был он очень коротким и незнакомым.

Заглянув в каталог /boot, я обнаружил там только ядро 2.4.18-3. Старое ядро 2.4.2 было удалено. А в каталоге /root в процессо обновления был создан файл upgrade.log. Он слишком велик, чтобы привести его здесь полностью, поэтому я приведу его в сокращенном виде (удаленные куски отмечены многоточиями):
Обновление 499 пакетов

Следующие пакеты были автоматически выбраны для установки:

Upgrade Dependency: initscripts needs iproute, automatically added.
Upgrade Dependency: 4Suite needs Distutils, automatically added.
.........................................
Upgrade Dependency: sawfish needs rep-gtk-gnome, automatically added.
Upgrade Dependency: gnome-vfs needs gnome-mime-data, automatically added.


Обновление glibc-common-2.2.5-34.
Обновление hwdata-0.14-1.
.........................................
Обновление setup-2.5.12-1.
/etc/group created as /etc/group.rpmnew
/etc/passwd created as /etc/passwd.rpmnew
/etc/shells created as /etc/shells.rpmnew
Обновление filesystem-2.1.6-2.
group lock does not exist - using root
Обновление glibc-2.2.5-34.
.........................................
Обновление xmms-skins-1.2.7-1.


Следующие пакеты были доступны для этой версии, но НЕ были обновлены:
sash-3.4-11.i386.rpm
FreeWnn-libs-1.11-20.i386.rpm
ghostscript-fonts-5.50-3.noarch.rpm
............... (917 пакетов).............
busybox-0.60.2-4.i386.rpm
Как видите, тут три группы сообщений: о том, какие пакеты потребовались для разрешения зависимостей, какие пакеты были обновлены и какие пакеты можно было установить, но они НЕ БЫЛИ установлены (это самая большая группа).

Я еще выполнил команду rpm -qa | wc -l, которая сообщила, что теперь в системе установлено 544 пакета. Цифры немного не сходятся, но почему это произошло, я не могу объяснить.

Поскольку у меня был русифицированный Red Hat, я попытался еще воспользоваться 4-ым диском дистрибутива, содержащим пакеты обновления и русификации. Установил диск в дисковод, запустил autorun с помощью Midnight Commander (автоматический запуск почему-то не сработал). Первым делом попытался провести обновление пакетов. Однако, соответствующая экранная клавиша почему-то не сработала (никакой реакции на ее нажатие вообще). Тогда провел установку пакетов русификации. Результат вы видите на рис.1.

Рис.1

Рис. 1. Установка пакетов русификации.

Затем я провел инсталляцию пакета OpenOffice.org1.0, как показано на рис.2:

Рис.2

Рис. 2. Установка OpenOffice.org1.0.

После этого я вызвал браузер Mozilla. Открылось окно браузера, причем в пункте "Помощь" главного меню браузера сообщается, что версия программы равна 1.0. А команда
rpm -qa | grep mozilla
сообщила, что в моей системе установлены пакеты
mozilla-0.9.9-7
mozilla-psm-0.9.9-7
mozilla-mail-0.9.9-7
mozilla-nss-0.9.9-7
mozilla-nspr-0.9.9-7
причем прямой вызов программы /usr/bin/mozilla приводит к вызову именно версии 0.9.9. Зато в каталоге /home/kos/mozilla имеется исполняемый файл mozilla, который вызывает версию 1.0. Значит я ставил ее из исходников и она более поздняя, чем установленная из пакетов. Поэтому я со спокойной совестью удалил перечисленные ваше пакеты версии 0.9.9 командой rpm -e.

Аналогичная история у меня оказалась с пакетом OpenOffice.org. Команда
rpm -qa | grep openoffice
показала только пакеты
openoffice-psm-0.4-1
openoffice-rus-1-1
Но разборки с OpenOffice я решил отложить на потом, а пока в первую очередь разобраться с пакетом VMware, который, как было сказано в начале статьи, играет наиважнейшую роль на моем служебном компьютере.

Между прочим, попытка еще раз запустить "Обновление пакетов" с 4-го диска снова окончилась неудачей, так что я убрал этот диск в его упаковочку.

Команда rpm -qa | grep VMware обнаружила пакет VMware-2.0.4-1235. Конечно, неплохо бы перед переустановкой VMware сделать backup старых виртуальных машин. Но объем каталога /home/kos/vmware равен 5,97 ГБ, так что backup сделать некуда. Придется идти напролом.

Удаляю старую версию командой rpm -e VMware-2.0.4-1235, ставлю новый пакет командой
rpm -Uhv VMware-workstation-4.0.5-6030.i386.rpm
и запускаю скрипт /usr/bin/vmware-config.pl. Подробно излагать процесс конфигурирования системы VMware я не буду, поскольку только что описывал его в заметке [4]. После завершения работы скрипта запускаю VMware (как запускал и раньше, через пункт "Выполнить команду" главного меню KDE). Программа успешно запускается. Выбираю пункт "Open existing virtual machine", нахожу старый файл конфигурации. Виртуальный компьютер запускается (правда с низким разрешением) и сообщает, что формат виртуальных дисков у меня старый, предлагает преобразовать. Однако преобразование не проходит, появляется сообщение о том, что места в каталоге /tmp недостаточно.

Рис.3

Рис. 3. Сообщение о недостатке места в /tmp.

Каталог это у меня находится в корневой файловой системе, просмотрев содержание которой, я обнаружил в каталоге /opt исходные коды ядра версии 2.4.2. Они, как вы знаете, довольно громоздки, и мне уже не нужны, потому что ядро это снесено. Удаляю подкаталог /opt/kernel-2.4.2, а остальное содержимое каталога /opt (в нем еще были исходные коды пары крупных пакетов) переношу в раздел /usr, после чего в корневой файловой системы освободилось 1,3 ГБ. После этого преобразование виртуальных дисков некоторое время продолжалось. Но результат был несколько обескураживающим - в виртуальном компьютере высветился "синий экран смерти".

Такой результат меня сильно огорчил - я уж было засомневался, сумею ли восстановить информацию со своих виртуальных дисков. Но что остается делать? Пытаюсь перезагрузить виртуальный компьютер. Перезагрузка, к моему удивлению и радости, прошла нормально и я снова увидел стартовый экран Windows NT4, правда все еще с тем же низким разрешением (что-то вроде 640х480). Но это вполне нормально - чтоб получить что-нибудь приемлемое, надо ставить VMware Tools. Завершаю загрузку Windows и выбираю пункт "VMware Tools install" в меню "File" окна VMware. После завершения процесса инсталляции VMware Tools открываю окно свойств экрана в "Панели управления", меняю тип дисплея на вкладке "Параметры" на "VMware SVGA II". После этого задаю разрешение экрана 800х600 (больше я не использую, потому что иначе придется работать с VMware на полном экране, а я предпочитаю окно).

На этом описание процедуры обновления системы заканчиваю. В заключение попробую подвести некоторые итоги.

Во-первых, как показал этот опыт, обновление системы с помощью штатной программы инсталляции - вполне приемлемый вариант.

Однако, по-видимому, идти на этот вариант стоит только в том случае, если вы используете при обновлении новую версию того же дистрибутива, который был у вас установлен ранее. В противном случае обновление может не пройти. (Остается, конечно, подозрение, что моя неудача в переходе с Red Hat 7.1 на ASPLinux обусловлена не разностью дистрибутивов, а недостатками программы инсталляции конкретно дистрибутива ASP Linux, и я не берусь однозначно утверждать, какая из этих двух причин имеет место в действительности.)

Во-вторых, так или иначе, "мусор" на диске от предыдущего варианта системы все равно остается. В моем случае это были исходные коды ненужного уже ядра 2.4.2 и еще кой-какие каталоги и файлы, которые я обнаружил при анализе того, что получилось в результате обновления. Так что после завершения обновления системы имеет смысл провести такой анализ. И это подталкивает к мысли, что обновление методом полной переустановки системы имеет свои преимущества.

Но зато, как я уже говорил, мне не пришлось заводить пользователей, настраивать графику и сеть.

В общем, еще раз повторю заключение предыдущей статьи: выбирать метод обновления вам придется самим, я надеюсь только, что мой опыт поможет вам сделать такой выбор более осознанно. А я, вероятно, еще вернусь к теме обновления системы в своих заметках - Линукс стремительно развивается и через некоторое время желание перейти на более новую версию дистрибутива у меня обязательно появится.

Список литературы и ссылки.

  1. В.А.Костромин, "Linux для пользователя", изд. БХВ-Петербург, 2002 год, серия "Самоучитель", 650 стр.
  2. "Четыре варианта обновления Линукс-системы." (11 декабря 2003 г.)
  3. "Второй этюд о компиляции ядра из исходных кодов." (11-14 декабря 2003 г.)
  4. "Установка VMware Workstation 4.0.5 " (14-18 декабря 2003 г.)