Тонкости обновления ubuntu с 14.04 до 16.04

Итак, в итоге и я выделил время и решил слезть с системы, поддержка которой скоро прекратится, сервер как-никак, софт должен обновляться своевременно во избежание поиска уязвимостей всякими любителями-кулхацкерами 🙂

Если интересно — остальная запись вынесена под кат 🙂

В графической оболочке решил не обновляться, кстати для меня это в первый раз. Ушёл в консольку, нажав Ctrl+Alt+F1, залогинился, написал

do-release-upgrade

Как потом выяснилось, мне очень помогло то, что я обновлялся через консоль, у меня в /var/log/dist-upgrade/apt-term.log записался заветный лог обновления системы, который помог устранить некоторые небольшие косячки после апдейта и удалить «нулевые» пакеты, у которых был конфликт зависимостей и по логу они вроде как удалились, на самом деле присутствовали в системе, а при удалении на диске не прибавилось ни на байт свободного места.

Например, выдержка из лога:

dpkg: libtag1c2a:amd64: dependency problems, but removing anyway as you request$
 gstreamer1.0-plugins-good:amd64 depends on libtag1c2a (>= 1.5); however:
  Package libtag1c2a:amd64 is to be removed.
 vlc-nox depends on libtag1c2a (>= 1.7); however:
  Package libtag1c2a:amd64 is to be removed.

или из другой системы, руссифицированный лог:

dpkg: libtag1c2a:amd64: имеются проблемы с зависимостями, но по вашему указанию
он всё равно будет удалён:
 vlc-nox зависит от libtag1c2a (>= 1.7), однако:
  Пакет libtag1c2a:amd64 будет удалён.

Таких я прибивал нещадно, ручками 🙂 поскольку параллельно пробегал весь лог глазами и искал не возникло ли какой проблемы после обновления, о которой я не знаю.
Впринципе система обновилась вполне успешно, только после установки ждал меня неприятный сюрприз — было «поломано» всё, что работало на php, поскольку в 16.04 ubuntu в стоковые репозитории взяли и запилили php 7.0 и понятно что некоторые установленные у меня дистрибутивы к работе на новейшей версии оказались не совсем готовы. Проблему решил «костыль» (кстати единственный после обновления, да и то — через полгода я думаю можно его будет «прибить» и начать жить на php 7.0).
Костыль заключается в подключении «левого» репозитория и установке более древней версии php 5.6.

Инструкция, как это сделать:

В терминале пишем:

sudo apt-get purge `dpkg -l | grep php| awk '{print $2}' |tr "\n" " "`

здесь мы удалили все старые пакеты из нашей системы, в которых встречается слово «php»

sudo add-apt-repository ppa:ondrej/php

подключили «левый» репозиторий

sudo apt-get update
sudo apt-get install php5.6

подгружаем список пакетов из нового репозитория и инсталлим php 5.6

sudo apt-get install php5.6-mbstring php5.6-mcrypt php5.6-mysql php5.6-xml php5.6-cli

дополнительно инсталлим всякие нужные либы для работы связки Apache+PHP+MySQL

sudo php -v

проверяем что 5.6 установилась и «отвечает» нам, что с ней всё хорошо. 🙂

Если всё работает — радуемся. Если нет — пишем мне на почту gladsas@yandex.ru, ибо комменты пока выключены, а почту я получаю реал-тайм.

Далее — из стоковых репозиториев новой 16.04 убунты подтянулась и новая версия MySQL — 5.7. Говорю сразу — НЕ нужно пытаться удалить её и установить вашу старую 5.5 (какая была у меня) или 5.6 — завелось всё из коробки.
Я же этого не знал и по какой-то неведомой причине оно сразу у меня не завелось и на возвращение старой версии потратил несколько часов, а когда ничего не заработало — вернул новую и немного над ней поколдовал.
Но как у нас многих это принято «сначала делать, а потом читать инструкцию» я сначала занимался этим, а у же на следующий день анализировал логи обновления системы. Оказалось, что при установке MySQL автоматически проапдейтил все InnoDB таблички из всех доступных ему баз, а которые не работали — «подлечил». Кто не верит — снова выжимка из лога обновления:

mysql start/running, process 9357
Checking if update is needed.
Checking server version.
Running queries to upgrade MySQL server.
Checking system database.
mysql.columns_priv                                 OK
...
phpmyadmin.pma__table_uiprefs
error    : Table rebuild required. Please do "ALTER TABLE `pma__table_uiprefs` FORCE" or dump/reload to fix it!
...
Repairing tables
`phpmyadmin`.`pma__table_uiprefs`
Running  : ALTER TABLE `phpmyadmin`.`pma__table_uiprefs` FORCE
status   : OK

В примере выше я привёл два случая — когда при проверке таблицы всё было ОК и когда она требовала repair. MySQL отрепейрил все таблицы, которые посчитал нужным. Поэтому НЕ нужно пытаться вернуть старую версию MySQL ибо она уже не заработает.

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

На новой системе также при каждом выполнении

sudo apt-get update

всплывало предупреждение

N: Файл «50unattended-upgrades.ucf-old» в каталоге «/etc/apt/apt.conf.d/» игнорируется, так как он не имеет неправильное расширение

Вначале мне было не до него, поскольку я возился с php, потом оно «осело у меня в печёнках» и я пошёл смотреть что же там такого криминального и в чём отличия нового и старого конфига. Оказалось что в моём случае — ни в чём, так что старый файлик «50unattended-upgrades.ucf-old» смело удаляйте командой

sudo rm /etc/apt/apt.conf.d/50unattended-upgrades.ucf-old

Последнее замечание: на 16.04 отныне скрипты запуска нужно писать под systemd, а не upstart, поскольку частенько в процессе обновления я видел предупреждение (цитата из лога обновления):

insserv: warning: script 'seafile-server' missing LSB tags and overrides

И установленный у меня seafile не стартовал автоматически, пришлось сходить в /etc/init.d и прибить старый скрипт запуска, написав после этого новый, уже под systemd.

На этом все тонкости обновления моей ubuntu до 16.04 закончились, остальное сразу завелось как надо, а именно: графики температуры, загрузки сервера и прочие (речь про rrdtool), apcupsd новой версии также завёлся хорошо.

Добавить комментарий