После обновления что-то сломалось, а когда именно — уже не помнишь? pacman ведёт собственный журнал: /var/log/pacman.log, простой текстовый файл, куда попадает каждая установка, обновление и удаление с точным временем. Разберись с его форматом один раз — и всегда сможешь ответить, что изменилось вчера вечером и какой пакет свалил систему.
Файл один: /var/log/pacman.log. pacman пишет в него с первого дня существования системы и не перестаёт никогда. Каждая транзакция — от pacman -Syu до установки пакета из AUR хелпером — оставляет там строку с датой, действием, именем пакета и версиями.
Читать его стоит по трём причинам.
Первая — расследование поломки. Система работала утром, а вечером после обновления хватила глючить. Лог покажет, что именно изменилось между этими двумя моментами.
Вторая — простой вопрос «когда». Когда обновлялось ядро? Когда ставился этот пакет? Когда кто-то удалил ту утилиту? Ответ лежит в логе, искать его нужно секунды.
Третья — осторожность перед откатом. Прежде чем возвращать старую версию, посмотри, когда она стояла и что менялось вокруг. Так откат не заденет ничего лишнего.
Куда pacman пишет остальное — базы, список установленных пакетов, кэш — разобрано в статье «Базы pacman: где лежат». Лог обновлений живёт отдельно от них и не зависит от состояния баз.
Вот реальная строка из лога:
2026-09-20 12:34:56 [ALPM] upgraded linux (6.12.9.arch1-1 -> 6.12.10.arch1-1)
Разбираем по полям.
2026-09-20 12:34:56, локальное время транзакции. Это и есть метка, по которой потом ищешь причину поломки.[ALPM], Arch Linux Package Management, ядро менеджера пакетов. Значит, запись сделана самим pacman, а не каким-то скриптом.upgraded. Бывает ещё installed (новый пакет), removed (удалён), downgraded (откат на старую версию), reinstalled (переустановка поверх).linux. Имя ровно такое, как в pacman -Ss.(6.12.9.arch1-1 -> 6.12.10.arch1-1), стрелка показывает переход: слева старая, справа новая. У installed левой версии нет, у removed — только левая.Не все строки одинаковые. [PACMAN] ставит оболочка: Running 'pacman -Syu', синхронизация баз, запуск транзакции. По таким записям видно, какая именно команда запускалась и когда началось обновление.
[ALPM-SCRIPTLET] — это вывод скриптов, которые pacman запускает после установки или удаления. Пересборка initramfs, перезагрузка юнитов systemd, обновление кеша шрифтов — всё это scriptlet’ы. Именно в них появляются ошибки вроде «failed to create initcpio image», которые в обычных строках [ALPM] не видно. Если обновление «прошло успешно», а внутри скрипт упал — ищи вон в этих строках.
Простейший способ — вытащить из лога строки с сегодняшней датой:
grep "$(date +%Y-%m-%d)" /var/log/pacman.log
Команда подставит текущую дату в формате 2026-09-23 и покажет всё, что произошло в этот день. Для вчерашнего дня замени подстановку на date -d yesterday +%Y-%m-%d.
Если интересуют только повышения версий, отфильтруй по действию:
grep 'upgraded' /var/log/pacman.log
А чтобы просто взглянуть, что происходило последним, хватит хвоста файла:
tail -n 50 /var/log/pacman.log
Пятьдесят последних строк обычно покрывают несколько последних запусков pacman — ровно то, что нужно перед разбором свежей поломки.
Задай имя пакета как шаблон grep:
grep 'linux' /var/log/pacman.log
В выводе будут все события с этим словом: установки, обновления, удаления — с датами. Если строк слишком много и имя пакета совпадает с лишним (например, linux встречается в linux-firmware), сузь поиск действием:
grep 'upgraded.*linux ' /var/log/pacman.log
Тот же приём работает для любого пакета: grep 'upgraded.*firefox', grep 'removed.*virtualbox'. Другие удобные сочетания pacman и поиска по логам собраны в статье «Pacman от А до Я: команды».
Классическая схема расследования выглядит так. Система упала в 18:05. Значит, всё подозрительное — в окне от 17:30 до 18:05.
Открой лог и посмотри, что попало в это окно:
grep "2026-09-22 1[78]:" /var/log/pacman.log
Допустим, в 18:00 ты обновил mesa, а в 18:05 упала графическая сессия. Виноват mesa — остальные обновления в это окно не попадали. Дальше действуй по ситуации: перезагрузка, откат одного пакета по примерам из статьи «Откат одного пакета: примеры» или более широкие меры, если ломанулось многое сразу.
Обратный порядок тоже работает: сначала узнай точное время падения из journalctl -b, потом найди в pacman.log ближайшее обновление до него. Пока в логе пусто, а поломка есть — причина не в пакетах, и искать надо в конфигурациях и железе.
Это два журнала для двух разных задач, и путать их не стоит.
pacman.log отвечает только на вопрос «что и когда устанавливалось». Там нет ошибок служб, падений процессов и сообщений ядра — только транзакции пакетов.
journalctl отвечает на вопрос «что происходило в системе»: падения сервисов, ошибки ядра, действия пользователя, тайминги загрузки. Но он не знает, какая версия библиотеки встала в 18:00.
Работают они в паре: journalctl показывает, что сломалось и когда, а pacman.log — что было обновлено в тот же момент. Подробный разбор второго журнала есть в статье «Как читать вывод journalctl при первой загрузке».
В большинстве систем файл открыт для чтения всем, так что cat /var/log/pacman.log или less /var/log/pacman.log работают без sudo. Если прав доступа отняли, добавь sudo перед командой.
Лог фиксирует только операции pacman. Компиляция через makepkg внутрь не попадает, но финальная установка через pacman -U записывается строкой [ALPM] installed ... с временем. Искать AUR-пакеты в логе можно точно так же, как обычные.
Можно: это обычный текстовый журнал, pacman работает и без него. Но тогда ты потеряешь историю обновлений — ту самую, по которой потом ищешь виновника поломки. Лучше лог редко трогать, а при желании ограничиться ротацией: скопируй старую версию в архив и начни новый файл.
Проверь дату командой date: возможно, смотришь не на тот день. Если файл действительно чист, кто-то его очищал — посмотри строки пораньше и убедись, что обновление вообще проходило через pacman, а не через другой хелпер.
Запусти sudo tail -f /var/log/pacman.log в одном терминале и запускай обновление в другом. Каждая транзакция будет появляться на экрану сразу после записи.
/var/log/pacman.log — это черный ящик твоей установки Arch: каждое обновление записано с датой, действием и версиями. Научись три вещи: читать формат строк, вырезать нужный день или пакет через grep и сопоставлять время транзакции со временем падения. С такими навыками разбор любой поломки после pacman -Syu превращается из гадания в десятиминутное расследование.
Задай вопрос в чате — отвечаем быстро, по делу и без воды.
Комментарии