Hallo zusammen,
In der Hoffnung die Batman-Entwicklung durch Batman-Nutzung voranzutreiben erkläre ich hier, wie man Nach einer Kernel-Panik die Ursache dafür aufzeichnet und dies den Entwicklern mitteilt. Dadurch können Fehler, die nicht bei der Entwicklung bedacht oder falsch implementiert wurden beseitigt werden, da sie offensichtlich nur in der freien Wildbahn auftreten und nicht im Labor.
Ich bin nicht vom Fach – ich habe mein Wissen aus diesen und anderen (die mir jetzt nicht einfallen) Links abgeleitet und schreibe hier eine Anleitung nach „Linux from Scratch“ Art für Debian. Nachdem man verstanden hat, worum es geht, kann man dies auch für andere Distributionen anwenden. Bei Gentoo kann ich noch auf Wunsch aushelfen, bei Arch steht es dort im Wiki …
zum Diskutieren sind die einzelnen Abschnitte nummeriert (X).
http://funwithdebian.blogspot.de/2014/05/using-kdump-on-debian-wheezy-linux.html
http://wiki.incloudus.com/display/DOC/Debian+-+Kdump
How to use kdump for Linux Kernel Crash Analysis
(1)
zuerst einen aktuellen Kernel besorgen, wenn man der Meinung ist, der verwendete Kernel sei zu alt.
In sources.list eintragen
echo "
# jessie-backports
deb http://ftp.debian.org/debian/ jessie-backports main
deb-src http://ftp.de.debian.org/debian/ jessie-backports main" >> /etc/apt/sources.list
und installieren (hier gleichzeitig mit kdump-tools):
apt-get update
apt-get -y install kdump-tools linux-image-4.2.0-0.bpo.1-amd64 linux-image-4.2.0-0.bpo.1-amd64-dbg
update-rc.d kdump-tools enable
für einen debug-Kernel werden um die 2,3 GiB Festplattenspeicher benötigt. Man kann auch auf einer anderen Mashine debuggen, dann lautet die Installation nur
apt-get -y install kdump-tools linux-image-4.2.0-0.bpo.1-amd64
(2)
kexec bearbeiten:
sed -i /etc/default/kexec -e "s@^USE_GRUB_CONFIG=@USE_GRUB_CONFIG=true@g"
dies deshalb, weil bei mir die folgenden Einträge gar nicht greifen … sollen sie greifen, muss da false stehen:
sed -i /etc/default/kexec -e "s@^USE_GRUB_CONFIG=@USE_GRUB_CONFIG=false@g"
mit nosmp booten die Maschinen bei einigen Hostern nicht, dennoch irgendetwas hiervon versuchen (nur eins davon):
sed -i /etc/default/kexec -e "s@^APPEND=\".*\"@APPEND=\"crashkernel=128M\"@g"
sed -i /etc/default/kexec -e "s@^APPEND=\".*\"@APPEND=\"crashkernel=128M nosmp\"@g"
sed -i /etc/default/kexec -e "s@^APPEND=\".*\"@APPEND=\"crashkernel=128M nosmp maxcpus=0\"@g"
sed -i /etc/default/kexec -e "s@^APPEND=\".*\"@APPEND=\"crashkernel=128M maxcpus=0\"@g"
ansonsten muss man selbst einen nicht-SMP-Kernel bauen … sprengt hier den Rahmen
dies wird aber gleich direkt in Grub2 implementiert – kann man sich eigentlich sparen, ist hier nur der Vollständigkeit halber. Um noch ein mal zu entwirren: ich arbeite hier mit der Grub2 und nicht mit der Commandline von kexec, deshalb nur
sed -i /etc/default/kexec -e "s@^USE_GRUB_CONFIG=@USE_GRUB_CONFIG=true@g"
(3)
kdump-tools bearbeiten und einschalten:
sed -i /etc/default/kdump-tools -e "s@^USE_KDUMP=.*@USE_KDUMP=1@g"
(4)
Soll Grub2 doch alles machen: irgendeines aus diesen Befehlen:
sed -i /etc/default/grub -e "s@^GRUB_CMDLINE_LINUX_DEFAULT.*@GRUB_CMDLINE_LINUX_DEFAULT=\"crashkernel=128M\"@g"
sed -i /etc/default/grub -e "s@^GRUB_CMDLINE_LINUX_DEFAULT.*@GRUB_CMDLINE_LINUX_DEFAULT=\"crashkernel=128M maxcpus=0\"@g"
sed -i /etc/default/grub -e "s@^GRUB_CMDLINE_LINUX_DEFAULT.*@GRUB_CMDLINE_LINUX_DEFAULT=\"crashkernel=128M maxcpus=0 nosmp\"@g"
sed -i /etc/default/grub -e "s@^GRUB_CMDLINE_LINUX_DEFAULT.*@GRUB_CMDLINE_LINUX_DEFAULT=\"crashkernel=128M nosmp\"@g"
(5)
grub2 dank der Schritte (1) und (4) aktualisieren:
update-grub
(6)
alles noch mal gegen checken
grep KDUMP_COMMANDLINE_APPEND /etc/default/kdump-tools
grep DUMP_CMDLINE_APPEND /etc/default/kdump-tools
grep USE_KDUMP /etc/default/kdump-tools
grep ^GRUB_CMDLINE_LINUX_DEFAULT /etc/default/grub
einschalten
update-rc.d kdump-tools enable
und neu starten
reboot & exit
(7)
die Einstellungen zuvor sollten nach dem Neustart sichtbar sein:
cat /sys/kernel/kexec_crash_loaded
muss 1 ausgeben
cat /proc/cmdline
sollte crashkernel=128M und einige oder keine SMP Kernel-Befehle aufweisen
es „fehlen“ 128 MiB RAM für den Carsh-Kernel
free -m
Kdump sollte laufen
service kdump-tools status
[…]
Active: active (exited)
[…]
(
)
eine Kernel-Panik provozieren und überprüfen, ob das System diese Korrekt aufzeichnet und anschließend neu startet:
Festplatte halbwegs sichern und retten:
sync
finstere Magie anwenden
echo 1 > /proc/sys/kernel/sysrq
echo c > /proc/sysrq-trigger
Das System startet den Crashkernel und sichert den Inhalt des RAMs und dmesg in Dateien, die in /var/crash/ abgespeichert werden. Danach startet es normal neu.
Das Debugging beschreibe ich später™ (oder jemand anderes tut es). Nur so viel: niemandem den Kerneldump geben – da sind Passwörter und $Zeug drin. Bis dahin kann man die Dumps erst ein mal bei sich horten.