Все об Arch Linux
Arch Linux будет тем, что вы из него сделаете!
Все об Arch Linux
Arch Linux будет тем, что вы из него сделаете!
Сразу к делу: второе ядро для отладки — это рабочий инструмент, а не роскошь. Поставь linux-lts рядом с основным ядром: оно даёт читаемые символы для perf, а через kdump и crash превращает панику в разбор полётов. Стоковые ядра Arch собираются без полной отладочной информации, поэтому трассы получаются «слепыми», а отдельное ядро решает эту проблему без пересборки системы.
Стоковое ядро Arch (linux) собирается с урезанными отладочными символами. CONFIG_DEBUG_INFO в нём не включён полностью, поэтому perf report показывает имена функций ядра лишь частично, а crash не может разобрать дамп без подходящего vmlinux. Отсюда идея: держать рядом второе ядро с отладочной информацией и загружаться в него, когда нужно профилировать или ловить панику.
Что дают отладочные символы на практике? Вместо голых адресов в трассах ты видишь имена функций, номера строк и локальные переменные. Для perf это разница между «горячая точка по адресу 0xffffffff81001234» и «горячая точка в ext4_do_update_inode». Для crash без символов разбор дампа почти невозможен: утилита не понимает, где в памяти лежат структуры ядра.
Когда это реально нужно? Три типовых сценария. Первый: система периодически зависает, и ты хочешь понять, какая подсистема виновата — perf top на втором ядре покажет горячие функции без пересборки. Второй: ядро падает в панику, и нужен дамп для разбора — тут без kdump и crash не обойтись. Третий: свежее обновление ядра сломало загрузку, а работать надо прямо сейчас — LTS поднимает систему за минуту.
Практичный вариант — linux-lts. Он ставится рядом с основным ядром и работает как безопасное запасное: если свежее ядро не загрузилось, выбираешь LTS в меню GRUB и продолжаешь работать. Подробнее про выбор — в статье «Какое ядро выбрать: linux, linux-lts, zen или hardened».
Второй вариант — собрать своё ядро с CONFIG_DEBUG_INFO=y. Это даёт полные символы и для perf, и для crash. Процесс описан в статье «Сборка своего ядра за 5 шагов».
pacman -S linux-lts linux-lts-headers
mkinitcpio -P
grub-mkconfig -o /boot/grub/grub.cfg
mkinitcpio -P пересобирает initramfs для всех установленных ядер, а grub-mkconfig добавляет новые пункты в меню загрузчика. После этого в меню GRUB появляются оба ядра. Как различать их в меню, разобрано в статье «Несколько ядер в меню: linux, linux-lts, hardened».
Для отладки загружайся в LTS с подробным выводом. Убери quiet из параметров ядра:
# /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="loglevel=7"
grub-mkconfig -o /boot/grub/grub.cfg
Теперь ядро печатает все сообщения в консоль — видно, где что тормозит или падает. Если система не загружается вовсе, добавь к параметрам systemd.unit=emergency.target — попадёшь в аварийный режим для ремонта. В нём поднят только корень, сеть и пользовательские сервисы не запускаются, зато можно чинить fstab, пересобирать initramfs и откатывать пакеты.
perf ставится одной командой:
pacman -S perf
Быстрый замер производительности:
perf stat ls -R /usr
Покажет количество инструкций, промахи кэша, время выполнения. Для более детальной картины добавь -d — появятся счётчики кэша и ветвлений:
perf stat -d ls -R /usr
Для профилирования с деревом вызовов:
perf record -g ./my-program
perf report
perf record -g записывает стек вызовов, perf report показывает интерактивный отчёт: какие функции съедают больше всего времени. Частотную выборку задаёт -F:
perf record -F 99 -g ./my-program
Живой мониторинг — perf top, работает как top, но по функциям ядра и процессов:
perf top
Список доступных событий покажет perf list — там и аппаратные счётчики (промахи кэша, ветвления), и программные (переключения контекста, page faults). Если профилируешь конкретный процесс, добавь -p с PID — perf будет следить только за ним, а не за всей системой.
Нюанс: символы ядра в /proc/kallsyms скрыты. Либо запускай perf от root, либо разреши чтение указателей:
sysctl kernel.kptr_restrict=0
Без этого отчёт по ядру будет с адресами вместо имён функций.
kdump работает так: при панике основное ядро не умирает молча, а загружает маленькое запасное ядро, которое сбрасывает память в файл vmcore. Потом этот дамп разбираешь через crash.
Установка и настройка:
pacman -S kexec-tools
systemctl enable kdump.service
В параметры ядра добавь crashkernel=256M — резерв памяти под crash-ядро:
# /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="crashkernel=256M"
grub-mkconfig -o /boot/grub/grub.cfg
reboot
Проверь, что резерв выделен:
cat /proc/iomem | grep Crash
Строка Crash kernel в выводе — значит, резерв на месте. При панике crash-ядро загрузится и запишет дамп в /var/crash. Размер резерва подбирай под объём памяти: для 8 ГБ хватает crashkernel=256M, для машин с большим количеством RAM можно поставить 512M. Проверить механизм без реальной аварии можно принудительной паникой:
echo c > /proc/sysrq-trigger
Система упадёт, kdump отработает, и в /var/crash появится vmcore. Это безопасный тест: после него просто перезагружаешься. Размер дампа зависит от объёма памяти — на машине с 16 ГБ vmcore займёт несколько гигабайт, так что следи за свободным местом на диске.
pacman -S crash
crash работает в паре: файл ядра с символами + дамп памяти.
crash /usr/lib/modules/$(uname -r)/vmlinuz /var/crash/.../vmcore
Тут нюанс: vmlinuz из пакета содержит урезанную таблицу символов. Для полного разбора нужен vmlinux из сборки ядра с CONFIG_DEBUG_INFO=y — то самое своё ядро из статьи про сборку. Стокового vmlinuz хватит для базовых команд вроде bt, но имена функций будут неполными.
Внутри crash полезны команды:
bt — стек вызовов на момент паники;log — последние сообщения ядра;ps — список процессов;files — открытые файлы процесса;mod — загруженные модули;dis — дизассемблирование по адресу.Полный цикл выглядит так: паника → kdump пишет vmcore → crash vmlinux vmcore разбирает дамп. Версия ядра в vmlinux должна точно совпадать с той, что упала, иначе crash откажется работать.
Если ядро не падает, а просто висит — на помощь приходит magic SysRq. Это комбинации Alt+SysRq+<клавиша>, которые ядро обрабатывает даже в зависшем состоянии. Классическая последовательность REISUB:
R — вернуть клавиатуру из raw-режима;E — убить все процессы, кроме init;I — убить все процессы;S — синхронизировать диски;U — перемонтировать всё в read-only;B — перезагрузиться.На ноутбуке SysRq часто совмещён с Print Screen. Если комбинации не работают, проверь:
cat /proc/sys/kernel/sysrq
Значение 1 — разрешены все функции, 0 — всё выключено. Промежуточные значения включают отдельные группы: 2 — управление процессами, 4 — синхронизация дисков, 8 — размонтирование, 16 — перезагрузка. Управлять можно и без клавиатуры, через файл:
echo s > /proc/sysrq-trigger # синхронизация дисков
echo b > /proc/sysrq-trigger # перезагрузка
echo c > /proc/sysrq-trigger # принудительная паника (тест kdump)
Для виртуальных машин полезно вывести консоль ядра на последовательный порт — тогда сообщения паники не потеряются:
# /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="console=ttyS0,115200"
В QEMU вывод смотри через -serial stdio, в libvirt — через virsh console. Так ты увидишь последние строки ядра перед паникой, даже если экран уже мёртв.
Да. Даже без разработки оно полезно: LTS как запасной вариант при неудачном обновлении и как «чистый» инструмент для perf и kdump. Один пакет — и есть и страховка, и отладочная среда.
Запусти perf от root или поставь kernel.kptr_restrict=0. Для полных имён функций ядра загружайся во второе ядро с отладочными символами.
Проверь, что crashkernel=256M реально в параметрах загрузки (cat /proc/cmdline), что kdump.service активен и что в /proc/iomem есть резерв Crash kernel. После изменения параметров не забудь grub-mkconfig и перезагрузку.
gdb работает с обычным процессом, crash — с дампом памяти ядра. crash понимает структуры ядра: списки процессов, модули, стеки. Для анализа паники он удобнее.
Ядра копятся в /boot и занимают место. Раз в пару месяцев удаляй неиспользуемые — как это сделать, описано в статье «Чистка старых ядер и initramfs».
Второе ядро — это страховка и инструмент одновременно. linux-lts рядом с основным ядром даёт запасной вариант загрузки и читаемые символы для perf. kdump с crashkernel=256M превращает панику в файл vmcore, который разбирается через crash. А magic SysRq позволяет сохранить работу и перезагрузиться, даже когда система висит. Поставь linux-lts, настрой crashkernel, проверь echo c > /proc/sysrq-trigger — и следующая авария станет учебным примером, а не головной болью.
Задай вопрос в чате — отвечаем быстро, по делу и без воды.
Комментарии