RAID10 kernel panic nach kernel update [SOLVED]

[dma67]

Hallo zusammen,
nach über einem Jahr taddelloser Arbeit streikt mein Server-Knecht mit kernel panic.
Nach dem heutigen Update -darunter kernel default - (nur offizielle Repos) kommt folgende Meldung:

bin/bash: cannot find shared library libreadline.so.6:cannot open shared object file: No such file or directory
Kernel panic - not syncing: Attempted to kill init!

Ich wollte so langsam das System auf 11.3 umstellen. Wäre ein guter Zeitpunkt, das Problem ist: ich habe da 4 HDDs im RAID10 -Verbund.

Paritionsübersicht (gemacht über ein LIVE-system)
so sieht es aus

linux:/home/linux # fdisk -l                                                    

Disk /dev/sda: 640.1 GB, 640135028736 bytes
255 heads, 63 sectors/track, 77825 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x000491ad                     

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          14      112423+  83  Linux 
/dev/sda2              15         275     2096482+  82  Linux swap / Solaris
/dev/sda3             276        6019    46138680   fd  Linux raid autodetect
/dev/sda4            6020       77825   576781695   fd  Linux raid autodetect

Disk /dev/sdb: 640.1 GB, 640135028736 bytes
255 heads, 63 sectors/track, 77825 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x8c71ad6e                     

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1          14      112423+  83  Linux 
/dev/sdb2              15         275     2096482+  82  Linux swap / Solaris
/dev/sdb3             276       77825   622920375   fd  Linux raid autodetect

Disk /dev/sdc: 640.1 GB, 640135028736 bytes
255 heads, 63 sectors/track, 77825 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00037ebe

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1               1          14      112423+  83  Linux
/dev/sdc2              15         275     2096482+  82  Linux swap / Solaris
/dev/sdc3             276        6019    46138680   fd  Linux raid autodetect
/dev/sdc4            6020       77825   576781695   fd  Linux raid autodetect

Disk /dev/sdd: 640.1 GB, 640135028736 bytes
255 heads, 63 sectors/track, 77825 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x000979fd

   Device Boot      Start         End      Blocks   Id  System
/dev/sdd1               1          14      112423+  83  Linux
/dev/sdd2              15         275     2096482+  82  Linux swap / Solaris
/dev/sdd3             276       77825   622920375   fd  Linux raid autodetect

Disk /dev/sde: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00018820

   Device Boot      Start         End      Blocks   Id  System
/dev/sde1   *           1        9730    78149632   83  Linux

Wie kriege ich:

sda3 + sdc3 = md0 /
sda4 + sdc4 = md1 /srv
sdb3 + sdd3 = md2 /home

wieder so, damit die Daten sichern kann und diese nicht flöten gehen? (wäre ein Grund zum Selbstmord).

bzw. md0 Verbund erstellen, um Daten zu sichern => (etc und config, asterisk..., mysql)

Dann würde ich updaten, beim Update auf OS 11.3 md1 und md2 erneut erstellen (NICHT formatieren)

Ach so: sde ist 5. Platte, 80GB, einfach so für andere Sachen - irrelevant.

Geht das?
Was soll ich sagen.... HELP!

EDIT: ist ja eine Operation am offenen Herzen, deswegen will ich es ohne Eure Hilfe nicht anfassen.

Wäre

mdadm --create /dev/md0 --level=10 --raid-devices=2 /dev/sda3 /dev/sdc3

korrekt?


OK sieht gut aus:

linux:/home/linux # mdadm --create /dev/md0 --level=raid10 --raid-devices=2 /dev/sda3 /dev/sdc3                                                                 
mdadm: /dev/sda3 appears to contain an ext2fs file system                       
    size=46137344K  mtime=Mon Dec 13 20:47:56 2010                              
mdadm: /dev/sda3 appears to be part of a raid array:                            
    level=raid10 devices=2 ctime=Mon May 24 10:59:51 2010
mdadm: /dev/sdc3 appears to contain an ext2fs file system
    size=46137344K  mtime=Wed Jan  5 19:35:40 2011
mdadm: /dev/sdc3 appears to be part of a raid array:
    level=raid10 devices=2 ctime=Mon May 24 10:59:51 2010
Continue creating array? yes
mdadm: array /dev/md0 started.

und

linux:/home/linux # cat /proc/mdstat
Personalities : [raid10]
md0 : active raid10 sdc3[1] sda3[0]
      46138560 blocks 2 near-copies [2/2] [UU]

