Partition tables dahin & kernel panic

[Globestern]

moin

das ganze fing damit an, dass sich apache desöftern mit

[Mon Sep 14 14:47:04 2009] [notice] Apache/2.2.13 (Unix) PHP/5.3.0 configured -- resuming normal operations
[Mon Sep 14 14:47:06 2009] [notice] child pid 9533 exit signal Segmentation fault (11)
[Mon Sep 14 14:47:07 2009] [notice] child pid 9477 exit signal Segmentation fault (11)
[Mon Sep 14 14:48:04 2009] [notice] caught SIGTERM, shutting down

verabschiedete, was eigentlich auf einen hardware fehler zurückführen lässt.

darauf hin, prüfte ich mit fsck die verschiedenen partitionen, soweit so gut - ein paar errors wurden gefunden, welche ich fixen lies. Danach rebootete ich den server.

dieser kam nun nicht mehr hoch - kernel panic (gemäss support) - im rescue modus meldete mir smartmon tools keine probleme mit den beiden festplatten und auch memory und cpu test waren iO aber:

fdisk /dev/md8 zeigte mir immer einen fehler mit den partition tables welchen ich mit "w" beheben könne. (genaue meldung habe ich leider nicht mehr)
worauf hin ich dies mit "w" - write erledigte. Danach kam der server leider immer noch nicht hoch.


fdisk -l zeigt mir:

Disk /dev/sda: 750.1 GB, 750156374016 bytes
255 heads, 63 sectors/track, 91201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot	    Start	  End	   Blocks   Id 
System
/dev/sda1   *		1	   25	   200781   fd 
Linux raid autodetect
/dev/sda2	       26	91201	732371220    5 
Extended
/dev/sda5	       26	  280	  2048256   83 
Linux
/dev/sda6	      281	 6374	 48950023+  fd 
Linux raid autodetect
/dev/sda7	     6375	78453	578974536   fd 
Linux raid autodetect
/dev/sda8	    78454	91201	102398278+  fd 
Linux raid autodetect

Disk /dev/sdb: 750.1 GB, 750156374016 bytes
255 heads, 63 sectors/track, 91201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot	    Start	  End	   Blocks   Id 
System
/dev/sdb1		1	   25	   200781   fd 
Linux raid autodetect
/dev/sdb2	       26	91201	732371220    5 
Extended
/dev/sdb5	       26	  280	  2048256   83 
Linux
/dev/sdb6	      281	 6374	 48950023+  fd 
Linux raid autodetect
/dev/sdb7	     6375	78453	578974536   fd 
Linux raid autodetect
/dev/sdb8	    78454	91201	102398278+  fd 
Linux raid autodetect

fdisk /dev/md7

Command (m for help): p

Disk /dev/md7: 592.8 GB, 592869851136 bytes
2 heads, 4 sectors/track, 144743616 cylinders
Units = cylinders of 8 * 512 = 4096 bytes

    Device Boot      Start         End      Blocks   Id  System

wenn ich die partitionen mounte im rescue modus habe ich problemlosen zugriff auf das filesystem und die dateien

ideen was ich probieren könnte?
mfg

 

[LinuxAdmin]

verabschiedete, was eigentlich auf einen hardware fehler zurückführen lässt.

Tut es das wirklich? Da gibt es noch viele andere Gründe. Wenn Hardware-Fehler dann ist es ein RAM-Fehler, kein Festplattenfehler. Das kann Dein Provider testen oder Du falls Du über eine serielle Konsole memtest86 booten kannst.

darauf hin, prüfte ich mit fsck die verschiedenen partitionen, soweit so gut - ein paar errors wurden gefunden, welche ich fixen lies. Danach rebootete ich den server.

Kling so, als ob Du die Platten gecheckt hättest, während sie noch gemountet waren -- das erklärt die vielen Fehler. Durch das fixen hast Du dann das Dateisystem ruiniert.

Oder hast Du gar das fsck auf den Platten direkt ausgeführt anstatt auf den md-Devices des RAID-Verbundes?

fdisk /dev/md8 zeigte mir immer einen fehler mit den partition tables welchen ich mit "w" beheben könne. (genaue meldung habe ich leider nicht mehr)
worauf hin ich dies mit "w" - write erledigte. Danach kam der server leider immer noch nicht hoch.

