Или разлепляем пельмени, а потом собираем их обратно. Пару заметок.
Собственно разработчики Linux Mint всегда рекомендовали использовать новую установку вместо того, что бы просто обновлять систему. Несколько релизов я всё же обновлялся путём исправления репозиториев и apg-get upgrade / apt-get dist-upgrade. При выходе 18 версии дистрибутива авторы выложили инструмент и инструкцию для сего обновления:
Как обычно проблемы кроятся в мелочах. А именно: не учитывается влияние PPA от слова совсем.
Собственно:
- Очень злую шутку играет наличие PPA. Да, утилита выключает все сторонние репозитории, да вот откат изменений из них до актуальных версий из существующих репозиториев она сделать не может. Особенно доставляет PPA
ppa:ubuntu-toolchain-r/test, который, обычно, ставят когда есть желание поиграться со свежими версиями компиляторов. В моём случае, версия libstdc++6 из этого PPA для Trusty окалазалась новее стандартной libstdc++6 для Xenial. Как следствие - утилиты типа apt, apt-get и прочие, которые могут помочь в решении насущных вопросов восстановления системы попросту не работают. Хорошо, что бронебойный dpkg остался в строю. - Cinnamon при обновлении может упасть в середине установки пакетов. С учётом предыдущего пункта - собственно и получаете систему в виде разлепленных пельменей.
- На системах с гибридной графикой можете столкнуться, что альтернативы для GL и EGL станут указывать на реализацию OpenGL от nVidia. Что потом будет приводить к странному падению Cinnamon при запуске. Про переключение и подробности падения можно посмотреть в заметке post/2014/11/13/linux_thinkpad_t530_i_minidp_displayport, там же лечение.
- Из разряда косметики, но с далеко идущими последствиями: может не обновится информация о дистрибутиве, которая выводится в Grub (косметика), при текстовом логине (косметика) и в выводе lsb_release. Первые два пункта - косметика, последний помимо эстетического неприятия приводит к тому, что добавления PPA через apt-add-repository добавляет его… для Trusty!
- Ещё я зачем-то перезагрузил компьютер. Отдать должное - система загрузилась до текстового логина. Но позникло непонятно: работа с сетью. У провайдера IPoE в самом простом варианте: просто втыкаешь Ethernet кабель и делаешь dhclient eth0. Сеть поднимается, выдаётся IP адрес, получаются DNS адреса, назначаются маршруты (если верить выводу ip route), ping работает, правда, только от root, но, судя по всему, по новой политике с него сняли SUID бит, что не страшно. Но тут начинаются весёлости: при отсутствующих правилах iptables (не используется) работают утилиты dig и host, резолвят адреса, но TCP соединения ни по имени домена ни по IP не устанавливаются. Ещё весёлостей для восстановления.
Собственно последняя проблема относится к категории: звёзды сложились. Но “вылечил” я её путём явного запрета IPV6:
echo "options ipv6 disable=1" > /etc/modprobe.d/ipv6.conf
и подключения не по кабелю, а по WiFi к роутеру. Тут я постоянно забываю, так что на правах мемориза три команды:
- iwlist - для сканирования сетей
- wpa_supplicant - для аутентификации
- wpa_passphrase - для генерации конфига для wpa_supplicant с зашифрованным ключём
Собственно последние две могут пригодиться и при правильном IPoE и проводном соединении.
Как видно, в сусти проблемы я не разобрался, но получив рабочую сеть сразу приступил к восстановлению системы.
Неработающий apt/apt-get решился скачиванием правильной версии libstdc++6 для данного релиза Ubuntu с официального сайта и установка его при помощи dpkg с указанием опции --force-all, так как вылазят конфликты, но они сейчас нас мало волнуют.
После чего apt заводится и достаточно выполнить:
apt-get -f install
что бы привести систему к вижу: фарш - отдельно, тесто - отдельно.
После этого станартная процедура из:
apt update
apt upgrade
apt dist-upgrade
После чего поможет утилита apt-show-versions, которая поможет найти пакеты, установленные в системе, но для которых нет соответствия в репозиториях:
apt-show-versions | grep 'No available version'
Тут могут быть как пакеты поставленные вручную, не из репозитория, типа Teamviewer или пакеты сделанные при помощи checkinstall - на такие нужно просто обратить внимание, может они уже и не нужны или нуждаются в обновлении. Ну и самая гнусная категория - это пакеты, которые “новее”, чем те, что есть в стандартных репозиториях, обычно это остатки от PPA или сторонних репозиториев. Тут можно поступить двумя путями: настроить нужные сторонние репозитории и обновиться, что скорее всего вылечит от некого числа таких зависших пакетов, либо откатить все такие пакеты на дистрибутивные.
Я выбрал последний пункт. Дело в том, что если в DEB системах в нескольких репозиториях есть разные версии одного пакета, то выбран по умолчанию будет самый новый (согласно правилам сравленения версий пакетов), но у вас остаётся возможность принудительно поставить и любую другую версию пакета, явно указав её:
apt install foo=version
а вообще, для таких пакетов команда
apt show -a foo
выведет несколько записей, где можно посмотреть и описание и версии.
В случае “зависших” пакетов, в выводе apt show будет первой записью информация об установленной версии, а второй - актуальная версия в репозиториях. Ну а алгоритм получается так:
- пробегаемся по каждому пакету
- смотрим вывод apt show
- если записей больше одной, то добавляем в список запись вида “пакет=версия”
- в конце одним махом делаем``` apt-get install пакет1=версия1 пакет2=версия2 … пакетN=версияN
Почему одним махом? А потому, что "зависшие" пакеты могут зависеть по версии друг от друга. Таким образом мы сразу выбираем все пакеты из дистрибутивных репозиториев и не ломаем зависимости. Чуть позже выложу скрипт, которые мне помог в разгребании этой проблемы.
Прочие "висячие" пакеты (для которых доступна только одна, установленная, версия) можно удалять. Но я делал это поодиночке, обращая внимание на то, что удаляется как связанная сущность. Само удаление делал парой команд:
apt-get purge foo apt-get autoremove
autoremove использовал для того, что бы сразу удалить пакеты, которые ставились как зависимость для текущего. Предварительно я добился того, что бы список для autoremove был пуст - велика вероятность снести не то, чего хотелось бы. Для этого пункта тоже сделан скрипт.
Следующий шаг: поискать необновлённые пакеты, которые остались от PPA и актуальны для предыдущей версии. Некоторые такие пакеты, почему-то, не попадают в список **apt-show-versions**. Как их искать? Сложный вопрос. Если авторы порядочные люди, они в версию добавляют версию дистрибутива или его кодовое имя, тогда найти пакеты просто:
dpkg -l | grep ‘14.04
|trusty’
потом по этому списку пройтись по алгоритму удаления "висящих" пакетов.
Если информации о версии дистрибутива нет, пакет именно такой версии есть и стандартных репозиториях (при этом собран для старой версии библиотек), то простых вариантов решения проблемы я не вижу. Лично я оставил до момента, когда реально столкнусь с поломкой. Но мысль такая: смотреть кто пакетировал, сравнивать с записью для репозиторных пакетов, при не соответствии форсированно заменять на версию из репзитория.
После этого нужно добиться правильной работы **lsb_release**. В чём тут дело, я так до конца и не разобрался: отчего-то не обновились файлы:
* /etc/issue
* /etc/issue.net
* /etc/lsb-release
из пакеты *base-files* который предоставляется командой разработчиков Linux Mint, причём в самом пакете эти файлы с правильными данными. **dpkg-reconfigure** на пакет ни к чему не приводит, ровно как и форсированная переустановка. Поэтому решил просто: просто достал эти файлы из пакета и заменил их в файловой системе.
Косметическая проблема с названием пункта меню в Grub решается стандартно:
dpkg-reconfigure grub-pc
После этих телодвижения **apt-add-repository** станет работать корректно и можно приступать к восстановлению нужных сторонних репозиториев и PPA и установкой софта/обновлений из них.
В целом ощущения такие:
* стоило обновляться стандартным образом, как делал это раньше;
* сколько зарекался запускать обновления из X11... в общем - консоль в помощь;
* понятно нежелание разработчиков Mint поддерживать обновление: всего не учтёшь, а лучи ненависти получать будут;
* флешка загрузочная даже не потребовалась, значит система просто превратилась в фарш, а не тыкву;
* для C++ хочется стабильности ABI, хотя бы на уровне, сопоставимом с glibc;
* это тот случай, когда хочется, что бы весь пакетный менеджер был собран статически.