unused devices: <none>

md0 gemountet, alles von der root-Partition ist da. Wenigstens das fürs Erste.

Trotzdem möchte ich euch fragen, wie das jetzt am geschicktesten wäre:

1. habe jetzt noch keinen Bock auf 11.3 Update zu machen, wie kriege ich einen lauffähigen kernel wieder drauf?
2. Wenn ich doch Updaten muss - wie am besten?

Herzlichen Dank für jeden Hinweis!

 

[spoensche]

Wie sehen den die Bootparameter vom Kernel aus? Ist nach dem Update eine initrd erstellt worden? Wenn nein, musst du das noch manuel durchführen.

 

[dma67]

Nach dem Update habe ich neu gestartet - dann kamm kernel panic. Keine Ahnung, ob initrd erstellt wurde. Wohl nicht. Ich habe dann die Install-DVD angeworfen mit Reparatur-Modus, und dann wollte er plötzlich nicht mehr von sda1 booten. (sda1 ist keine RAID-Partition, ca 200MB normale ext4 als /boot)
grub.conf

linux:/home/linux # cat /rettung/root/etc/grub.conf
setup --stage2=/boot/grub/stage2 --force-lba (hd0,0) (hd0,0)
quit
linux:/home/linux # cat /rettung/boot/grub/device.map
(hd3)   /dev/disk/by-id/ata-SAMSUNG_HD642JJ_S1AFJR0QB00007
(hd1)   /dev/disk/by-id/ata-SAMSUNG_HD642JJ_S1AFJR0S400049
(hd0)   /dev/disk/by-id/ata-WDC_WD800BB-75CAA0_WD-WMA8E3830122
(hd4)   /dev/disk/by-id/ata-SAMSUNG_HD642JJ_S1Q0J1BQA01956
(hd2)   /dev/disk/by-id/ata-SAMSUNG_HD642JJ_S1AFJR0S400057
linux:/home/linux # ls /rettung/boot
backup_mbr                    memtest.bin
boot                          message
boot.readme                   symtypes-2.6.31.14-0.6-default.gz
config-2.6.31.14-0.6-default  symvers-2.6.31.14-0.6-default.gz
grub                          System.map-2.6.31.14-0.6-default
initrd                        vmlinux-2.6.31.14-0.6-default.gz
initrd-2.6.31.14-0.6-default  vmlinuz
lost+found                    vmlinuz-2.6.31.14-0.6-default

Da stimmt was nicht: der greift auf hd0 - das ist sde1 ohne initrd.
Wie biege ich das zurecht?

EDIT: initrd scheint zu existieren

 

[Anonymous]

Nach dem heutigen Update -darunter kernel default - (nur offizielle Repos) kommt folgende Meldung:

bin/bash: cannot find shared library libreadline.so.6:cannot open shared object file: No such file or directory
Kernel panic - not syncing: Attempted to kill init!

dieser Fehler hat nichts mit dem Kernel zu tun. Das ist das Fehlen oder eine falsche Version der Library /lib/libreadline.so.6 die unter anderem von der Bash benötigt wird. möglich auch eine nicht korrekte oder durch ein abgebochenes update nicht ausgeführte ld-configuration Wahrscheinlich wird diese lib auch in die initrd benötigt. Müsste man die letzten Zeilen vor dem Crash genauer anschauen, um zu sagen ob der Fehler schon in der initrd oder erst danach aufgetreten ist. Ohne diese Lib startet keine Bash und ohne Shell in den Startscripten kracht es gewaltig.
Diese Lib kommt aus dem Paket "libreadline6-6.........."

Wäre

mdadm --create /dev/md0 --level=10 --raid-devices=2 /dev/sda3 /dev/sdc3

korrekt?

Ich habe mir jetzt mal nicht die Zeit genommen und deine gesamten Beiträg mit den Logs sehr aussführlich durchgelesen und hab auch die ganze Konfiguration nur mal kurz überflogen, aber das in deiner Situation ist eine absolute Schei.. :zensur: ...Idee, damit würdest (oder hast) du eine neue Raidkonfiguration über die alte geschrieben, das Raid also neu aufgesetzt. Bei Raid 1 kann man das sicherlich noch notfalls man probieren wenn man ganz verzweifelt ist , aber jedes andere Raid ist vorsätzlich versuchter Suizid.

Richtig währe hier diese Funktionen