Fein. Was hast Du denn erwartet, wenn Du ein md-Device mit fdisk (das nur für ganze Festplatten gedacht ist) bearbeitest. Diese Devices haben logischerweise keine Partitionstabelle. Wahrscheinlich hat das "w" keinen allzugroßen Schaden angerichtet, da die ersten 512-Bytes der Partition normalerweise nicht verwendet werden, aber falsch war es trotzdem.

PS: Bitte noch mal bei Gelegenheit die Nutzungsbedingungen wegen der Groß-/Kleinschreibung anschauen. Danke!

 

[Globestern]

vielen Dank für deine ausführliche Antwort!

Tut es das wirklich? Da gibt es noch viele andere Gründe. Wenn Hardware-Fehler dann ist es ein RAM-Fehler, kein Festplattenfehler. Das kann Dein Provider testen oder Du falls Du über eine serielle Konsole memtest86 booten kannst.

Das Memory ist ok, habe ich bereits überprüft.

Kling so, als ob Du die Platten gecheckt hättest, während sie noch gemountet waren -- das erklärt die vielen Fehler. Durch das fixen hast Du dann das Dateisystem ruiniert.

Oder hast Du gar das fsck auf den Platten direkt ausgeführt anstatt auf den md-Devices des RAID-Verbundes?

das unmounten habe ich def. vergessen, der fsck wurde aber auf den md-devices durchgeführt.

Fein. Was hast Du denn erwartet, wenn Du ein md-Device mit fdisk (das nur für ganze Festplatten gedacht ist) bearbeitest. Diese Devices haben logischerweise keine Partitionstabelle. Wahrscheinlich hat das "w" keinen allzugroßen Schaden angerichtet, da die ersten 512-Bytes der Partition normalerweise nicht verwendet werden, aber falsch war es trotzdem.

klingt im Nacherein logisch - war wohl nicht ganz auf der Höhe.. :S
wieder etwas dazugelernt..

wie fixe ich nun am Besten das Problem?

 

[Globestern]

ich habe nun versucht den mbr neu zu schreiben:

rescue:/bla2# dd if=boot.0810 of=/dev/sda bs=512
1+0 records in
1+0 records out
512 bytes transferred in 0.000050 seconds (10249897 bytes/sec)

rescue:/bla2# dd if=boot.0810 of=/dev/sdb bs=512
1+0 records in
1+0 records out
512 bytes transferred in 0.000036 seconds (14227911 bytes/sec)

boot.0810 sollte eigentlich richtig sein:

hexdump -x boot.0810
00001f0    0000    0000    0000    0000    0000    0000    0000    [B]aa55[/B]
0000200

trotzdem kommt der server leider nicht hoch - ideen?

 

[LinuxAdmin]

Dir ist schon klar, dass in den ersten 512 Bytes auch Deine Partitionstabellen standen?

Wenn Du Glück hast, wurden die Datei boot.0810 vom Bootmanager erst erstellt, als schon alle Partitionen eingerichtet waren. Andernfalls sind sie jetzt weg (Immerhin hat das SSF ja noch einen Backup der Daten...).
Dass der Server nicht bootet, nachdem Du die Backup-Kopie des MBR von vor der Installation des Bootmanagers drüber gebügelt hast, sollte Dich eigentlich nicht wundern.

Mir scheint, Du bist ziemlich verzweifelt und probierst wild irgendwelche Sachen aus, die Du in den Tiefen des Internets gefunden hast, ohne Dir über die Konsequenzen Gedanken zu machen. Das halte ich für ziemlich gefährlich.

Als nächstes solltes Du schauen, dass Deine Partitionstabellen wirklich in Ordnung sind. Danach solltest Du den Bootmanager (grub oder Lilo, je nachdem, was ursprünglich installiert war) verwenden, um den MBR-Code neu zu schreiben.

 

[Globestern]

richtig, ich bin ziemlich verzweifelt...

um jetzt aber nicht wieder den selben Fehler zu machen und etwas unüberlegtes zu starten:

wie schreibe ich den MBR am Besten per lilo?

dd reicht ja nicht..

also per:

lilo.real -M /dev/sda1?

denke ja nicht, dass der MBR aufs RAID muss, macht keinen Sinn?