[Eisfair] Kernel Panic nach Systemupdate

Harald Seitter harald.seitter at gmx.de
Do Apr 11 01:20:24 CEST 2019


Hallo Marcus,


Am 06.04.2019 um 10:03 schrieb Marcus Roeckrath:
> Hallo Harald,
> 
> Harald Seitter wrote:
> 
>>   > Ein Blick in die Base verrät folgendes:
>>   >
>>   > swap_free: Bad swap file entry 360fb58a
>>   > BUG: Bad page map in process eisman_upgrade
>>
>> zur Information:
>>
>> Die Beschreibungen von Manfred kommen mir sehr bekannt vor.
>>
>> Ich habe letzten Sonntag (31.03.19) ebenfalls ein System durch manuelle
>> Updates aktualisiert.
>>
>> Bis dann am Montag Win-PCs abstürzten beim Verbinden mit
>> Netzwerklaufwerken und andere gar keine bekamen.
>> Auf der Console laufend Meldungen swap_free: Bad swap file entry
>> und ebenso dann Kernel-Panic.
>> In der varlogmessages Meldungen von korrupten Filesystem etc.
>> Beim Neustart und Reparatur beim Superblock und geforcten
>> Filesystemcheck war erstmal wieder Ruhe. Ein Tag später eine korrupte
>> Word-Datei. Beim Zurückspielen über einen NFS-Mount Kernel-Panic!
> 
> Da niemand auf echter Hardware ein solches Problem hat, wäre es möglich,
> dass es mit der Virtualisierung zusammenhängt.
> 
> Fragen an euch beide:
> 
> Welche Virtualisierungslösung in welcher Version?
> 
Bei mir läuft das ganze auf ESXi 6.7 u. 6.5.
Ich will ja nicht ausschliessen, dass es an einer Virtualisierung liegen
kann.

> Welches war der problematische Kernel 3.38.0?
Da ich das System ja "weggeschmissen" hatte kann ich nicht mehr
nachsehen. Aber es war damals das aktuellste Update vom Sonntag 31.03.
Das System vor dem Update (File-Server):
base     : 2.8.9
eiskernel: 3.20.0 (3.16.58-eisfair-1-SMP)

System:    Host: host9 Kernel: 3.16.58-eisfair-1-SMP i686 bits: 32
            Console: tty 0 Distro: eisfair-1
Machine:   Device: vmware System: VMware product: VMware Virtual 
Platform serial: VMware-56 4d 29 e0 80 b7 0f 1b-59 13 53 a6 e9 fe 9c 6a
            Mobo: Intel model: 440BX Desktop Reference Platform serial: N/A
            BIOS: Phoenix v: 6.00 date: 04/05/2016
CPU(s):    2 Single core Intel Core i7-7700s (-HT-SMP-) cache: 16384 KB
            clock speeds: max: 3599 MHz 1: 3599 MHz 2: 3599 MHz
Graphics:  Card: VMware SVGA II Adapter
            Display Server: N/A driver: N/A
            tty size: 197x51 Advanced Data: N/A for root out of X
Audio:     Sound: Advanced Linux Sound Architecture v: 
k3.16.58-eisfair-1-SMP
Network:   Card: VMware VMXNET3 Ethernet Controller driver: vmxnet3
            IF: net0 state: up speed: 10000 Mbps duplex: full
            mac: 00:0c:29:fe:9c:6a
Drives:    HDD Total Size: 584.1GB (43.9% used)
            ID-1: /dev/hda model: VMware Virtual IDE Hard Drive size: 34.4GB
            ID-2: /dev/hdc model: VMware Virtual IDE Hard Drive size: 
549.8GB
Partition: ID-1: / size: 7.8G used: 853M (12%) fs: ext4 dev: /dev/hda3
            ID-2: /boot size: 43M used: 15M (37%) fs: ext4 dev: /dev/hda1
            ID-3: swap-1 size: 1.07GB used: 0.00GB (0%) fs: swap dev: 
/dev/hda2
RAID:      No RAID devices: /proc/mdstat, md_mod kernel module present
Sensors:   None detected - is lm-sensors installed and configured?
Info:      Processes: 147 Uptime: 7 days 21:40 Memory: 222.2/1009.3MB
            Init: SysVinit runlevel: 2 Client: Shell (hwdiag-list) inxi: 
2.3.40

> 
>> Ich habe dann die Reißleine gezogen.
> 
> Kannst du in der Virtualisierung nicht oldeis booten?
> 
Da hast Du in der Tat Recht. Auf die Idee bin ich nicht gekommen - 
peinlich.

> Da hätte man bei ansonsten gleichem System sehen können, ob es wirklich der
> Kernel ist.
Jou
> 
>> Man könnte meinen als stimmt was mit dem neuen Kernel nicht.
> 
> Warum sollte da nicht auch mal ein Bug drin sein.
> 
Gehört zwar nicht in den Thread aber zur Erklärung:
Es kann schon an der Virtualisierung liegen. Als ich letztes Wochenende
einen neuen Mailserver aufgebaut hatte, der alte war ziemlich alt, war
ich so ziemlich fertig und wollte am Schluss mit rsync die .imapmail
Inahlte rüberziehen und urplötzlich die Fehlermeldung:
rsync: writefd_unbuffered failed to write 4 bytes [sender]: Broken pipe 
(32) rsync: connection unexpectedly closed (1212 bytes received so far) 
[sender].
Panik - was ist denn jetzt schon wieder los. Der Aufbau hatte doch
einwandfrei geklappt. Googeln hatte nichts vernünftiges gebracht. Durch
Austausch der virt. Netzwerkkarte auf E1000 lief es danach einwandfrei.

Bem: Bei obigen Fileserver macht die Netzwerkkarte keine Prob. und
funktioniert mit rsync seit langem einwandfrei.
Manchmal ist es eben ein System mit 7 Siegeln.

Viele Grüße
Harald












Mehr Informationen über die Mailingliste Eisfair