VIA K8M800 на Fedora 9

2008-08-21 09:30 | Автор: Vasile Chelban | Filed under: Vasile

Через пару месяцев после выхода Fedora 9, решил перевести еще одну домашнюю машину на новую версию. Исходный продукт - Fedora 8 i386 на AMD Sempron 2800+, мат. плата MSI K8MM3-V (чипсет VIA K8M800), 1Гб оперативной памяти, SATA жесткий диск Maxtor, DVD-ROM TEAC и звуковая карта YMF 724F-V. Система довольно дешевая и простая. Особых проблем не ожидал. Процедура апгрейда, опять-же, традиционна - YumUpgradeFaq. Благо относительно быстрое ADSL соединение в наличии, и скорость до молдавского репозитория хорошая. 🙂

Быстро разобравшись с обновлением fedora*-release пакетов, установкой репозиториев для апгрейда, удалением пару несовместимых пакетов (согласно FAQ), запустил процесс и пошел пить "чай".

Однако победный онец в тот день я не увидел. Куча сообщений о нехватке места заполнили весь экран. Причем сообщения появились не в момент закачки пакетов, но уже в процессе их установки. Вина тут моя - надо было сообразить что на 5Гб root-файловой системе (которая одновременно и /var и /tmp и /usr) и свободных 1.5Гб точно подобное возникнет.

Тут решаю вопрос просто - так как есть /home раздел с достаточным местом для размещением кеша yum'a - туда его и переносим. Как? Примерно вот так:

# yum clean all

# mkdir /home/yc

# mount --bind /home/yc /var/cache/yum

Снова запускаю yum upgrade и опять иду дышать свежим никотином. И опять незадача - система зависла после большей части процесса установки пакетов. Попалось что-то тяжелое вроде glibc или selinux-policy. Резет, в грубе выбираю новое ядро и ... система зависает после двух-трех оборотов курсора мыши на экране rhgb (эта та графическая заставка при загрузке системы). Опять резет, выбираю новое ядро, но уже не жму Enter, но 'e' (Edit), перехожу к строке 'kernel ...', опять жму 'e', перехожу к концу строки и удаляю параметр 'rhgb'. Далее Enter и 'b' для запуска загрузки. Пошел процесс, мелькают сообщения запускается gdm, и опять стоп-кран. Соображаю что rhgb не причем. Что-то с X-ами, точнее с видеодрайвером - обыкновенно именно этот компонент имеет возможность так влиять на оборужование. Поэтому решаю загрузить систему в runlevel 3 (текстовый режим, а по умолчанию графический именуется runlevel 5) и диагносцировать систему по лог-файлам, запуском startx из консоли и.т.д. Делается это также легко как и отключение rhgb - просто кроме удаления параметра rhgb также добавляем параметр '3' (записываем без кавычек). Теперь дошел до логина (текстового), но не далее. Все попытки логина отвергались. И так как login процесс завершался аварийно, и mgetty при этом перезапускался - сообщения о ошибке увидеть не удалось. Вот еще один эффект незавершенного обновления системных компонентов. Что делать? Перставлять? Нет - это не наш метод. Переходим на уровень ниже - runlevel 1. Однако и там без успеха. Всё, приехали? Нет - есть еще 2 варианта: загрузка с rescue/Live диска или загрузка в ультраминимальном режиме - ядро+bash. Так как первый способ требует телодвижений с оптическими носителями.накопителями выбираю второй. Кстати он годится и для смены забытого root пароля и довольно независим от дистрибутива. На этот раз добавляемый в GRUB'e/LILO параметр ядра: 'init=/bin/bash'. В Fedora bash всегда в /bin, однако для других систем это не всегда так. Однако всегда на всех UNIX системах есть имполняемый файл или ссылка на него под именем /bin/sh, можно попробовать и его. Тут конечно всё загружается, но система не пригодна пока для наших целей. Напомню: цель - продолжение процеса обновления системы, с помощью комманды yum-complete-transaction. Поэтому подключаем /home и yum cache, настраиваем локальную сеть (надо же дать yum'у доступ к онлайн репозиторию. Если бы репозиторий был локальный - можно и без сети).

