Не было печали, апдейтов накачали (Arch)

  • Tutorial

По мотивам этого поста.


Про Archlinux ходит множество слухов, в том числе не совсем правдивых. В частности, устоявшееся общественное мнение говорит, что Арч часто ломается при обновлениях, так как bleeding edge. На практике это это одна из самых живучих и ремонтопригодных систем, которая может жить годами без переустановок, при этом обновляясь чуть не каждый день.


Иногда, около одного-двух раз в год, проблемы всё-таки возникают. Какой-нибудь злостный баг умудряется просочиться в репозитории, после обновления система ломается, и вы как пользователь мало что можете с этим сделать — надо откатываться.


Ситуация


С очередным обновлением всё ломается к хренам собачьим. Уровень возможных проблем варьируется от "шрифты стали некрасивые" до "перестала работать сеть", а то и "ядро не видит дисковые разделы". Многие пользователи Арча умеют справляться с этой проблемой так или иначе, а в этой статье я расскажу как это делаю я.


Возврат контроля над системой


Для проведения ремонтных работ нам нужна консоль и работающая сеть. Если есть — хорошо. Если нет — есть простой и быстрый способ гарантированно их получить. Грузимся с загрузочной флешки, монтируем наши дисковые разделы, чрутимся в систему:


arch-chroot /mnt

Всё, мы в консоли нашей системы, и у нас есть сеть.
А наличие загрузочной флешки в арсенале арчевода — практически обязательно.


Алгоритм ремонта


  1. Убеждаемся, что проблема нерешаема своими силами
  2. Определяем виновника проблемы и дату проблемного обновления
  3. Подменяем /etc/pacman.d/mirrorlist
  4. Выполняем pacman -Syyuu

Система отремонтирована!


Как это работает


Существует специальный сервер обновлений под названием Arch Linux Archive (ранее он назывался Arch Linux Rollback Machine), в котором хранятся "слепки" всех репозиториев на каждую отдельную дату.


Желаемую дату можно выбрать, специальным образом задав имя сервера в файле mirrorlist. Проще всего старый файл забэкапить, создать новый и добавить туда единственную строчку (в примере задано 1 декабря 2017г)


##                                                                              
## Arch Linux repository mirrorlist                                             
## Generated on 2042-01-01                                                      
##
Server=https://archive.archlinux.org/repos/2017/12/01/$repo/os/$arch

После чего команда pacman -Syyuu принудительно обновит базу данных пакетов на ту, которая соответствует выбранной дате, и принудительно переустанавливает все пакеты в системе, версии которых не соответствуют этой дате.


Наша задача — определить ближайшую дату, откат на которую даёт рабочую систему, выяснить какие пакеты обновились на следующий день, и выяснить, какой из этих пакетов вызвал поломку.


Приступим!


Определение нужной даты


Если система обновлялась не очень давно, можно пошагово уменьшать дату в mirrorlist, каждый раз выполняя pacman -Syyuu и проверяя, не исчезла ли проблема. Плюсом такого подхода является то, что можно с высокой вероятностью сразу вычислить конкретный пакет и добавить его в /etc/pacman.conf в строчку IgnorePkg — до лучших времен.


Если с момента последнего обновления прошёл, допустим, месяц — то итеративно делим временной промежуток пополам. Сперва откатываемся на полмесяца назад. Если проблема исчезла — то обновляемся на четверть месяца вперед, если нет — то четверть месяца назад. И так далее. Этот способ позволяет определить точный момент сбоя, который произошёл в течение последнего года, всего за 9 смен даты.


Определение пакета-виновника


Итак, допустим — мы не обновлялись уже неделю, pacman сообщает что есть 200 необновленных пакетов. После обновления система ломается.


Откатываемся назад на сутки, несколько пакетов "обновляются" до более ранней версии. Проверяем — система все ещё сломана.


Откатываемся ещё на сутки, ещё несколько пакетов снижают версию. Система сломана.


Ещё на сутки, очередные три пакета "обновляются" наоборот и ура, проблема исчезла!
Теперь мы точно знаем, что виноват один из этих трех пакетов. Допустим, это linux, linux-headers и gnome-shell. Так как linux-headers тянутся вслед за linux, их в расчёт не берем, это зависимость. Так что у нас всего два варианта.


Далее мы поодиночке добавляем кандидатов в /etc/pacman.conf.
Начнём с пакета linux:


# Pacman won't upgrade packages listed in IgnorePkg and members of IgnoreGroup
IgnorePkg   =  linux
#IgnoreGroup =

После чего обновляем систему через pacman -Syu и смотрим, не исчезла ли проблема. Если она исчезла — то как раз потому, что пакет-виновник записан в pacman.conf как запрещенный к обновлению. Если не исчезла — снова откатывается на рабочую систему, вписываем в IgnorePkg следующего кандидата и повторяем цикл.


Пункт, который должен быть первым


А чей, собственно говоря, баг? Данная статья посвящена проблемам на уровне всего дистрибутива. Нет никакого смысла откатываться на старые версии пакетов, если проблема не вызвана их обновлениями. Поэтому первое, что делаем — это гуглим ошибку всеми возможными способами, настроив выдачу только на свежие записи. Если проблема общая — то с огромной вероятностью вы наткнетесь на свежий тред на каком-нибудь официальном форуме дистрибутива, где узнаете все подробности — точную дату проблемного обновления, имя проблемного пакета, и даже технические причины (что, собственно, сломалось под капотом).


Возьмем пример выше. Допустим, мы выяснили, что наша система не грузится в графический режим после обновления пакета gnome-shell до версии 3.26.2


Что делать дальше?


Сперва делаем, чтобы система работала — откатываемся на дату на день раньше вредного обновления и добавляем gnome-shell в IgnorePkg (как вариант — добавить всю группу gnome в IgnoreGroup, чтобы гном не обновлялся частично).


Далее пытаемся найти в гугле ответ на вопрос — "это моя личная проблема или у других тоже так?" Если такой проблемы в интернете не обнаружилось — это может быть признаком того, что баг слишком свежий. Ждем для уверенности несколько дней, иногда повторяя поисковые запросы в разных сочетаниях. Если проблема в том, что проблемный пакет действительно пролез в репозитории — она обязательно вылезет в интернете! У арча огромная пользовательская база, и люди будут писать багрепорты и задавать вопросы на форумах.


Если в течение нескольких дней вы не видите никаких упоминаний о проблеме — у меня для вас плохие новости. Систему вы с вероятностью, близкой к 100%, сломали сами. Вспоминайте свои действия, анализируйте логи, разбирайтесь что произошло. Вообще, такой случай (когда какое-то обновление приводит к поломке, но это не баг) характерно для ситуаций, которые всегда освещаются в новостях в заголовком "при обновлении требуется ручное вмешательство". Такое случается, когда очередное обновление привносит настолько серьезные изменения в систему, что средствами самого обновления корректно это осуществить не удаётся.

Share post

Similar posts

