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).

    1 Star2 Stars3 Stars4 Stars5 Stars (1 votes, average: 5,00 out of 5)
    Loading...

    Метки: , , ,

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


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

    1. Oleg:

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

    2. Alex:

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

    3. Кирилл:

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

    4. Владимир:

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

    5. Vasile:

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

      Option "XaaNoImageWriteRect" "True"

    6. Vasile:

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

    Leave a comment

    *