Календарь
Метки
alsa amd antivirus audio bittorrent bug centos dns fedora fedora 8 fedora 9 fedora 10 FedoraMD fglrx firefox flash player gmail gnome google intel interview java kde kernel linux livecd migrate moldova nvidia openoffice opera pulse-audio python radeon radeonhd red hat rpmfusion selinux skype video virtualisation vmware wine xfce yum
FedoraMD апгрейд сервера - вторая часть
December 22, 2008 14:19 | Author: Vasile | написано в рубрике: FedoraMD, Vasile | 72 views
В последнее время наш сервер претерпел обновление. Как любая система, которая работает достаточно много содержит много сервисов, которые подстроены и налажены для стабильной работы. И конечно после апгрейда на новую версию некоторые сервисы перестали адекватно вести себя. Я расскажу о некоторых возникших проблемах.
Метки: fedora 10, migrate, selinux
FedoraMD server software upgrade
December 10, 2008 11:56 | Author: Vasile | написано в рубрике: FedoraMD | 194 views
Сложилась традиция зимой обновлять версию ПО. И в этот раз мы решили не нарушать традицию и была произведен апгрейд с Fedora 8 на Fedora 10. Fedora 10 (Cambridge) на наш взгляд довольно стабильная система. Процедура апгрейда прошла успешно и не повлияла на все наши сервисы.
Но если все же были найдены какие-либо ошибки, то просим сообщить в комментариях.
Апгрейд производился, используя инструкции YumUpgradeFaq
Метки: fedora 10, FedoraMD, migrate, mysql, yum
Обновление ключей Fedora
September 5, 2008 10:08 | Author: Vasile | написано в рубрике: Новости | 386 views
После недавних событий, все мы задаём себе вопрос - когда же появятся обновления для Fedora 8 и 9?
В веб-интерфейсе bodhi (инструмент управления обновлениями) можно увидеть уже сотни пакетов на разных стадиях готовности. Rawhide также ежедневно наполняется новыми пакетами (но тут объяснение проще - пакеты в Rawhide не подписываются). Компрометация сервера где проходила процедура цифровой подписи репозиториев, сделала необходимым переход на новый набор ключей GPG. В настоящий момент происходит пере подписывание всех пакетов в репозиториях fedora-updates. Уже известны и детали процедуры миграции:
- будет создан новый набор ключей для обновлений и тестовых обновлений.
- в текущий репозиторий будут добавлены новый версии fedora-release (с новыми ключами и .repo файлами ссылающимися на новые местонахождение репозиториев) и PackageKit. Всё ещё подписаны старым ключём.
- будут созданы другие репозитории в каталогах с именем заканчивающимися на .newkey согласно структуре.
- будут сделаны объявления о процедуре миграции
- обновления из очереди Bodhi подписываются сразу новым ключем и попадают в новые репо.
- все старые пакеты подписываются заново новым ключем и переносятся в новые каталоги.
- старые репозитории очищаются (кроме fedora-release и PackageKit, требуемых для миграции свеже установленных систем ).
- будет создан новый fedora-release в новом репозитории который при обновлении удалит из системы старые ключи и старые .repo файлы.
- для Fedora 10 всё будет несколько проще - все пакеты будут подписаны новым ключем. Процедура миграции со старых версии Fedora будет выполнятся anaconda (установщик Fedora).
VIA K8M800 на Fedora 9
August 21, 2008 9:30 | Author: Vasile | написано в рубрике: Vasile | 402 views
Через пару месяцев после выхода 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
(ro) Fedora 8->9 upgrade şi Union Fenosa
July 5, 2008 11:27 | Author: Vasile | написано в рубрике: Vasile | 380 views
Извините, но данная статья доступна только на ro.
Апгрейд на Fedora 9
May 31, 2008 22:16 | Author: Oleg | написано в рубрике: Олег | 958 views
Вчера решился проапгрейдится. Как всегда проблем особых не было, но после перезагрузки появились нюансы. Сразу после перезагрузки gdm потерялл авто-логин, из-за того, что при установке был указан конфиг из rpm. Добавя несколько строчек все стало на свое место. Новый драйвер nvidia сразу заработал без нареканий. Прочитав, заметки об апгрейде, сделал манипуляции с Mozilla Thunderbird.
При проигрывании мультимедия в mplayer появилась ошибка: “The flip-hebrew option can’t be used in a config file. Error parsing option flip-hebrew=no at line 133.” Пришлось править кофиг /etc/mplayer/mplayer.conf и комментировать данный параметр. Следующая проблема была с wine. При запуске зависала полностью система. Как оказалось, это известный баг и на форумах рекомендуется обновить ядро, но для меня это не выход, т.к. пришлось бы пересобирать модуль ядра для видео драйвера. Оказался выход довольно простой: удаляем ~/.wine и занового его создаем. Еще одна проблема с wine: нет возможности набирать текст на кирилице.
Для тех, кто пользуется XFCE могут возникнуть проблемы с запуском “Диспечера настроек”. Решение оказалось в установке приложения at-spi.
Метки: fedora 9, migrate, wine
Миграция PC
January 28, 2008 17:17 | Author: Oleg | написано в рубрике: Олег | 342 views
Сегодня удачно прошла миграция с P4 на CoreDuo. Результат и эффективность: переименовал LVM Group, количество томов LVM сократил до 2-х. Миграция прошла бед rescue disk. Одна загрузка в init 1 и готово! Нюанс был в том, что в связи, что сетевуха стала другая (другой мак), в системе стал интерфейс eth1. Немножко погугля, нашел ответ на проблему. Одна перезагрузка и готово! Как переименовать eth0…5 есть в нашей вики в разделе “Установка и настройка”.
Обновилась видюха. Было i915G стало Geoforce 8500GT. Появились проблемы: открытые дровишки не работали, после установки xorg-x11-drv-nvidia все пошло нормально, но появились траблы с CS1.6, который работает через Wine. CS отказался работать с OpenGL, хотя с i915G все было ОК. Загадка. Понравилось, что sensors обнаружил датчик на видюхе и с удовольствием его отображает.
Первый раз увидел nvidia- settings. Очень порадовало. AMD панель - отдыхает.
Миграция HDD
January 26, 2008 13:23 | Author: Oleg | написано в рубрике: Олег | 345 views
Сегодня завершились мучения переноса моей системы на другой HDD, большего объёмом. Были нюансы, причём много, все подробней опишу позже в Wiki FedoraMD.org.
Метки: migrate
Обновляем Fedora с i386 на x86_64 архитектуру
January 12, 2008 4:00 | Author: FedoraMD.org | написано в рубрике: Новости | 228 views
На известном сайте Linux.com появился интересный материал об переходе с i386 на x86_64 версию Fedora 8. Описана процедура и подводные камни. То что официально не поддерживается оказывается вполне возможным.


(3 votes, average: 4.67 out of 5)