Kernel Panic – Fallback mit Lilo und im System

Wer kennt das nicht: Man will einen neuen Kernel nutzen, hat aber Angst, dass man seinen Server, der im Rechenzentrum in Frankfurt steht, abschiesst.

Beim bootloader lilo kann man sich eine Hintertür aufhalten:

/etc/lilo.conf
..
default=Linux
image=/boot/vmlinuz-2.6.18-6-686-bigmem
label=Linux
initrd=/boot/initrd.img-2.6.18-6-686-bigmem
image=/boot/vmlinuz-2.6.26-1-686-bigmem
label=Linux-new
initrd=/boot/initrd.img-2.6.26-1-686-bigmem
append ="panic=30"

Einfach den Parameter „append =“panic=30“ anfügen. Das gibt dem Kernel einen Paramter mit der aussagt: im Falle einer Kernel Panic nach 30 Sekunden neustarten.

lilo konfigurieren:
/sbin/lilo -v

Noch haben wir nichts gewonnen, sagen aber lilo nun das er im folgenden einmal den neuen Kernel booten soll:
/sbin/lilo -R Linux-new
Linux-new korrespondiert mit dem label in der lilo.conf

Nach einem Reboot das große Bangen: bootet die Kiste mit neuem Kernel?

Falls ja: einfach die Labels in der lilo.conf ändern und mittels /sbin/lilo -v schreiben lassen.

Generell kann es praktisch sein den Server im Falle einer Kernel Panic neustarten zu lassen.
Das sollte über so funktionieren:

in /etc/sysctl.conf trägt man ein
kernel.panic=30

und lädt den Parameter mittels
/sbin/sysctl -p
(oder startet den Server neu)

Mehrere IPs unter Debian

Man installiere iproute und trage in /etc/network/interfaces folgendes ein

up ip addr add 78.XX.XX.97/29 dev eth0
up ip addr add 78.XX.XX.98/29 dev eth0
up ip addr add 78.XX.XX.99/29 dev eth0
up ip addr add 78.XX.XX.100/29 dev eth0
up ip addr add 78.XX.XX.101/29 dev eth0
up ip addr add 78.XX.XX.102/29 dev eth0

getestet bei Hetzner für die zusätzlichen IPs

Andere NIC bringt auch nichts & die Lösung des Problems

Die andere Netzwerkkarte zu nutzen hat auch nichts gebracht. das gleiche Problem, die Verbindung ist nach ein paar Gigabyte einfach weg.

Verwunderlich war das keinerlei Logeinträge generiert wurden. Den entscheidenden (?) Hinweise hat mir dann ethtool gegeben, damit habe ich festgestellt das die Netzwerkkarte nur als 100/half betrieben wurde. Kurze Kontrolle zeigte, das statt des vermuteten Switches dann doch nur ein Dual Speed Hub am Server hängt um WLAN und Solaranlage anzubinden. Diesen durch einen 4 Port Switch ersetzt und die Probleme waren weg. vermutlich hat der Bay Networks/Netgear DS108 einfach die Backen dicht gemacht, eine Kontrolle mit 45 Gigabyte verlief zumindest ohne Auffälligkeiten.

Ein neuer Gigabit Switch steht dennoch an. Nur bin ich noch unsicher ob ich nicht gleich einen managbaren Switch nehmen soll..

Kernel bauen hilft.. oder auch nicht.

Die dropped packets sind auf 0, wie sich das gehört – leider kam es nach weiteren 3000 Bildern wieder zum aufgehängten eth0.

Heute abend werde ich mal die Interfaces tauschen, ggf ist die PCIe Karte (gleicher Chipsatz) nicht so empfindlich. Schon ärgerlich.. ein Backupserver der sich aufhängt, wenn man ein Backup versucht.

Wegen alter r8169 Treiber in Lenny neuen Kernel bauen

Die Netzwerkkarte hat sich aufgehängt wenn Last drauf war. Zum surfen reichts, aber wenn man ein Backup aufspielen wollte war aufeinmal das Interface weg :-/
Dazu unglaublich hohe Packet Drops (im Rahmen mehrerer Milliarden). Das liegt am r8169 Treiber, also mußte ein neuer Kernel installiert werden.

Kenrel runterladen und entpacken
cd /usr/src/ wget http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.28.6.tar.bz2
tar xvjf linux-2.6.28.6.tar.bz2

Alte config einpflegen

cd linux-2.6.28.6
cp /boot/config config-2.6.26-1-686 ./.config
make oldconfig

Kernel kompilieren, um beide Kerne zu nutzen setzt man den CONCURRENCY_LEVEL auf 2
Ganz wichtig: damit man auf das gecryptete Filesystem laden kann braucht man eine initrd, das gibt man dann bei make-kpkg an.

