B.A.T.M.A.N.-adv und andere Kernel-Bestandteile mit Crashkernel und Kerneldumps unter Debian debuggen


#1

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).


Fun with Debian: Installing and enabling Kdump on Debian (wheezy) linux-image-3.2.0-4-686
Debian - Kdump - Documentation - Incloudus - Wiki
http://www.thegeekstuff.com/2014/05/kdump/

(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)
[…]


(:skull_and_crossbones:)

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.


Aktueller Stand Supernodes und L2TP
10000 Threads im Freifunk-Forum
Stand der Dinge KW2016/01
#2

ich bin jetzt aus Zeitgründen zu Faul das Debugging zu beschreiben. Dies haben aber schon andere Menschen zuvor besser gemacht. Deshalb gibt es hier die weiterführenden Links zur Analyse des zuvor erstellten Speicherabbilds:

ist IMHO die beste Anleitung, die ich fand … aber auf Französisch geschrieben

deshalb noch einige auf Englisch:


#3

Vielen Dank für die ausführliche Beschreibung. Was Kernel Debugging angeht tastete ich bis vor Kurzem noch im Dunkeln, kann das aber auch gut für andere Projekte brauchen (Android Kernels haben (noch) kein batman etc!)
Willst du ein Wiki daraus machen?

Ich mache hier mal meine Notizen zu der Anleitung:

Benutzte Kernelparameter:

  • crashkernel=128M
  • nosmp
  • maxcpus=0

/etc/default/kdump-tools (!)Debian

USE_KDUMP=1
DUMP_CMDLINE_APPEND=??

https://wiki.archlinux.org/index.php/Kdump


#4

Danke für die tolle Anleitung! Frage: Was genau macht der Parameter maxcpus=0?

Hast du mit dem System schon ein paar Batman 15 auf Mehrkernsystemen Paniken eingefangen?

Grüße
Matthias


#5

https://www.open-mesh.org/issues/223
(suche “SMP”)


#6

irgendwann™

Zitat aus linux/Documentation/kernel-parameters.txt:

 maxcpus=    [SMP] Maximum number of processors that    an SMP kernel
             should make use of.  maxcpus=n : n >= 0 limits the
             kernel to using 'n' processors.  n=0 is a special case,
             it is equivalent to "nosmp", which also disables
             the IO APIC.
 nosmp       [SMP] Tells an SMP kernel to act as a UP kernel,
             and disable the IO APIC.  legacy for "maxcpus=0".

Ja, diese lassen sich aber nicht debuggen, da die Kernel-Panik auf mehreren Prozessoren entstanden ist.


#7

Ah okay, danke. Ich kannte den Begriff SMP noch gar nicht, gerade mal kurz gegooglet. Hab gerade den Link gelesen. Das sieht ja echt vielversprechend aus!

Tritt der Fehler denn bei einem Kern nur seltener oder überhaupt nicht auf? Wir haben bisher nur sehr kleine Bat15-Domänen, daher kann ich das selbst noch nicht beurteilen. Es scheint ja auf jeden Fall eine Korrelation zur Anzahl der direkt verbundenen Clients zu geben.

Grüße
Matthias


#8

Es geht hier Thread um die Analyse eines Fehlers und nicht um einen konkreten Fehler … also nur ganz kurz: es gibt, so weit ich es überblicke, mehr als eine Ursache, warum Batman den Server ins Nirvana zieht: die mir bekannten: Schnittstelle mit if del entfernen, mehrere Schnittstellen mit gleicher oder unterschiedlicher MTU mit und ohne SMP … Bitte dazu einen bestehenden Thread verwenden oder einen neuen eröffnen. In Dom. Wupper fahre ich nur eine Schnittstelle pro Broadcast-Domäne, keine Bridge … es gibt keine Abstürze mit bat15. Die angesprochenen Fehler kann ich reproduzierbar hervorrufen. Mir fehlt aber derzeit die Zeit dazu.