По мотивам этого поста.
Про Archlinux ходит множество слухов, в том числе не совсем правдивых. В частности, устоявшееся общественное мнение говорит, что Арч часто ломается при обновлениях, так как bleeding edge. На практике это это одна из самых живучих и ремонтопригодных систем, которая может жить годами без переустановок, при этом обновляясь чуть не каждый день.
Иногда, около одного-двух раз в год, проблемы всё-таки возникают. Какой-нибудь злостный баг умудряется просочиться в репозитории, после обновления система ломается, и вы как пользователь мало что можете с этим сделать — надо откатываться.
Ситуация
С очередным обновлением всё ломается к хренам собачьим. Уровень возможных проблем варьируется от "шрифты стали некрасивые" до "перестала работать сеть", а то и "ядро не видит дисковые разделы". Многие пользователи Арча умеют справляться с этой проблемой так или иначе, а в этой статье я расскажу как это делаю я.
Возврат контроля над системой
Для проведения ремонтных работ нам нужна консоль и работающая сеть. Если есть — хорошо. Если нет — есть простой и быстрый способ гарантированно их получить. Грузимся с загрузочной флешки, монтируем наши дисковые разделы, чрутимся в систему:
arch-chroot /mntВсё, мы в консоли нашей системы, и у нас есть сеть.
А наличие загрузочной флешки в арсенале арчевода — практически обязательно.
Алгоритм ремонта
- Убеждаемся, что проблема нерешаема своими силами
- Определяем виновника проблемы и дату проблемного обновления
- Подменяем /etc/pacman.d/mirrorlist
- Выполняем 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%, сломали сами. Вспоминайте свои действия, анализируйте логи, разбирайтесь что произошло. Вообще, такой случай (когда какое-то обновление приводит к поломке, но это не баг) характерно для ситуаций, которые всегда освещаются в новостях в заголовком "при обновлении требуется ручное вмешательство". Такое случается, когда очередное обновление привносит настолько серьезные изменения в систему, что средствами самого обновления корректно это осуществить не удаётся.
mistergrim
> 2. Определяем виновника проблемы и дату проблемного обновления
«Как нарисовать сову.»
Narical Автор
Понял, сейчас распишу подробнее.
mistergrim
Да не поможет тут подробнее. У вас статья о том, как откатить апдейт, а это как раз ни разу не проблема, а вот как его найти — это да.
Narical Автор
Дополнил статью. Всё ещё сова?
Skerrigan
Уже ближе к массам — я виндовод, но +- понял что, куда, зачем и как.
Narical Автор
Москва не сразу строилась. Статьи тоже пишутся итеративно)) Я думаю, в текущей редакции вопросов должно быть минимум.
4umak
Но если что, попробуйте откатить версию статьи на месяц назад и обновить — если вопросы исчезли, то вы на правильном пути!
maisvendoo
На арче уже пару лет нет таких обновлений, которые ломают всё к чертям. Сходите на официальный форум — там уже давно скука смертная ). Хотя я помню времена переноса библиотек из /lib в /usr/lib и переход на systemd, было весело.
На арче уже более пяти лет — лучший на мой взгляд дистрибутив
Narical Автор
Прям буквально недавно, когда в стейбл упал Gnome 3.26 — гномощель стала рандомно крашиться, часто при закрытии или сворачивании окна некоторых приложений. Это был довольно назойливый баг, который затронул очень большое количество пользователей. Пришлось откатываться. До этого (правда, давно) был косяк с проприетарными дровами нвидии, которые после обновления xorg до 1.18 перестали работать на системах с Optimus. Пришлось откатываться, лочить иксы в IgnorePkg и ждать пока починят — гребаных 4 месяца.
У меня Арч без переустановки живет около 6 лет, сменив пару дисков и четыре ноутбука.
n0dwis
Правда, что-ли? Я после того как 2 раза за неделю пришлось систему поднимать на ubuntu перешел. Вернуться что-ли. Дистрибутив тоже считаю лучшим.
buran1
аналогично, а для десктопа перешел с минта на antergos и уже года полтора никакие апдейты ничего не ломали
lorc
Буквально недавно pacman -Sy на старом ноуте сказал «а нету списка пакетов». Оказалось, они выбросили поддержку i686. Было неприятно. Я то перешел на Arch32. Но сам факт…
Aristarkh
Разработчики еще год назад предупреждали об окончании поддержки.
larrabee
Думаю надо упомянуть, что по дефолту арч не удаляет старые пакеты из кэша пакмана, поэтому в большинстве ситуаций откат выглядит так:
(ansible взят для примера)Narical Автор
Ну я потому и написал, что у каждого свой способ. Как уже было сказано выше — проблема в поиске виновника, и статья посвящена в целом этому. Прежде чем сделать pacman -U %pkgname%, надо сперва откуда-то имя разузнать.
t3mnikov
Спасибо за статью. А на Manjaro данный гайд поможет при случае?
Narical Автор
Если там репы арчевские используются — без сомнения поможет.
Aristarkh
На Manjaro свои репы, не арчевские. По данному гайду вы накатите арчевские пакеты на манджаро, а это нежелательно, версии могут различаться.
Narical Автор
Я особо не разбираюсь в производных дистрах, похоже путаю Manjaro и Antegros.
ziv
На Арче 10 лет, прямо совсем ломающих обновлений не помню, кроме железо-специфичных — например, на моём старом компе, использовавшем 32-битный Арч, отваливалась звуковуха с новыми версиями ядра. Завёл об этом баг — ответ был, что с 64-битным драйвером всё работает, а 32 бита тестировать некому. Ну и правда, как мы знаем, 32-битная архитектура больше не поддерживается.
Мой рецепт — подписаться на рассылки, по крайней мере на arch-announce. Туда пишут, когда очередное обновление требует ручного вмешательства. Например, так было с упомянутым обновлением filesystem и переносом /{bin,lib} -> /usr/{bin,lib}. Пришлось немного повозиться, но система поломана не была.
omgiafs
Я тоже раньше был любителем всего нового, модного, молодёжного. А потом понял, что ОС нужна как драйвер между мной и машиной, и я её не должен замечать и чинить 3 раза в неделю. С тех пор я на stable дистрах и если меня всё устраивает, то обновляться не спешу.
Более того, при (нормально для меня) работающем софте и наличии обновлений появляется не то чтобы страх, но опасение, что после обновления что-то сломается.
Поэтому только обновления безопасности.
Как сказал один киношный персонаж, «я слишком стар для этого дерьма» ©.
Narical Автор
А я был поначалу любителем «stable»-дистров, а именно Убунты. А потом понял, что ОС нужна как драйвер между мной и машиной, и я не должен её замечать и переустанавливать как минимум раз в квартал — с частотой мажорных обновлений, которые Убунта почему-то не переживала у меня ни разу. Я слышал истории, как люди обновлялись с одной мажорной версии на другую, потом на третью, и их система работала и не ломалась. Такие люди ещё любят обвинять меня в кривизне рук)) А у меня дошло до ситуации, когда я ставил опыты — пытался обновить систему до следующей мажорной версии, чтобы руки вообще не влияли. Чистая установка, разбивка диска по-умолчанию, никаких новых пакетов не устанавливается — система предлагает обновление, я нажимаю «ок». Система мертва. Опыт был повторен много раз.
В какой-то момент я понял, что слишком стар для этого дерьма и не хочу возиться с переустановкой. Теперь у меня Арч, который без переустановки уже лет 6 живет. Ломается он фантастически редко, и в этом случае ремонтируется за 5 минут с закрытыми глазами.
antonsr98
У меня один пк живет на юбунте уже 12 лет, без переустановок и допиливаний
Narical Автор
И всё это время успешно обновляется с одной версии на другую?
wsf
Суть проблемы в первом же предложении. Убунту очень сложно назвать stable-дистром
Zebradil
Очень нравился арч одно время — и на ноуте стоял и на домашнем сервере. Но потом появился макбук, а домашний сервер перетащил на центос, потому что порой случались проблемы после обновлений, которые отнимали время. Да и не особо интересно стало возиться с этим, надо было, чтоб просто работало :-)
Тем не менее, для ПК это лучший дистрибутив, на мой взгляд.
Jokerjar
На Арче со времен rc.conf. Навскидку несколько основных советов, чтобы минимизировать количество и частоту печалек:
жив кстати?)
AntonAlekseevich
Первый пункт, согласен нужно это делать, но в зависимости от того какая репа(Обычные можно раз в неделю, testing раз в четыре дня, staging лучше каждые 12 часов.) используется.
Второй пункт, согласен.
Третий пункт, чем вам не угодил yaourt? (Не конечно я понимаю что можно городить связку git+makepkg, но зачем? (Сам по началу так делал пока про yaourt не вспомнил. Плюсом yaourt проверяет базу данных на наличие конфликтных файлов после установки пакетов
pacman -Dk))Четвертый пункт, бесспорно, но некоторые *.pacnew можно игнорировать. (Пример pacman-mirrorlist создает pacnew этого mirrorlist'а, но у тебя есть reflector который этот лист генерирует.)
Насчет пунктов 4, 5 и 6 лучше поступить кардинальнее все пакеты сделать asdeps и затем выбрать нужные asexplicit и снести другие. (Но этот вариант многим опаснее вашего.)
Седьмой пункт, согласен.
В качестве дополнения не забывайте делать резервные копии!
rusbaron
У меня корень системы висит в brfs, а в .zshrc добавлен алиас update, где сначала делается снапшот, а потом уже pacman -Syu. В случае косяка:
А далее уже можно смотреть что делать с пакетом виновником.
Топорно, но уже как год работает. Недавно как раз откатывался из за через одно место рабочего NetworkManager.
glowingsword
У меня, как и у rusbaron, корень на btrfs. Удобно, могу в любой момент откатиться на состояние системы до обновления. Но если точно известно, в каком пакете косяк, можно зачрутиться в систему и откатить один пакет, нет смысла в таком случае откатываться на предыдущий снэпшот.
К примеру, недавно у меня система не могла загрузиться из-за бага в cryptsetup(корень на Btrfs поверх LUKS). Зная что проблема c cryptsetup, я просто зачрутился в систему и понизил версию пакета cryptsetup с помощью удобной тулзы downgrader. Добавил её в IgnorePkg, а когда проблему через несколько дней пофиксили, убрал из IgnorePkg и обновился.
?