CONCURRENCY_LEVEL=2 make-kpkg --initrd --revision=fullkernel.1 kernel-image

Danach installiert man mittels

cd ..
dpkg -i linux-image-2.6.28.6

Danach rebooten und fertig.

Und nach einem ersten Test kann man ein paar Gigabyte kopieren ohne das sich das ethernet aufhängt und die drop packets sind auch weg.

Es scheint sich gelohnt zu haben.

Ethernet hängt sich manchmal auf..

Kopiert man großen Mengen an Daten hängt sich das eth0 manchmal auf und muß mittels ifconfig eth0 down && ifconfig eth1 up wieder zum Leben gebracht werden. auch sind absurde Dropped Packets in den Statistiken zu sehen.
Beides deutet auf einen Fehler im r8169 hin, der in neueren Versionen gefixt sein soll.

Feb 16 22:03:01 seth kernel: [203679.997699] NETDEV WATCHDOG: eth0: transmit timed out
Feb 16 22:03:01 seth kernel: [203679.997699] ------------[ cut here ]------------
Feb 16 22:03:01 seth kernel: [203679.997699] WARNING: at net/sched/sch_generic.c:222 dev_watchdog+0x8f/0xdc()
Feb 16 22:03:01 seth kernel: [203679.997699] Modules linked in: xt_TCPMSS xt_tcpmss iptable_mangle xt_tcpudp xt_state ipt_REJECT iptable_filter nf_nat_irc nf_nat_ftp iptable_nat nf_nat nf_conntrack_irc nf_conntrack_ftp nf_conntrack_ipv4 nf_conntrack ip_tables x_tables pppoe pppox ppp_generic slhc ipv6 ext2 sbp2 loop i2c_i801 snd_pcsp i2c_core iTCO_wdt serio_raw psmouse snd_hda_intel button intel_agp snd_pcm snd_timer agpgart snd soundcore snd_page_alloc evdev ext3 jbd mbcache sha256_generic aes_i586 aes_generic cbc dm_crypt crypto_blkcipher dm_mirror dm_log dm_snapshot dm_mod sg sr_mod cdrom sd_mod ahci libata scsi_mod dock ohci1394 ieee1394 r8169 ehci_hcd uhci_hcd usbcore thermal processor fan thermal_sys
Feb 16 22:03:01 seth kernel: [203679.997699] Pid: 4, comm: ksoftirqd/0 Not tainted 2.6.26-1-686 #1
Feb 16 22:03:01 seth kernel: [203679.997699] [] warn_on_slowpath+0x40/0x66
Feb 16 22:03:01 seth kernel: [203679.997699] [] __wake_up_common+0x2e/0x58
Feb 16 22:03:01 seth kernel: [203679.997699] [] __wake_up+0x29/0x39
Feb 16 22:03:01 seth kernel: [203679.997699] [] wake_up_klogd+0x2b/0x2d
Feb 16 22:03:01 seth kernel: [203679.997699] [] lock_timer_base+0x19/0x35
Feb 16 22:03:01 seth kernel: [203679.997699] [] __mod_timer+0x99/0xa3
Feb 16 22:03:01 seth kernel: [203679.997699] [] queue_delayed_work_on+0x9a/0xa6
Feb 16 22:03:01 seth kernel: [203679.997699] [] dev_watchdog+0x0/0xdc
Feb 16 22:03:01 seth kernel: [203679.997699] [] queue_delayed_work+0x16/0x18
Feb 16 22:03:01 seth kernel: [203679.997699] [] dev_watchdog+0x8f/0xdc
Feb 16 22:03:01 seth kernel: [203679.997699] [] run_timer_softirq+0x11a/0x17c
Feb 16 22:03:01 seth kernel: [203679.997699] [] dev_watchdog+0x0/0xdc
Feb 16 22:03:01 seth kernel: [203679.997699] [] __do_softirq+0x66/0xd3
Feb 16 22:03:01 seth kernel: [203679.997699] [] ksoftirqd+0x0/0xa6
Feb 16 22:03:01 seth kernel: [203679.997699] [] do_softirq+0x45/0x53
Feb 16 22:03:01 seth kernel: [203679.997699] [] ksoftirqd+0x43/0xa6
Feb 16 22:03:01 seth kernel: [203679.997699] [] kthread+0x38/0x5d
Feb 16 22:03:01 seth kernel: [203679.997699] [] kthread+0x0/0x5d
Feb 16 22:03:01 seth kernel: [203679.997699] [] kernel_thread_helper+0x7/0x10
Feb 16 22:03:01 seth kernel: [203679.997699] =======================
Feb 16 22:03:01 seth kernel: [203679.997699] ---[ end trace b54c54d5d43b381e ]---
Feb 16 22:03:01 seth kernel: [203680.017712] r8169: eth0: link up