mdadm --assemble  ...................

um die alten vorhanden Raids entweder aus der Konfigurationsdatei oder den Superblöcken auf den Platten wieder richtig zusammenzubauen.
zB sowas hier

mdadm --assemble --scan

Schau in die Manpage von mdadm, unter "ASSEMBLE MODE"

Ansonsten jedes vernünftige Livesystem von CD sollte die Raids beim booten automatisch richtig zusammensetzen können, von dort kannst du dann auch deine Sicherungen machen.


Ansonsten müsstest du Irgendwie die Bash zum laufen bringen, dazu müsstest du dieses Library überprüfen, wenn es da sein sollte und wirklich auch ein library ist nicht irgend etwas anders, dann prüfen ob ldconfig diese lib kennt und dann noch mal eine neue initrd erstellen. Das Ganze am allerbesten von einem Rettungs- oder Livesystem aus, da du ja wahrscheinlich mit deinem System aus sowieso gar nichts machen kannst.

Wie das jetzt natürlich nach den bisherigen Rettungsversuchen aussieht und was da noch so alles "kaputt repariert" und umkonfiguriert worden ist :???:

robi

 

[dma67]

Ich habe mir jetzt mal nicht die Zeit genommen und deine gesamten Beiträg mit den Logs sehr aussführlich durchgelesen und hab auch die ganze Konfiguration nur mal kurz überflogen, aber das in deiner Situation ist eine absolute Schei.. :zensur: ...Idee, damit würdest (oder hast) du eine neue Raidkonfiguration über die alte geschrieben, das Raid also neu aufgesetzt. Bei Raid 1 kann man das sicherlich noch notfalls man probieren wenn man ganz verzweifelt ist , aber jedes andere Raid ist vorsätzlich versuchter Suizid.

Hallo robi,

danke für die ausführliche Erklärung. Diesmal bin ich von Gottes Hand geführt worden, alles halb so wild.

Also, was hab ich gemacht?
Nachdem ich den RAID10-Verbund wie oben beschrieben md0 (root Partition) aufgesetzt hatte, klappte es trotzdem ohne Probleme.
mittels

dd if=/dev/md0 of=/dev/sde1

sicherte ich erstmal die komplette root-Partition aus dem RAID.

Im Nachhinein war das selbstverständlich nicht korrekt. Hätte ich 'assemble' benutzen sollen.
Die übrigen 2 RAIDS habe ich testweise mittels 'assemble' auf einem Live-System verbunden - alles 1A.

Dann Update auf OS 11.3. Bei der Neuinstallation musste ich die Option für Experte wählen.
Alle RAIDs wurden einwandfrei erkannt (md0, md1, md2). Dann md0 als root Partition gewählt - es wurde also bei der Installation formatiert und das neue System 11.3 befindet sich jetzt drauf.
Übrige RAIDs md1 wurde als /home und md2 als /srv - wie vorher eingebunden - nicht formatiert.

Nach 20 Minuten steht 11.3 da, alles wie gehabt, Daten, Serverdaten etc, KDE Einstellungen für alle user.
Natürlich muss ich noch einige Server konfigurieren, aber die alte root-Partition ist gesichert. Also muss ich jetzt normalen "Migrationsaufwand" betreiben.

Schlußfolgerungen:
1. SUSE ist einfach GEIL, bin zwar kein SUPER Profi, aber die Neuinstallation mit bestehenden RAID war echt easy.
2. Trotz eines falschen Befehls (--create anstatt --assemble) ist alles heil geblieben.


Danke für die Hilfe.

GELÖST!

 

[spoensche]

(sda1 ist keine RAID-Partition, ca 200MB normale ext4 als /boot)

200 MB Bootpartition ist eine gute Wahl. ext4 als Dateisystem ist allerdings absolut gar keine gute Wahl. Mit ext2 wärst du da besser beraten.

 

[dma67]

Meinst Du speziell für die boot-Partition oder insgesamt? Alle Partitionen habe ich mit ext4 formatiert. Es wurde als default (bei 11.2 glaube ich, als ich die RAIDs aufgesetzt habe) vorgeschlagen, dann habe ich es genommen. Warum soll es schlecht sein?

 

[josef-wien]

Mit ext2 wärst du da besser beraten.

