Все об Arch Linux
Arch Linux будет тем, что вы из него сделаете!
Все об Arch Linux
Arch Linux будет тем, что вы из него сделаете!
Сбой случился: питание вырубилось посреди обновления, ядро ушло в панику, диск отвалился на секунду. Теперь Arch снова загрузился — и первое желание начать чинить всё подряд. Не спеши: сначала выясни, цела ли файловая система, потом — что упало в прошлой загрузке, потом — целы ли пакеты, и только после этого трогай систему.
Первый приоритет — дождаться загрузки до конца. Не перезагружайся, не жми волшебные комбинации, не запускай обновления. Дойди до входа в систему (или хотя бы до TTY: Ctrl+Alt+F2), и если получилось — логинься и дай системе минуту «подышать». Цель этого шага простая: понять, загружается ли система вообще и до какой стадии доходит.
Если экран остановился на каком-то сервисе — запомни, на каком. Если чёрный экран — переключись на TTY и посмотри, отвечает ли systemd. Если дошёл до логина — отлично, переходи к диагностике.
Пока ты не понял, что система стартует стабильно, ничего не переустанавливай и не перезаписывай: любая новая команда замазывает следы предыдущего сбоя. Порядок простой: загрузка → файловая система → логи прошлой загрузки → пакеты → ремонт.
Файловая система — фундамент. Если она поломана, логи врут, а проверка пакетов бессмысленна: pacman будет сверять контрольные суммы с искажённым диском.
На ext4/ext2 при каждой загрузке fsck запускается автоматически, если раздел отмечен как грязный (после сбоя питания — почти всегда). Формат вывода узнаваемый: строки вида /dev/sda1: clean, 123456/655360 files, 89012/2621440 blocks означают, что проверка прошла, а сообщения с FIXED или CLEAN — что fsck сам починил мелочи.
Если система загрузилась, но ты подозреваешь проблемы, проверь раздел руками. Смонтированный корень fsck не трогает — размонтируй его или грузись с live USB:
fsck -f /dev/sda1 # принудительная проверка с live USB или TTY
Флаг -f заставляет fsck проверить раздел полностью, даже если он выглядит чистым. На live USB это безопаснее: никакой записи в работающую систему.
Если система не загрузится совсем и дошла до приглашения root (continue) или emergency shell — тот же fsck -f с live USB, только на выключенный раздел. Для btrfs обычный fsck не подходит, используй:
btrfs check --readonly /dev/sda2 # только чтение, ничего не меняет
--readonly важен: btrfs check по умолчанию умеет перезаписывать структуры, а после сбоя хочется сначала посмотреть, а не чинить вслепую.
Файловая система цела — теперь выясняй, что упало. Ключевая команда — чтение журнала предыдущей загрузки:
journalctl -b -1 -p err
Флаг -b -1 означает «предыдущая загрузка», -p err — только ошибки и выше. Ты увидишь список сервисов и модулей, которые падали перед сбоем. Если ошибок мало, распользуй контекст:
journalctl -b -1 -n 50 # последние 50 строк прошлой загрузки
journalctl -b -1 --no-pager # весь лог без постраничной прокрутки
Вторая команда удобна, когда хочешь увидеть, чем всё закончилось: хвост журнала прямо перед выключением обычно содержит корневую причину. Фильтры и приоритеты подробно разобраны в статье про чтение journalctl после первой загрузки — там те же команды, но с акцентом на то, как их читать.
Дополни картину ядром:
dmesg | grep -iE 'error|fail|warn'
dmesg показывает кольцевой буфер текущей загрузки: сегфолты, ошибки дисков, обрывы USB. Если ядро паниковало, строки будут здесь, даже когда журнал systemd не успел записать ничего толкового.
Порядок чтения: сначала -p err (картина), потом -n 50 (хвост), потом dmesg (ядро). Не наоборот — иначе утонешь в строках.
Логи прочитаны, но подозреваешь, что пострадали именно файлы пакетов — например, обновление оборвалось на середине? Проверяй базу:
pacman -Qkk пакет # проверка одного пакета
pacman -Qkk # проверка всех сразу (долго)
Важно различать два исхода. Если pacman жалуется на базу (local database ... is corrupt или пропал каталог /var/lib/pacman/local/<пакет>), то эталонов для сравнения нет, и проверка файлов бессмысленна: сначала чини базу. Если база цела, а расхождения только в файлах (missing, checksum mismatch) — это ровно тот случай, когда переустановка спасает. Механика проверки и формат вывода разобраны в статье про целостность pacman -Qkk.
Смотри на первые строки вывода: 0 errors у пакета — всё в порядке; любая строка warning с перечнем файлов — список кандидатов на восстановление.
Система не доходит до логина, а экран завис на «Starting initramfs» или молча замирает? В меню GRUB выбери fallback-запись ядра — она обычно идёт следом за основной и называется вроде «Advanced options for Arch Linux» → ядро с пометкой (fallback initramfs).
Fallback-образ собирается без оптимизаций: в него входят все модули, включая те, которые основной образ мог не подхватить после обновления. Если проблема в драйвере диска или контроллера, fallback часто доезжает до системы там, где основной — нет.
Загрузился с fallback? Значит, виноват initramfs, а не ядро и не корень. Частая причина — образ собран под другую версию ядра: как это проверить и починить через mkinitcpio -P, рассказано в статье про initramfs, собранный с другим ядром. Не загрузился даже fallback — переходи к live USB, на этом этапе домашние методы исчерпаны.
А вот если меню GRUB пропало совсем, уже другая история — там чинят сам загрузчик, а не файловую систему или пакеты.
Пора чинить, но что именно? Переустановка pacman -S пакет перезаписывает все файлы пакета из зеркала — это ответ, когда:
pacman -Qkk показал missing или checksum mismatch у конкретного пакета;pacman -S пакет без -Syu не трогает остальную систему — перезаписывает только указанный пакет. Этого достаточно в большинстве случаев после файловых повреждений.
Чего переустановка не лечит: сломанные конфиги в /etc (pacman предупредит о backup-файлах), поломки после обновления зависимостей (нужен откат версии) и проблемы самой файловой системы (это шаг с fsck). Если после pacman -S ошибка осталась — возвращайся к логам, а не повторяй команду.
Финальный рубеж. Переходи к chroot, когда:
Порядок действий: грузишься с установочного ISO, монтируешь разделы в /mnt, заходишь через arch-chroot и уже оттуда запускаешь те же проверки — fsck, journalctl -D, pacman -Qkk. Полный алгоритм восстановления, включая откаты и снапшоты, есть в статье про алгоритм первой помощи после обновления, а сама процедура chroot описана в ArchWiki. Не затягивай с этим шагом: chroot — не экстрим, а обычная мастерская, и чем раньше ты туда перейдёшь, тем меньше дообрабатываешь следствия.
Да, если вывод показал clean без ошибок. Автоматический fsck запускается только на грязных разделах; после следующей «чистой» перезагрузки он снова не понадобится. Подозрение осталось? Прогони fsck -f вручную с live USB для спокойствия.
Журнал предыдущей загрузки бывает пуст: логи живут только в оперативной памяти (/var/log/journal отсутствует) и очищаются при старте. Создай каталог и перезапусти journald — но это уже после ремонта. Пока используй dmesg и вывод на экране.
Нет, это похоже на повреждение самой базы /var/lib/pacman/local, а не файлов. Не пытайся переустанавливать сотни пакетов: сначала восстанови базу (тот же chroot с live USB), потом повторяй проверку.
Ошибки в readonly-режиме означают, что повреждения реальны. Дальше — либо снапшот (если есть рабочий), либо btrfs check без флага на выключенном разделе, либо восстановление из резервной копии. Не запускай запись, пока не сделан бэкап того, что ещё читается.
fsck -f, для btrfs — btrfs check --readonly). 3. Прочитать прошлую загрузку (journalctl -b -1 -p err). 4. Проверить пакеты (pacman -Qkk). 5. Только потом чинить: переустановка, mkinitcpio, chroot.Первая загрузка после сбоя — не время для экспериментов, а время для последовательности: файловая система, логи прошлой загрузки, пакеты, и только потом ремонт. fsck -f отвечает на вопрос «цел ли диск», journalctl -b -1 -p err — на вопрос «что упало», pacman -Qkk — на вопрос «целы ли файлы». Освой этот порядок — и после любого сбоя ты будешь действовать за минуты, а не методом тыка в темноте.
Задай вопрос в чате — отвечаем быстро, по делу и без воды.
Комментарии