![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
f16 -> f18
Jun. 13th, 2013 11:30 pmНаконец решил переехать на новомодное, с идеями чучхэЛеннарта Поттеринга (меня тут за чаем коллеги в качестве стёба попросили линки на lurkmore использовать, ну, вот тут уместно), воплощённое во всей красе в F18. То, что это самый тяжкий апгрейд в моей жизни, я понял после двух вечеров, поминая всуе идеи чучхэ, заложенные в основе. На такую глубь ковыряния системы при апгрейде я не опускался давно. Но давайте по порядку.
Вечер первый, или ничто не предвещало беды
Традиционно я обновляю систему через yum. Так же начал и в этот раз, загрузил и установил пакеты fedora-release и fedora-release-notes руками, потом сказал yum update. Yum радостно зашуршал и через какое-то время выдал список ломающих систему зависимостей (самосборные пакеты), после их удаления все зависимости просчитались, и манящий своей перспективой вопрос "Продолжить [д/Н]:" появился на экране. Я, наивный, ответил: "Конечно, да!"
Полчаса на загрузку (да, я отсталый, у меня 10Мбит канал), и приключения начинаются...
Рекурсия - см. Рекурсия. Попытка просчитать транзакцию завершилась печально: rpm не смог найти свою внутреннюю зависимость rpmlib(X-CheckUnifiedSystemdir), и мне предложено было обновить RPM. "Ладно", - думаю я, - "обновлю руками", что сразу и сделал. Перезапускаю yum update, и снова здравствуйте. Картина никак не изменилась, хотя rpm уже 4.10.
Чем дальше в лес... Исходная зависимость требовалась для пакета filesystem - один из базовых пакетов системы. Попробовал установить пакет руками. Ага, идеичучхэ не дали совершить действие. Я ж совсем забыл, что тут systemd головного мозга во весь рост! /lib, /bin и /sbin - символические ссылки на /usr/lib, /usr/bin и /usr/sbin соответственно. Я прилежно скопировал каталоги и поставил симлинки на их копии, но не подумал, что содержимое каталогов неплохо бы скопировать в соответствующие каталоги в /usr. Тут-то и поджидало меня веселье. Я говорю, хочу filesystem, glibc и ещё каких-то пару пакетов за раз поставить, игнорируя эту внутреннюю зависимость. Установка радостно обламывается, я остаюсь в системе, где у меня в /lib, /bin и /sbin нет никаких базовых утилит (они же в соседние каталоги забэкаплены)! Пришлось вспоминать LD_LIBRARY_PATH, LD_PRELOAD.
Может ли быть хуже? А вот может, после того, что команда ls и подобные заработали снова, я попытался обновить glibc. Я уж не припомню, что там обломалось, но каждый последующий запуск чего угодно заканчивался Segmentation fault. Вот тут пришлось ещё вспомнить и запуск бинарников через ld-linux.so... В процессе борьбы я склонялся к варианту "А ну его к чёрту, может с usb-брелока и по-новому раскатать систему?", но не наш же путь! Кое-как, привёл в чувства, догадался наконец скопировать содержимое /lib и Ко в соответствующие каталоги в /usr и перезапустили yum update, правда уже по частям (пара небольших обновления и пара довольно больших), после чего ушёл спать.
Забыл совсем упомянуть крах базы rpm во время песен и плясок вокруг разломанной системы. rpm --rebuilddb справился вроде бы неплохо, хотя появились дубликаты записей некоторых пакетов. Часть из них я удалил руками, часть (старые пакеты) удалились при обновлении yum'ом.
День следующий
Утром перед работой я перезагрузил систему, чтобы под новое ядро всё запустилось, да и посмотреть на этот самый systemd.
Ага, отвалилась сеть. Ну, ладно, до вечера уж подождёт. Вечером продолжил исследования. Не помню каким бубном и шаманскими танцами, но сеть поднялась (перезагружался для проверки, что автоматом всё тоже сработает). Открыл для себя nm-tool, nmcli и nm-online. Ах, помню, что пришлось сказать systemctl disable network.service - LSB сервис, который по сути кроме красных надписей при загрузке ничего не добавлял (может в этом была причина?).
Следующая проблема - X не стартуют. Долгое копание в заменителях runlevel'ов и файлах настройки systemd выяснил, автор сего чуда - большой любитель символических ссылок. Первое, надо проставить символическую ссылку на необходимую цель (у нас же systemd, помните?), чтобы она была целью по умолчанию. Попытка запуска init 5 ничего не давала. Посмотрел новомодный файл graphics.target, там упоминался display-manager.service. Догадаетесь, что мне было сказано на попытку systemctl start display-manager.service? Правильно "No such file or directory"! Символические ссылки... Эту мантру должен повторять каждый пользователь systemd. systemctl enable gdm.service автоматически (хоть где-то автоматика сработала!) проставил ссылку gdm.service <- default.service.
Наконец-то появилась графика, чтобы запускать браузер. Я давно уже использую Xfce, но с каждым релизом там хуже и хуже, такое впечатление, что там специально наняли человека, который чуть-чуть портит.
Проблемы с Xfce и их решения.
Ну, ещё по мелочи, mc перестал нормально отображать цвета в панелях, когда запущен под screen, а терминал 256-цветный. На этот счёт есть запись #902911 в RH Bugzilla.
В остальном пока что полёт нормальный.
Вечер первый, или ничто не предвещало беды
Традиционно я обновляю систему через yum. Так же начал и в этот раз, загрузил и установил пакеты fedora-release и fedora-release-notes руками, потом сказал yum update. Yum радостно зашуршал и через какое-то время выдал список ломающих систему зависимостей (самосборные пакеты), после их удаления все зависимости просчитались, и манящий своей перспективой вопрос "Продолжить [д/Н]:" появился на экране. Я, наивный, ответил: "Конечно, да!"
Полчаса на загрузку (да, я отсталый, у меня 10Мбит канал), и приключения начинаются...
Рекурсия - см. Рекурсия. Попытка просчитать транзакцию завершилась печально: rpm не смог найти свою внутреннюю зависимость rpmlib(X-CheckUnifiedSystemdir), и мне предложено было обновить RPM. "Ладно", - думаю я, - "обновлю руками", что сразу и сделал. Перезапускаю yum update, и снова здравствуйте. Картина никак не изменилась, хотя rpm уже 4.10.
Чем дальше в лес... Исходная зависимость требовалась для пакета filesystem - один из базовых пакетов системы. Попробовал установить пакет руками. Ага, идеи
Может ли быть хуже? А вот может, после того, что команда ls и подобные заработали снова, я попытался обновить glibc. Я уж не припомню, что там обломалось, но каждый последующий запуск чего угодно заканчивался Segmentation fault. Вот тут пришлось ещё вспомнить и запуск бинарников через ld-linux.so... В процессе борьбы я склонялся к варианту "А ну его к чёрту, может с usb-брелока и по-новому раскатать систему?", но не наш же путь! Кое-как, привёл в чувства, догадался наконец скопировать содержимое /lib и Ко в соответствующие каталоги в /usr и перезапустили yum update, правда уже по частям (пара небольших обновления и пара довольно больших), после чего ушёл спать.
Забыл совсем упомянуть крах базы rpm во время песен и плясок вокруг разломанной системы. rpm --rebuilddb справился вроде бы неплохо, хотя появились дубликаты записей некоторых пакетов. Часть из них я удалил руками, часть (старые пакеты) удалились при обновлении yum'ом.
День следующий
Утром перед работой я перезагрузил систему, чтобы под новое ядро всё запустилось, да и посмотреть на этот самый systemd.
Ага, отвалилась сеть. Ну, ладно, до вечера уж подождёт. Вечером продолжил исследования. Не помню каким бубном и шаманскими танцами, но сеть поднялась (перезагружался для проверки, что автоматом всё тоже сработает). Открыл для себя nm-tool, nmcli и nm-online. Ах, помню, что пришлось сказать systemctl disable network.service - LSB сервис, который по сути кроме красных надписей при загрузке ничего не добавлял (может в этом была причина?).
Следующая проблема - X не стартуют. Долгое копание в заменителях runlevel'ов и файлах настройки systemd выяснил, автор сего чуда - большой любитель символических ссылок. Первое, надо проставить символическую ссылку на необходимую цель (у нас же systemd, помните?), чтобы она была целью по умолчанию. Попытка запуска init 5 ничего не давала. Посмотрел новомодный файл graphics.target, там упоминался display-manager.service. Догадаетесь, что мне было сказано на попытку systemctl start display-manager.service? Правильно "No such file or directory"! Символические ссылки... Эту мантру должен повторять каждый пользователь systemd. systemctl enable gdm.service автоматически (хоть где-то автоматика сработала!) проставил ссылку gdm.service <- default.service.
Наконец-то появилась графика, чтобы запускать браузер. Я давно уже использую Xfce, но с каждым релизом там хуже и хуже, такое впечатление, что там специально наняли человека, который чуть-чуть портит.
Проблемы с Xfce и их решения.
- systray стал бегать по панели, а не придерживаться её края. Оказывается, раньше tasklist автоматически занимал всю ширину панели. Коммит 080db558 всё испортил. Лечить установкой разделителя перед systray plugin со свойством expandable.
- magnet-link не открывается. Не знаю, что там произошло, исправление здесь.
- и самое нетривиальное, часы на боковой панели стали повёрнутыми вертикально. Вначале потратил время, чтобы найти параметр rotate-vertically, который установили в TRUE по умолчанию (что курили?). Затем выяснил, смена параметров вручную в файле настроек панели ни к чему не приводит, они перезаписываются (может я что-то неправильно там форматировал?), зато православный путь - использование xfconf-query, а именно
xfconf-query -c xfce4-panel -p /plugins/plugin-18/rotate-vertically -n -t bool -s false, предварительно определив, как называется модуль часов.
Ну, ещё по мелочи, mc перестал нормально отображать цвета в панелях, когда запущен под screen, а терминал 256-цветный. На этот счёт есть запись #902911 в RH Bugzilla.
В остальном пока что полёт нормальный.
