Все об Arch Linux
Arch Linux будет тем, что вы из него сделаете!
Все об Arch Linux
Arch Linux будет тем, что вы из него сделаете!
Пять шагов: собираю данные из journalctl, строю гипотезу с дискриминационной проверкой, ищу корневую причину, применяю минимальный фикс и закрепляю результат в журнале решений. Система отработана на десятках реальных случаев, и ниже разбираю каждый шаг с конкретными примерами.
Гугл выдаёт десятки одинаковых советов: «перезагрузи», «переставь пакет», «попробуй другой DE». Среди них два-три релевантных, но отличить мусор от решения без системы невозможно. Тратишь часы, меняешь конфиги наугад и ломаешь то, что работало.
Метод сужает пространство поиска. Каждый шаг даёт ответ на конкретный вопрос, и на следующий переходишь с данными, а не с догадкой.
journalctl -b покажет все сообщения текущей загрузки. Проблема случилась после ребута два дня назад? Список последних загрузок:
journalctl --list-boots --no-pager | tail -4
Каждая строка — это загрузка с датой и индексом. Выбираешь нужную и смотришь:
journalctl -b -1 --no-pager
Дальше фильтруешь по имени сервиса или устройства. Сетевая проблема:
journalctl -b -1 | grep -iE 'enp42s0|r8169|NetworkManager'
Bluetooth:
journalctl -b -1 | grep -iE 'bluetooth|wireplumber|pipewire'
Ключевое: ты ищешь события, а не подтверждаешь свою теорию. В логах виновника нет? Гипотеза неверна, пора строить другую. О формате логов и фильтрации подробнее рассказано в ArchWiki: Systemd/Journal.
Дискриминационный тест — команда, которая отличает одну гипотезу от другой. Не «попробуй перезагрузить», а конкретная проверка, которая покажет: причина здесь, а не там.
Пример 1. yay падает с EOF, но сайты открываются. Первый инстинкт: сеть не работает. Проверка:
curl -s -o /dev/null -w "%{speed_download}" --max-time 10 \
"https://speed.cloudflare.com/__down?bytes=80000000"
Нормальная скорость? Сеть в порядке. Проблема в самом приложении: Go-резолвер yay ставит IPv6 выше IPv4, а IPv6-маршрута нет → EOF без фолбэка. Сайты через curl работают, потому что он пробует оба стека. Подробнее — разбор yay и EOF на фоне IPv6.
Пример 2. Проводное подключение «плавает», сайты открываются медленно. Curl к speed.cloudflare.com тоже не выдаёт максимум. Причина не в браузере и не в DNS — проблема на физическом уровне.
Вот суть дискриминационного теста: обходишь подозреваемого виновника и проверяешь среду. Среда в порядке — дело в компоненте. Среда сломана — ищи причину глубже.
Самая частая ошибка: лечить симптом, не докопавшись до корня. Вот три реальных кейса.
Realtek дауншифт до 100 Мбит. Команда journalctl -b -1 | grep downshift выдаёт Link is Up - 100Mbps/Full (downshifted). Ядро пишет check cabling!. Кабель Cat5 с деградировавшими парами. Гигабиту нужны все 4 пары, при плохом контакте PHY дауншифтится до 100M на двух парах. Замена патч-корда за пять минут решает то, что выглядело программной проблемой. Разбор — Realtek и downshift.
Yay и IPv6. yay -Syu падает с EOF. Причина не в pacman и не в зеркалах. Go-резолвер в yay при отсутствии явного приоритета в /etc/gai.conf ставит IPv6 выше IPv4. Маршрута IPv6 нет, коннект таймаутится без фолбэка. Одна строка:
echo 'precedence ::ffff:0:0/96 100' | sudo tee -a /etc/gai.conf
Bluetooth-колонка замолкает после сна. Авто-подключение не помогает. WirePlumber при уходе в suspend ставит bluetooth-устройство в спящий профиль и не будит обратно. Конфиг WirePlumber с отключением suspend для bluetooth-узлов + перезапуск стека:
systemctl --user restart wireplumber pipewire pipewire-pulse
Подробнее — Bluetooth и WirePlumber.
Во всех трёх случаях симптом выглядел как программная проблема. Корневая причина оказалась на другом уровне: физика кабеля, логика резолвера, политика suspend в PipeWire. О работе PipeWire — ArchWiki: PipeWire.
Меняем одно. Не три конфига и не пять сервисов. Одно действие, потом проверка:
ping -c2 8.8.8.8 # сеть жива?
systemctl is-active <сервис> # сервис поднялся?
journalctl -b --no-pager | tail -20 # свежих ошибок нет?
После замены кабеля Realtek проверка: nmcli -f DEVICE,STATE device показывает connected вместо бесконечного цикла connecting/disconnected. После правки gai.conf:
getent ahosts aur.archlinux.org | head -3 # первой строкой IPv4
yay -Syu
Минимальный фикс даёт понимание: что именно решило проблему. И проще откатить, если пошло не так.
Фикс работает? Перезагрузись. Серьёзно. Проблемы с bluetooth и звуком часто проявляются только после полного цикла питания. Проверь, что после ребута всё ещё на месте.
Записывай результат в журнал решений. Формат простой:
Дата → симптом → корневая причина → решение → нюансы
Пример:
2026-09-10 → yay EOF при обновлении AUR → Go-резолвер IPv6 без фолбэка → precedence в gai.conf → ждать рабочего IPv6, строку убрать
Журнал не для красоты. Через три месяца ты за секунды найдёшь старое решение. Компьютером пользуешься не один? Журнал превращается в базу знаний.
journalctl не показывает ошибок, но проблема есть. Что делать?
Проверь, что смотришь правильную загрузку (--list-boots), и фильтруй по конкретному сервису. Ошибки драйвера попадают в ядерный буфер: journalctl -b -k.
Как понять, что проблема аппаратная, а не программная?
Дискриминационный тест: обходи подозреваемого виновника. curl к тестовому серверу работает медленно — проблема не в браузере. Другой кабель решает дело — виновата физика.
Что писать в журнал решений, если решение временное? Отмечай: «временное, ожидается обновление драйвера». Состояние «временно» через полгода без пометки превращается в забытую проблему.
Какой формат журнала самый практичный?
Одна строка на случай: дата | симптом | корневая причина | решение | нюансы. Файл в корне системы или в ~/.config/. Кто решает проблемы регулярно, оценит.
Пять шагов: собрал данные, построил гипотезу, нашёл корень, минимальный фикс, закрепил. Пропускать шаги — ловить баги, которые повторятся.
Самый ценный элемент — журнал решений. Он превращает случайные поиски в накопленный опыт. Через полгода ты вернёшься к записи «yay EOF + IPv6» и за минуту вспомнишь решение вместо двух часов заново.
Задай вопрос в чате — отвечаем быстро, по делу и без воды.
Комментарии