Irgendwie habe ich das Gefühl, die Empfehlung, Ext2 für eine Boot-Partition zu verwenden, kommt noch aus einer Epoche, in der die Boot-Partition eine lange Zeit einen statischen Inhalt hatte und oft gar nicht im Dateisystem eingehängt war. Jedes Kernel-Update verändert die Daten auf der Boot-Partition, und ein solches Ereignis ist heutzutage ja nicht gerade selten. Meiner Meinung nach ist es durchaus sinnvoll, auch für die Boot-Partition ein Dateisystem mit Journal zu verwenden. Ext2 verwende ich nur für meinen bootfähigen Notfall-Datenträger, der ist wirklich ziemlich statisch (und sorgsam verwahrt), beim laufenden Betrieb ist meine (RAID1-)Boot-Partition mit Ext3 formatiert (in manchen Dingen bin ich durchaus konservativ, da ist mir Ext4 noch zu neu).

 

[Anonymous]

Meiner Meinung nach ist es durchaus sinnvoll, auch für die Boot-Partition ein Dateisystem mit Journal zu verwenden.

Für was ist gleich nochmal das Journal da ? doch einzig und allein nur dazu im Falle eines ungücklichen Absturzes oder unsauberen aushängens das Filesystem beim Start nicht zeitaufwendig und komplett überprüfen zu müssen. Und dabei ist in diesem Fall ext3 wie ext4 in den default Modi nicht mal 110%tig. Es wird einzig und allein nur eine Konsistens der Dateisystem Metadaten wiederhergestellen, ob die Daten die genau im Absturzmoment geschrieben werden sollten nun da sind oder nicht interressiert dabei sowieso nicht. Nur die Filesystemmetadaten müssen untereinader schlüssig aussehen, dann wird ohne vollständigen Test einfach mal angenommen das Filesystem ist soweit in Ordnung das man damit arbeiten kann und damit passt das schon. Deshalb muss und/oder sollte ja auch alle paar mounts oder nach einer bestimmten Zeit ein solches Filesystem trotzdem mal komplett überprüft werde.
Nun ein reines Bootfilesystem hat so typischerweise 64 bis 256MB, dort dauert ein Filesystemcheck bei ext2 mal so grob über den Daumen geschätzt, na ja, da stockt mal ganz kurz eine Sekunde die Bootausgabe und das wars schon. Also bitte, diese Zeit habe ich immer übrig und kann mir dabei auch noch 100%tig sicher sein, das nach jedem hochfahren das Filesystem auch wirklich überprüft wurde oder vorher sauber ausgehängt war. Obwohl das Filesystem nach dem Filesystemcheck eigentlich gar nicht mehr gebraucht wird. Gebraucht wird es viel viel früher schon, nämlich im Grub und beim Kernel- und initrd-lesen. Und davor gibt es überhaupt keinen Filesystemcheck der die Vorteile des Journals ausschöpfen könnte. An dieser Stelle währe es wurscht wenn im Journal die Daten für eine schnelle Filesystemrepartur vorhanden sind. Der BIOS des PC ist das Einzige was vorher abläuft und der macht bestimmt keinen Filesystemcheck. Also zu was brauch ich hier ein Journal?

Wann schreiben wir nochmal schnell unterhalb von /boot ?

Jedes Kernel-Update verändert die Daten auf der Boot-Partition, und ein solches Ereignis ist heutzutage ja nicht gerade selten

also im Durchschnitt maximal 1 mal in 3 Wochen und da sind schon die Schreibaktionen dabei die Yast dort veranstaltet ohne das du es überhaupt bemerkst.

Also ext3 ist hier schon beinahe etwas zuviel des Guten, der Kernel und Grub würden dabei sowieso nur als ext2 lesend zugreifen, bei ext4 hat man sogar in so einem kleinem Filesystem nur mehr Nachteile anstatt irgendwelche Vorteile. Außer man würde einen Monsterkernel oder eine Monsterinitd bauen die um die 128MB oder größer ist. Dann hätte man eventuell einen Geschwindigkeitsvorteil von 1 bis 2 hundertstel Sekunden bei einem Kernelupdate. Und dieser würde sich nicht mal richtig auf das Filesystem auswirken, da nur alle 5 Sekunden ein sync gemacht wird. Wenn ich schon ein Extra /boot anlege, dann genau mit dem einzigen Filesystem mit dem es in über 15 Jahren nie an dieser Stelle Probleme gegeben hat, ext2. Hier ist das Bewährte und Einfachste auch das Sicherste und Beste.

Ist natürlich nur meine Meinung


robi