LINUX.ORG.RU

kdump.service - Crash recovery kernel arming. Centos 7. Failed to start Crash recovery kernel arming.

 , , ,


0

1

При установке на железо ядрa 3.19.2-1.el7.elrepo.x86_64 система тихо виснит чёрным экраном, но на виртуалку данное ядро установилось без проблем, значит надо дампить.

systemctl start kdump.service
 journalctl -xn
-- Logs begin at Вс 2015-03-29 04:46:58 BDT, end at Вс 2015-03-29 16:30:41 BDT. --
мар 29 16:30:41 localhost.localdomain kdumpctl[12744]: No kdump initial ramdisk found.
мар 29 16:30:41 localhost.localdomain kdumpctl[12744]: Rebuilding /boot/initramfs-3.19.2-1.el7.elrepo.x86_64kdump.img
мар 29 16:30:41 localhost.localdomain kdumpctl[12744]: No dump target specified. Default dump target is rootfs block device.
мар 29 16:30:41 localhost.localdomain kdumpctl[12744]: But dump path /var/crash is not backed by rootfs block device.
мар 29 16:30:41 localhost.localdomain kdumpctl[12744]: Either explicitly specify a dump target or specify a dump path backed by rootfs block device
мар 29 16:30:41 localhost.localdomain kdumpctl[12744]: mkdumprd: failed to make kdump initrd
мар 29 16:30:41 localhost.localdomain kdumpctl[12744]: Starting kdump: [FAILED]
мар 29 16:30:41 localhost.localdomain systemd[1]: kdump.service: main process exited, code=exited, status=1/FAILURE
мар 29 16:30:41 localhost.localdomain systemd[1]: Failed to start Crash recovery kernel arming.

У многих видел [warn] при active kdump.service
No kdump initial ramdisk found.
В документации не нашёл где и как нужно прописать initial ramdisk.
cat /etc/default/grub
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="ipv6.disable=1 rd.lvm.lv=centos/swap crashkernel=auto  rd.lvm.lv=centos/usr vconsole.font=latarcyrheb-sun16 vconsole.keymap=ru rd.lvm.lv=centos/root rhgb quiet"
GRUB_DISABLE_RECOVERY="true"

crashkernel=auto или указать вручную, как рекомендуют, не играет роли.
Памяти 32G думаю должно хватить для crashkernel=auto
No dump target specified. Default dump target is rootfs block device.
Вполне устраивает запись в /var/crash и не нужды в target specified
/etc/kdump.conf прописано

path /var/crash
core_collector makedumpfile -l --message-level 1 -d 31

P.S. Настройки в соответствии https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html...


/var на отдельном разделе? Каталог для кдампов должен быть на корневой ФС.

mv ★★★★★
()

kdump/kexec вещь хорошая, но ramoops для тах целей IMHO более подходящее решение. В местной wiki есть рецепты.

vel ★★★★★
()

crashkernel=auto или указать вручную, как рекомендуют, не играет роли.

Ванильные ядра не понимают «crashkernel=auto». Нужно указывать конкретный размер, например «crashkernel=128M».

Deleted
()

И кстати, это не имеет прямого отношения к kdump, но: попробуй поставить ядро от федоры или пересобрать пакет с elrepo с конфигом ядра от федоры. В elrepo конфиги ядер какие-то кривоватые ИМХО. Я как раз в конце прошлой недели столкнулся с тем, что на системе с двумя 10G сетевыми интерфейсами (be2net) под CentOS 7 после перехода со штатного ядра на ядро с elrepo, общая пропускная способность интерфейсов в обе стороны упала с ~35 гбит/с до ~15 гбит/с. И после пересборки ядра с конфигом от федоры всё снова стало нормально.

P.S. Дифф между конфигами там был довольно большой, а времени и желания ковыряться у меня не было, так что конкретная причина вот этого эффекта мне до сих пор неизвестна.

Deleted
()
Ответ на: комментарий от mv

ну не знаю. Т.к. регулярно приходится ковырятся в сетевом стеке ядра, oops или крахи ядра - норма жизни. ramoops - наиболее простой способ получить последние сообщения ядра. А kdump нужен любителям поковырять дебагером в корку ядра. А оно нам надо ?

Против некоторых мертвых зависаний не поможет ни ramoops, ни kdump/kexec.

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

vel ★★★★★
()
Ответ на: комментарий от mv

Вообще ни разу не альтернатива kdump'у.

Слова не мальчика, но мужа!

anonymous
()
Ответ на: комментарий от vel

То есть, ты сетевой стек исключительно отладочный выводом дебажишь? Может таки потратить немного времени н научиться kdump'у и отладчику?

anonymous
()
Ответ на: комментарий от anonymous

При чем тут дебаг отладочным выводом?

Речь шла о том, как получить инфу о креше ядра. Я рассказал о том, что примерно 3 года назад появился новый, более простой способ сохранения информации о креше ядра.

Если действительно что-то нужно отлаживать, то для этого есть qemu/kvm.

vel ★★★★★
()
Ответ на: комментарий от vel

Если ты действительно ковыряешься, то от голого бэктрейса толку чуть. Ну оно лучше, чем совсем ничего, но корку глянуть гораздо больше информации даёт.

mv ★★★★★
()
Ответ на: комментарий от mv

/var на отдельном разделе? Каталог для кдампов должен быть на корневой ФС.

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

ISV
() автор топика
Ответ на: комментарий от Deleted

пересобрал 3.19.2-1.el7.elrepo.x86_64 вручную

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

ISV
() автор топика
Ответ на: комментарий от Deleted

Нужно указывать конкретный размер, например «crashkernel=128M».

Я читал такие рекомендации, но ни одним месаджем не заметил, что «crashkernel=auto» не работает.

ISV
() автор топика
Ответ на: комментарий от ISV

Я читал такие рекомендации, но ни одним месаджем не заметил, что «crashkernel=auto» не работает.

Ядро в dmesg должно писать что-то на эту тему.

Deleted
()
Ответ на: комментарий от Deleted

Ядро в dmesg должно писать что-то на эту тему.

Сообщения dmesg попадают в системный журнал через демон журналирования, пересмотрел, ничего не нашёл. Первым делом в dmesg попадают сообщения о загрузке ядра ОС в память, уровень детализации --kernel есть.

ISV
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.