Как откатить linux manjaro

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

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

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

Ситуация

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

compizomania

Азбука в Linux для начинающих и не только. Я знаю только то, что ничего не знаю, но другие не знают и этого. Сократ

Страницы

08 апреля 2020

Как восстановить загрузчик GRUB Manjaro после установки другой системы Linux?

Многие пользователи компьютером устанавливают на жёсткий диск несколько ОС, чтобы попробовать и выбрать наиболее подходящую под свои запросы и возможности компьютера.
Если после установки Manjaro была установлена другая система Linux, например, Ubuntu; Linux Mint или Fedora и т.п., то загрузчик операционных систем GRUB теперь будет от последней установленной системы Linux.

Но вот незадача, войти в Manjaro будет проблематично, а именно, переключаясь в GRUB на строку с Manjaro и нажатия Enter, система не загружается и на экране появляется примерно вот такое извещение с Kernel panic:

Некоторые пользователи переустанавливают Manjaro, чтобы её загрузчик GRUB был главным, а из GRUB Manjaro, можно загрузиться и в другие системы.
Но переустанавливать Manjaro совсем необязвтельно. Для того чтобы из загрузчика GRUB, например, Ubuntu зайти в систему Manjaro, необходимо прежде переключится на строку Advanced options Manjaro и нажать Enter.

А затем в открывшемся меню выбрать третью строку с fallback initramfs или резервную инициализацию файловой системы и нажать Enter.

Таким образом пользователь совершает вход в систему Manjaro без проблем.

После того как пользователь вошёл в Manjaro, можно восстановить загрузчик GRUB Manjaro следующей командой в терминале:

sudo grub-install /dev/sda

И остаётся только обновить GRUB:

Вот и все. Теперь можно перезагрузить компьютер, чтобы убедиться, что система Manjaro находится первой в меню загрузчика GRUB.

Источник

Бэкап Linux и восстановление его на другом железе

Я работаю в организации с маленьким штатом, деятельность тесно связана с IT и у нас возникают задачи по системному администрированию. Мне это интересно и частенько я беру на себя решение некоторых.

На прошлой неделе мы настраивали FreePBX под debian 7.8, нанимали фрилансера. В процессе настройки оказалось, что сервер (да, я так называю обычный PC) не хочет грузится с HDD при подключенных USB 3G модемах, которые мы используем для звонков на мобильные, колупание BIOSа не помогло. Непорядок. Решил, что нужно перенести его на другую железяку. Так появилось сразу две связанные задачи:

• сделать бэкап сервера;
• восстановить бэкап на другом железе.

Гугление не дало внятных ответов, как это сделать, пришлось собирать информацию кусками и пробовать. Всякие acronis’ы отбросил сразу, ибо не интересно.

Опыт общения с linux-системами у меня небольшой: настройка VPN сервера на open-vpn, ftp-сервера и еще пара мелочей. Сам себя я характеризую как человека умеющего читать маны и править конфиги 🙂

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

Начинаем копать теорию:

Второй способ требует наличия внешнего жесткого диска объемом не меньше раздела, который архивируем. Да и что с ним потом делать, непонятно, хранить на полочке? Остановился на tar, чуть сложнее в реализации, нужно будет создать MBR, но время создания/восстановления архива существенно меньше, хранить бэкап проще, полтора гига можно закинуть в облако и скачать, когда будет нужно. Записывать его можно на ту же live-флэшку, с которой буду грузиться.

Итак, план действия:

1. Создание бэкапа

Грузимся с live-флэшки, у меня это debian-live-7.8.0-amd64-standard.

Переключаемся на root:

Монтируем раздел, который будем архивировать, у меня это sda1, чтобы случайно не наломать дров, монтируем только для чтения. Посмотреть все свои разделы можно при помощи команд ls /dev | grep sd или df -l

Наша флэшка уже примонтирована, но в режиме только чтения, нужно перемонтировать для чтения-записи, чтобы писать туда бэкап.

Все готово для создания архива

Здесь у нас параметры: c — создать архив, v — выводить информацию о процессе, z — использовать сжатие gzip, p — сохраняем данные о владельцах и правах доступа, f — пишем архив в файл, путь к файлу, —exclude — исключаем из архива каталог (я исключил каталоги с записями разговоров и каталог с бэкапами FreePBX), /mnt/ — каталог, который архивируем.

Ждем… у меня вся подготовка и создание архива заняли 10 минут. Будь флэшка быстрее, уложился бы в 7-8 минут.

Складываем архив в надежное место за пределами офиса.

Восстановление бэкапа на другом железе

2. Размечаем диск, создаем файловую систему

Грузимся с live-флэшки, у меня все та же debian-live-7.8.0.

Переключаемся на root:

Размечаем диск. Мне понравилась утилита с псевдографическим интерфейсом cfdisk. Там все просто и понятно.

Удаляем все имеющиеся разделы. Я создал два новых раздела, один на 490 Gb под / (sda1) и 10 Gb под swap (sda2) в конце диска, т.к. он практически не будет задействован. Проверим типы разделов. Который под систему должен иметь тип 83 Linux, второй — 82 Linux swap / Solaris. Помечаем системный раздел загрузочным (bootable), сохраняем изменения и выходим.

Cоздаем файловую систему на первом разделе.

3. Распаковываем архив.

Монтируем отформатированный раздел

Распаковываем архив прямо с флэшки

Параметр —same-owner — сохраняет владельцев у распаковываемых файлов, x — извлекаем из архива, v — выводить информацию о процессе, p — сохраняем права доступа, f — указываем файл, который распаковываем, C — распаковываем в категорию.

4. Создаем MBR на новом диске.

Чтобы корректно создать загрузочную запись, монтируем рабочие каталоги к нашему будущему root-каталогу, у меня это /mnt. Каталоги /dev и /proc сейчас используются live-системой, используем параметр bind, чтобы они были доступны сразу в двух местах:

Переключаемся на новую систему используя chroot:

Делаем swap-раздел для новой системы:

Подключаем его же:

Чтобы grub работал, нужно указать ему правильные UUID разделов в fstab, сейчас там прописаны разделы предыдущей системы:

Открываем второй терминал (Alt+F2) под root:

И видим текущие UUID разделов.

Вручную переписываем их в fstab переключаясь между Alt+F1 и Alt+F2. Да, муторно, но попытки копировать занимали у меня больше времени, чем переписывание. Сохраняем fstab.

Устанавливаем grub2. У меня один физический диск, поэтому ставим его на sda:

На чистый диск должно встать без ошибок. Обновляем информацию из fstab:

Возвращаемся в Live-систему:

Размонтируем все каталоги:

Если вылазят процессы, которые используют эти каталоги, убиваем их используя fuser.

Все, поехали. Грузимся с жесткого диска:

Здесь статья должна была закончиться, но у меня возникли проблемы с подключением к интернету. Сервер видит сеть, видит компьютеры в ней, но в интернет не ходит… а это как бы важно для телефонии.

5. Тестирование и устранение неполадок.

Показывет интерфейсы eth1 и lo, гугление сказало, что gateway можно прописать только подключению eth0, остальные рассчитаны только на работу внутри сети.

Похоже, отсутствие eth0 вызвано способом переноса системы. Находим файл, который отвечает за нумерацию интерфейсов, смотрим туда:

Действительно, там два активных интерфейса, определенных MAC’ами. Комментируем первый, второму прописываем eth0.

Перезапуск /etс/init.d/networking не помог, поэтому перезагружаемся:

Подключаем донглы, проверяем, все работает.
Спасибо за внимание.

Источник