# mount /home

# mount --bind /home/yc /var/cache/yum

# /sbin/ifconfig eth0 192.168.1.20

# /sbin/route add -net 0.0.0.0 netmask 0.0.0.0 gw 192.168.1.1

# yum-complete-transaction

Наконец процесс дошел до конца. Перезапускаюсь и обнаруживаю что ни граф. режимы, ни текстовый логин всё еще не работают. Тут бы опустились руки и бросили всё это, но толи тяга к познанию, толи банальное упрямство не позволяют остановиться.

Проблемы решать надо отдельно. Отлаживаю графическую до лучших времен и разбираюсь с логином. Опять загружаюсь с init=/bin/bash, гляжу в логи - замечаю что login завершается из за ограничений SELinux. Запускаю package-cleanup -d (из пакета yum-utils), вижу дву версии selinux-policy - от F8 и от F9. вручную удаляю старый (rpm -q selinux-policy-targeted отображает список версии, rpm -e selinux-policy-targeted-x.xx.-x.fc8 - удаляет старую). И надо делать обновление меток SELinux для всей файловой системы. Создаём в корне файл-флаг и перезагружаемся. relabel будет сделан при следующем запуске:

# touch /.autorelabel

# reboot

Наконец-то, работает логин. Вхожу в систему, запускаю startx. Пара секунд в граф режиме и система виснет. Опять загружаюсь в текстовом режиме, правлю /etc/X11/xorg.conf (vim /etc/X11/xorg.conf), вместо Driver "openchrome" ставлю универсальный Driver "vesa". startx - и всё работает. Хотя конечно не всё - с vesa драйвером фильмы не посмотришь, в игры не поиграешь. Но зато можно воспользоватся веб-браузером и зайти на bugzilla.redhat.com и задать поиск по openchrome драйверу. Оказалось что это известная проблема для openchrome на Xorg-1.5 (что появился в F9). И там же есть советы по решению - в xorg.conf, в рубрику опций драйвера нужно добавить ряд параметров. Получаем следующее:

Section "Device"

Identifier "Videocard0"

Driver "openchrome"

Option "AccelMethod" "EXA"

Option "ExaNoComposite" "True"

Option "MigrationHeuristic" "greedy"

Option "ExaScratchSize" "8192"

Option "MaxDRIMem" "16384"

EndSection

Перезапускаем.... и наконец процесс обновления успешно завершен. Система работоспособна. Осталось только стереть ненужный кэш yum в /home/yc и установить пакеты удаленный перед апгрейдом (согласно FAQ это thunderbird).

Метки: fedora 9, hardware, migrate, selinux

6 комментариев »

комментариев 6

1. Oleg:
   ������� 21, 2008 14:30

   с местом у меня тоже была такая проблема, но решился просто увеличить root, благо LVM, еще пригодится место для сборки пакетов.

2. Alex:
   ������� 17, 2009 1:58

   Спасибо помагло.

3. Кирилл:
   ������� 22, 2009 16:21

   Спосибо автору большое!
   Помог!

4. Владимир:
   ������ 27, 2009 10:40

   громадное спасибо автору за советы о том, как запустить систему в аварийном режиме без оптических носителей =)

5. Vasile:
   ��� 29, 2009 8:54

   Недавно обновлял эту систему до F10, а также другую более старую (с F8 и Via KM400). Баг всё еще на месте. Требуемая опция теперь:
   
Option "XaaNoImageWriteRect" "True"


6. Vasile:
   ����� 31, 2010 13:22

   подтверждаю — текущая версия (уже для F12) этой проблемой не болеет.

Leave a comment

Имя

Mail (will not be published)

Сайт

Δ

CAPTCHA Code *