Comments 30

    +2
    > 2. Определяем виновника проблемы и дату проблемного обновления

    «Как нарисовать сову.»
      0
      Понял, сейчас распишу подробнее.
        0
        Да не поможет тут подробнее. У вас статья о том, как откатить апдейт, а это как раз ни разу не проблема, а вот как его найти — это да.
          0
          Дополнил статью. Всё ещё сова?
            +1
            Уже ближе к массам — я виндовод, но +- понял что, куда, зачем и как.
              +2
              Москва не сразу строилась. Статьи тоже пишутся итеративно)) Я думаю, в текущей редакции вопросов должно быть минимум.
                0
                Но если что, попробуйте откатить версию статьи на месяц назад и обновить — если вопросы исчезли, то вы на правильном пути!

                спойлер
                ну шутка же:) Вообще, довольно занятный механизм, в те времена, когда я сам возился с арчём, не знал почему-то про слепки репозиториев на дату. Оч полезно, как по мне.
      0
      На арче уже пару лет нет таких обновлений, которые ломают всё к чертям. Сходите на официальный форум — там уже давно скука смертная ). Хотя я помню времена переноса библиотек из /lib в /usr/lib и переход на systemd, было весело.

      На арче уже более пяти лет — лучший на мой взгляд дистрибутив
        0
        Прям буквально недавно, когда в стейбл упал Gnome 3.26 — гномощель стала рандомно крашиться, часто при закрытии или сворачивании окна некоторых приложений. Это был довольно назойливый баг, который затронул очень большое количество пользователей. Пришлось откатываться. До этого (правда, давно) был косяк с проприетарными дровами нвидии, которые после обновления xorg до 1.18 перестали работать на системах с Optimus. Пришлось откатываться, лочить иксы в IgnorePkg и ждать пока починят — гребаных 4 месяца.

        У меня Арч без переустановки живет около 6 лет, сменив пару дисков и четыре ноутбука.
          0
          Правда, что-ли? Я после того как 2 раза за неделю пришлось систему поднимать на ubuntu перешел. Вернуться что-ли. Дистрибутив тоже считаю лучшим.
            0
            аналогично, а для десктопа перешел с минта на antergos и уже года полтора никакие апдейты ничего не ломали
              0
              Буквально недавно pacman -Sy на старом ноуте сказал «а нету списка пакетов». Оказалось, они выбросили поддержку i686. Было неприятно. Я то перешел на Arch32. Но сам факт…
                +2
                Разработчики еще год назад предупреждали об окончании поддержки.
              0
              Думаю надо упомянуть, что по дефолту арч не удаляет старые пакеты из кэша пакмана, поэтому в большинстве ситуаций откат выглядит так:
              pacman -U /var/cache/pacman/pkg/ansible-2.4.1.0-1-any.pkg.tar.xz
              (ansible взят для примера)
                0
                Ну я потому и написал, что у каждого свой способ. Как уже было сказано выше — проблема в поиске виновника, и статья посвящена в целом этому. Прежде чем сделать pacman -U %pkgname%, надо сперва откуда-то имя разузнать.
                0
                Спасибо за статью. А на Manjaro данный гайд поможет при случае?
                  0
                  Если там репы арчевские используются — без сомнения поможет.
                    0
                    На Manjaro свои репы, не арчевские. По данному гайду вы накатите арчевские пакеты на манджаро, а это нежелательно, версии могут различаться.
                      0
                      Я особо не разбираюсь в производных дистрах, похоже путаю Manjaro и Antegros.
                    0
                    На Арче 10 лет, прямо совсем ломающих обновлений не помню, кроме железо-специфичных — например, на моём старом компе, использовавшем 32-битный Арч, отваливалась звуковуха с новыми версиями ядра. Завёл об этом баг — ответ был, что с 64-битным драйвером всё работает, а 32 бита тестировать некому. Ну и правда, как мы знаем, 32-битная архитектура больше не поддерживается.

                    Мой рецепт — подписаться на рассылки, по крайней мере на arch-announce. Туда пишут, когда очередное обновление требует ручного вмешательства. Например, так было с упомянутым обновлением filesystem и переносом /{bin,lib} -> /usr/{bin,lib}. Пришлось немного повозиться, но система поломана не была.
                      +2
                      Я тоже раньше был любителем всего нового, модного, молодёжного. А потом понял, что ОС нужна как драйвер между мной и машиной, и я её не должен замечать и чинить 3 раза в неделю. С тех пор я на stable дистрах и если меня всё устраивает, то обновляться не спешу.
                      Более того, при (нормально для меня) работающем софте и наличии обновлений появляется не то чтобы страх, но опасение, что после обновления что-то сломается.
                      Поэтому только обновления безопасности.

                      Как сказал один киношный персонаж, «я слишком стар для этого дерьма» ©.
                        +3
                        А я был поначалу любителем «stable»-дистров, а именно Убунты. А потом понял, что ОС нужна как драйвер между мной и машиной, и я не должен её замечать и переустанавливать как минимум раз в квартал — с частотой мажорных обновлений, которые Убунта почему-то не переживала у меня ни разу. Я слышал истории, как люди обновлялись с одной мажорной версии на другую, потом на третью, и их система работала и не ломалась. Такие люди ещё любят обвинять меня в кривизне рук)) А у меня дошло до ситуации, когда я ставил опыты — пытался обновить систему до следующей мажорной версии, чтобы руки вообще не влияли. Чистая установка, разбивка диска по-умолчанию, никаких новых пакетов не устанавливается — система предлагает обновление, я нажимаю «ок». Система мертва. Опыт был повторен много раз.

                        В какой-то момент я понял, что слишком стар для этого дерьма и не хочу возиться с переустановкой. Теперь у меня Арч, который без переустановки уже лет 6 живет. Ломается он фантастически редко, и в этом случае ремонтируется за 5 минут с закрытыми глазами.
                          0
                          У меня один пк живет на юбунте уже 12 лет, без переустановок и допиливаний
                            +1
                            И всё это время успешно обновляется с одной версии на другую?
                            0
                            Суть проблемы в первом же предложении. Убунту очень сложно назвать stable-дистром
                          0
                          Очень нравился арч одно время — и на ноуте стоял и на домашнем сервере. Но потом появился макбук, а домашний сервер перетащил на центос, потому что порой случались проблемы после обновлений, которые отнимали время. Да и не особо интересно стало возиться с этим, надо было, чтоб просто работало :-)
                          Тем не менее, для ПК это лучший дистрибутив, на мой взгляд.
                            +2
                            На Арче со времен rc.conf. Навскидку несколько основных советов, чтобы минимизировать количество и частоту печалек:
                            • Регулярно обновляйтесь. Мелкие и частые обновления минимизируют риск что-то сломать при этих самых обновлениях
                            • Регулярно заходите на офсайт и читайте новости (или можно подписаться на рассылку). Если очередное обновление требует каких-то ручных махинаций, об этом обязательно напишут и лучше об этом узнать до, а не после обновления
                            • Не заигрывайтесь с Aur. Да, там много нужного и вкусного, но лучше для него пользоваться makepkg, чем автоматизированными средствами типа yaourt (или как там его,
                              жив кстати?)
                            • Контролируйте появление *.pacnew и *.pacsave файлов в вашей системе (find / -name *.pacnew). Если формат конфигурационного файла какого-нибудь пакета изменился, актуализируйте свой конфиг, используя средства сравнения файлов
                            • Контролируйте список «pacman -Qm». Это пакеты, «установленные вручную». Сюда же попадают пакеты, которые когда-то были установлены из репозитория, но в будущем исключенные оттуда. Часто в таком случае оказывается, что данный пакет утратил свою актуальность/его функционал поглощен другим пакетом/… и он в вашей системе просто мусор
                            • Контролируйте список «pacman -Qdt». Это пакеты-сироты. Также в большинстве случаев достойны удаления
                            • Анализируйте назначение и историю происхождения пакетов из двух вышеприведенных списков, явно ненужное периодически подчищайте через «pacman -Rns». Кстати, если вам нужно установить пакет временно для тестирования или сборки чего-то, можно его установить с ключом --asdeps, тогда он автоматически получит статус сироты и в будущем не затеряется в вашей системе навечно, будет, так сказать, на примете
                            • Помните о принципе «не сломалось — не чини»
                              0

                              Первый пункт, согласен нужно это делать, но в зависимости от того какая репа(Обычные можно раз в неделю, testing раз в четыре дня, staging лучше каждые 12 часов.) используется.
                              Второй пункт, согласен.
                              Третий пункт, чем вам не угодил yaourt? (Не конечно я понимаю что можно городить связку git+makepkg, но зачем? (Сам по началу так делал пока про yaourt не вспомнил. Плюсом yaourt проверяет базу данных на наличие конфликтных файлов после установки пакетов pacman -Dk))
                              Четвертый пункт, бесспорно, но некоторые *.pacnew можно игнорировать. (Пример pacman-mirrorlist создает pacnew этого mirrorlist'а, но у тебя есть reflector который этот лист генерирует.)
                              Насчет пунктов 4, 5 и 6 лучше поступить кардинальнее все пакеты сделать asdeps и затем выбрать нужные asexplicit и снести другие. (Но этот вариант многим опаснее вашего.)
                              Седьмой пункт, согласен.
                              В качестве дополнения не забывайте делать резервные копии!

                              +2
                              У меня корень системы висит в brfs, а в .zshrc добавлен алиас update, где сначала делается снапшот, а потом уже pacman -Syu. В случае косяка:
                               sudo snapper -v undochange 0..НОМЕРРАБОЧЕГОСНАПШОТА 

                              А далее уже можно смотреть что делать с пакетом виновником.
                              Топорно, но уже как год работает. Недавно как раз откатывался из за через одно место рабочего NetworkManager.
                                0

                                У меня, как и у rusbaron, корень на btrfs. Удобно, могу в любой момент откатиться на состояние системы до обновления. Но если точно известно, в каком пакете косяк, можно зачрутиться в систему и откатить один пакет, нет смысла в таком случае откатываться на предыдущий снэпшот.


                                К примеру, недавно у меня система не могла загрузиться из-за бага в cryptsetup(корень на Btrfs поверх LUKS). Зная что проблема c cryptsetup, я просто зачрутился в систему и понизил версию пакета cryptsetup с помощью удобной тулзы downgrader. Добавил её в IgnorePkg, а когда проблему через несколько дней пофиксили, убрал из IgnorePkg и обновился.

                                Only users with full accounts can post comments. Log in, please.