Hallo zusammen Zuerst einmal - alles funktioniert wieder - ich würde alles nur gerne verstehen. Mein Rechner hat sich durch leichtfertiges Starten zweier VMs in VMWare aufgehängt - sprich war so beschäftigt, dass auf keine Tastatureingabe (Strg+Alt*Esc, Strg+Alt+F1, Strg+Alt*Entf) reagiert wurde. Wartezeit etwa 60 Minuten. SSH-Login scheiterte am Timeout. Folglich konnte ich den Prozess mit meinem Wissen nicht killen. Nachdem nach einer weiteren Stunde die Uhr aber immer noch bei einer Stunde vorher stand, ging ich von einem Systemcrash aus. Bauchschmerzen bereiteten mir die (seltenen, aber reglemäßigen) Plattenzugriffe. Ich schaltete mit sehr ungutem Gefühl einfach ab und nach Reboot bekam ich nur die Meldung "Press any key to reboot" Also Live-CD rein und Root und Home-Partition per dd gesichert. Danach 10.1 DVD rein und System reaprieren lassen. Meldet Fehler auf hdb3, welcher nicht repariert werden kann und steigt aus der Systemreparatur aus, indem ohne Vorwarnung rebootet wird. Die Platten: hda1 = 250GB NTFS --> WinXP hdb1 = 25GB ReiserFS --> / hdb2 = 68GB ReiserFS --> /home hdb3 = 25GB ReiserFS --> Testpartition für Testinstallationen hdb4 = 2GB Swap sdx sind Backuppartitionen von insgesamt 200GB Ein FS-Check auf hdb3 sagte mir, es gäbe keinen Superblock und ich solle reiserfsck --rebuild-sb aufrufen. Done und es kam die Meldung der Superblock wäre restauriert worden. Ein weiterer reiserfsck --check gab die Meldung es gäbe kein Journal und ich solle reiserfsck --rebuild-tree aufrufen. Das wurde am Ende mit der Meldung abgebrochen, dass die Aktion nicht erfolgreich war. Danach war ich mit meinem FS-Latein am Ende. Nachdem ich hdb3 für mein System nicht zwingend brauche, versuchte ich Grub neu auf hdb1 (wo es vorher war) zu installieren scheiterte mit der Info, dass hdb1 nicht existiere. *????* Also nochmals Live-CD rein und nachgesehen, ob ich auf / (hdb1) und /home (hdb2) zugreifen kann und da sah alles normal aus. Nachdem hdb3 nur eine Testinstallationspartition ist, hab ich diese per fdisk gelöscht. Nach Reboot erscheint das Bootmenü (ohne Windows) und Suse 10.1 startet völlig normal. Ich musste nur noch die Backuppartitionen wieder einbinden (diese Einträge waren aus der fstab verschwunden - warum???) und alles klappt wieder. Ich habe alles nach bester Erinnerung aufgeschrieben und hoffe keine Fehler gemacht zu haben. Kann mir das jemand erklären? 1. Wie es zu einem FS-Fehler auf hdb3 durch einen Systemcrash kommen kann, wenn hdb3 aber niemals im Produktivsystem (welches gecrasht ist) eingebunden ist? 2. Wo die Meldung herkam: "Press a key to reboot"? 3. Warum sich hdb3 nicht restaurieren ließ? 4. Warum sich Grub nicht neu installieren ließ? 5. Warum bootet das System wieder nach Löschen von hdb3? Mir ist klar, dass man bestimmt nur Vermutungen anstellen kann. Ich bin trotzdem echt gespannt (aber froh, dass alles wieder geht). Andy -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, Am Sonntag, 7. Januar 2007 12:35 schrieb Andreas Schott:
Zuerst einmal - alles funktioniert wieder - ich würde alles nur gerne verstehen.
[ ... ]
Die Platten:
hda1 = 250GB NTFS --> WinXP hdb1 = 25GB ReiserFS --> / hdb2 = 68GB ReiserFS --> /home hdb3 = 25GB ReiserFS --> Testpartition für Testinstallationen hdb4 = 2GB Swap
[ ...]
Ich habe alles nach bester Erinnerung aufgeschrieben und hoffe keine Fehler gemacht zu haben. Kann mir das jemand erklären?
Vorweg: Ob ich wirklich zum Verständnis beitragen kann, weiß ich nicht so recht.
1. Wie es zu einem FS-Fehler auf hdb3 durch einen Systemcrash kommen kann, wenn hdb3 aber niemals im Produktivsystem (welches gecrasht ist) eingebunden ist?
Trotzdem ist ja hdb3 mit hda verknüpft, wenn GRUB im MBR oder dem Bootsektor von hdb installiert ist. Der Crash ist ja schon beim Hochfahren passiert - also war mit GRUB was nicht i.O.
2. Wo die Meldung herkam: "Press a key to reboot"?
Die Meldung kommt eindeutig von GRUB.
3. Warum sich hdb3 nicht restaurieren ließ?
Weil GRUB irgendwie zerschossen war und die initrd den Kernel nicht laden konnte.
4. Warum sich Grub nicht neu installieren ließ?
Das ist zwar etwas verwunderlich; deutet aber auf die öfter bestehenden Probleme zwischen XP, Linux und VMWare hin.
5. Warum bootet das System wieder nach Löschen von hdb3?
Weil damit die "alte" Ordnung vor der Installation des Testsystems wieder hergestellt wurde.
Mir ist klar, dass man bestimmt nur Vermutungen anstellen kann. Ich bin trotzdem echt gespannt (aber froh, dass alles wieder geht).
(Wäre ich auch). Gruß H.-Peter -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Sonntag, 7. Januar 2007 19:21 schrieb H.-Peter Baldamus:
Hallo,
Am Sonntag, 7. Januar 2007 12:35 schrieb Andreas Schott:
Zuerst einmal - alles funktioniert wieder - ich würde alles nur gerne verstehen.
[ ... ]
Die Platten:
hda1 = 250GB NTFS --> WinXP hdb1 = 25GB ReiserFS --> / hdb2 = 68GB ReiserFS --> /home hdb3 = 25GB ReiserFS --> Testpartition für Testinstallationen hdb4 = 2GB Swap
[ ...]
Ich habe alles nach bester Erinnerung aufgeschrieben und hoffe keine Fehler gemacht zu haben. Kann mir das jemand erklären?
Vorweg: Ob ich wirklich zum Verständnis beitragen kann, weiß ich nicht so recht.
Trotzdem danke für den Versuch.
1. Wie es zu einem FS-Fehler auf hdb3 durch einen Systemcrash kommen kann, wenn hdb3 aber niemals im Produktivsystem (welches gecrasht ist) eingebunden ist?
Trotzdem ist ja hdb3 mit hda verknüpft, wenn GRUB im MBR oder dem Bootsektor von hdb installiert ist. Der Crash ist ja schon beim Hochfahren passiert - also war mit GRUB was nicht i.O.
Falsch verstanden. Das System hatte ne Uptime von mehreren Tagen und ist erst gecrasht, als ich 2 VMs gestartet habe. Oder meinst du mit Crash die Fehlermeldung navh dem ersten Reboot?
2. Wo die Meldung herkam: "Press a key to reboot"?
Die Meldung kommt eindeutig von GRUB.
OKay.
3. Warum sich hdb3 nicht restaurieren ließ?
Weil GRUB irgendwie zerschossen war und die initrd den Kernel nicht laden konnte.
Was hat den der Bootmanager mit den einzelnen Partitionen zu tun? Ich startete ja ohne den Grub von PLatte, sondern von der Suse-DVD
4. Warum sich Grub nicht neu installieren ließ?
Das ist zwar etwas verwunderlich; deutet aber auf die öfter bestehenden Probleme zwischen XP, Linux und VMWare hin.
Versteh ich nicht. Es war gar keine 2. PLatte da laut Systemreparatur der Suse-DVD
5. Warum bootet das System wieder nach Löschen von hdb3?
Weil damit die "alte" Ordnung vor der Installation des Testsystems wieder hergestellt wurde.
Das System lief mit dem installierten Testsystem über Monate problemlos. Durch den Reset wird die PLatte hdb (und damit das FS) in einem undefinierten Zustand hinterlassen. Nachdem die zerstörte Partition hdb3 nicht eingebunden war, konnten auf der Partition selbst keine Schreibzugriffe erfolgt sein - nur im Bootsektor von hdb. Warum findet dann die DawnSmallLinux-Live-CD die PLatte hdb mit allen Partitionen, und die Suse-DVD behauptet nach dem Versuch der Reparatur von hdb3, es gäbe keine Partition hdb1 um Grub neu zu installieren? Muss es nicht so sein, dass die Information, wo die Partitionen liegen intakt gewesen sein muss, sonst hätte ich per Live-CD nicht darauf zugreifen können? Nur wenn diese intakt waren, und hdb3 nicht eingebunden war, dann verstehe ich eben nicht wieso hdb3 zerschossen war. Ich weiß - es wird vermutlich zu kompliziert werden und man muss zuviel vermuten, aber etwas mehr wüsste ich dann schon gerne. Danke trotzdem für die Hilfe. Andy -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, Am Son, 07 Jan 2007, Andreas Schott schrieb:
Mein Rechner hat sich durch leichtfertiges Starten zweier VMs in VMWare aufgehängt - sprich war so beschäftigt, dass auf keine Tastatureingabe (Strg+Alt*Esc, Strg+Alt+F1, Strg+Alt*Entf) reagiert wurde. Wartezeit etwa 60 Minuten.
Sysrq! Hilft wenn die Tastatur und der Kernel noch laufen. [..]
Ich schaltete mit sehr ungutem Gefühl einfach ab und nach Reboot bekam ich nur die Meldung "Press any key to reboot" [..] sdx sind Backuppartitionen von insgesamt 200GB
SCSI oder SATA? Wenn SATA: welcher Controller / Chip und Treiber? -dnh -- Und jetzt sei ein lieber Hase und hoppel irgendwohin, wo man knuddelige, fluffige kleine Dinger wie Dich in den Arm nimmt und lieb hat. -- Robin S. Socha in dcoulm -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Sonntag, 7. Januar 2007 22:16 schrieb David Haller:
Hallo,
Am Son, 07 Jan 2007, Andreas Schott schrieb:
Mein Rechner hat sich durch leichtfertiges Starten zweier VMs in VMWare aufgehängt - sprich war so beschäftigt, dass auf keine Tastatureingabe (Strg+Alt*Esc, Strg+Alt+F1, Strg+Alt*Entf) reagiert wurde. Wartezeit etwa 60 Minuten.
Sysrq! Hilft wenn die Tastatur und der Kernel noch laufen.
OKay.
[..]
Ich schaltete mit sehr ungutem Gefühl einfach ab und nach Reboot bekam ich nur die Meldung "Press any key to reboot"
[..]
sdx sind Backuppartitionen von insgesamt 200GB
SCSI oder SATA? Wenn SATA: welcher Controller / Chip und Treiber?
SCSI Andy -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hi, ich stocher auch mal mit im Dunkeln. * Andreas Schott wrote on Sun, Jan 07, 2007 at 12:35 +0100:
Ich schaltete mit sehr ungutem Gefühl einfach ab und nach Reboot bekam ich nur die Meldung "Press any key to reboot"
Wäre mir nicht 100% sicher, ob das vom Grub kommt oder vielleicht von einem BIOS, was mit'm MBR nix anfangen kann oder so.
Danach 10.1 DVD rein und System reaprieren lassen. Meldet Fehler auf hdb3, welcher nicht repariert werden kann und steigt aus der Systemreparatur aus, indem ohne Vorwarnung rebootet wird.
reiserfs?
Die Platten:
hda1 = 250GB NTFS --> WinXP hdb1 = 25GB ReiserFS --> / hdb2 = 68GB ReiserFS --> /home hdb3 = 25GB ReiserFS --> Testpartition für Testinstallationen
achso, reiser. SCNR :-)
hdb4 = 2GB Swap
sdx sind Backuppartitionen von insgesamt 200GB
[...]
Nachdem ich hdb3 für mein System nicht zwingend brauche, versuchte ich Grub neu auf hdb1 (wo es vorher war) zu installieren scheiterte mit der Info, dass hdb1 nicht existiere. *????*
War das bei reiser nicht sowieso so, dass der Treiber da irgendwelche gemeinsamen Strukturen benutzt, was auch für den interessanten Effekt sorgte, dass man reiserfs nicht über loopback von reiserfs mounten sollte? Weiterhin könnten ja irgendwelche kaputten blocknummern oder so im Filesystem "in den Wald" zeigen, keine Ahnung.
Also nochmals Live-CD rein und nachgesehen, ob ich auf / (hdb1) und /home (hdb2) zugreifen kann und da sah alles normal aus. Nachdem hdb3 nur eine Testinstallationspartition ist, hab ich diese per fdisk gelöscht.
Das half? Das ist schon interessant...
Nach Reboot erscheint das Bootmenü (ohne Windows) und Suse 10.1 startet völlig normal. Ich musste nur noch die Backuppartitionen wieder einbinden (diese Einträge waren aus der fstab verschwunden - warum???)
(yast automagie?)
Ich habe alles nach bester Erinnerung aufgeschrieben und hoffe keine Fehler gemacht zu haben. Kann mir das jemand erklären?
1. Wie es zu einem FS-Fehler auf hdb3 durch einen Systemcrash kommen kann, wenn hdb3 aber niemals im Produktivsystem (welches gecrasht ist) eingebunden ist?
Na ja, wenn ein Filesystemtreiber vielleicht durch kaputte Strukturen irgendwo in den Wald schreibt, dabei auf der Folge-Partition landet und die gleich mit himmelt? Bei Zeigerfehlern kann ja auch viel passieren (und hier gibts meist noch ne MMU, die bissel was schützt :)).
2. Wo die Meldung herkam: "Press a key to reboot"?
Ich bilde mir mal ein, sowas von einem BIOS gelesen zu haben. Aber lange her und kann sein, dass der Text bissel anders war. Vielleicht "No keyboard found. Press F1 to continue". Ach nee, das war was anderes :)
3. Warum sich hdb3 nicht restaurieren ließ?
reiserfs ist wohl dafür bekannt, bei Fehlern intoleranter zu sein, als z.B. ext3. reiserfs geht wohl davon aus, dass man bei Hardware und solchen Problemen eh ein Backup einspielt.
4. Warum sich Grub nicht neu installieren ließ?
Das ist interessant. Denke, dass lag am Grub, dessen Magie etwas nicht gefallen hat. Grub muss ja Dinge über das Filesystem wissen, die es gar nicht wissen sollte (nach Meinung Einzelner wie mir ;)). Wenn da was nicht OK ist, kann es ggf. halt nicht arbeiten. Könnte ich mir vorstellen. Dann vielleicht noch ein Mechanismus, der die Fehlermeldungen nach /dev/kde/kerrormsgh/kpollme umleitet oder so und man merkts gar nicht...
5. Warum bootet das System wieder nach Löschen von hdb3?
Ist auch interessant... Bin mal gespannt, ob David eine Idee hat :)
Mir ist klar, dass man bestimmt nur Vermutungen anstellen kann. Ich bin trotzdem echt gespannt (aber froh, dass alles wieder geht).
Ich würde diesem System nicht mehr trauen :) Hab heute gerade eine alte PostgreSQL 7.1 (das war bei SuSE 7.3 dabei) Datenbank verloren. Nach voller Platte und komischen Crash wollte das recovery nicht. Da hab ich das log gelöscht; dachte, sind halt die Statistikdaten weg, egal. PostgreSQL startete dann wieder. Hab mit paar "brutalen" test queries festgestellt, dass die DB aber nicht konsistent ist... Hab sie dann doch lieber weggeschmissen und neu gemacht, bei sowas hat man selten Selbstheilung ;) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, Am Die, 09 Jan 2007, Steffen Dettmer schrieb:
* Andreas Schott wrote on Sun, Jan 07, 2007 at 12:35 +0100: [..]
Nachdem ich hdb3 für mein System nicht zwingend brauche, versuchte ich Grub neu auf hdb1 (wo es vorher war) zu installieren scheiterte mit der Info, dass hdb1 nicht existiere. *????*
War das bei reiser nicht sowieso so, dass der Treiber da irgendwelche gemeinsamen Strukturen benutzt, was auch für den interessanten Effekt sorgte, dass man reiserfs nicht über loopback von reiserfs mounten sollte?
IIRC war da was. Spätestens beim 'reiserfsck --rebuild-tree'... *VEG*
1. Wie es zu einem FS-Fehler auf hdb3 durch einen Systemcrash kommen kann, wenn hdb3 aber niemals im Produktivsystem (welches gecrasht ist) eingebunden ist?
Da hab ich übrigens keine Idee zu.
5. Warum bootet das System wieder nach Löschen von hdb3?
Ist auch interessant... Bin mal gespannt, ob David eine Idee hat :)
Wenn du mich so provozierst... ;) GRUB greift (im stage1.5 IIRC) auf die Dateisysteme zu um das jew. Kernel-Image + initrd zu finden. Zeigt ein Verweis in der menu.lst dabei in was geschreddertes, macht GRUB evtl. an dieser Stelle schon die Grätsche, obwohl dieser "Schrott-Eintrag" gerade gar nicht gebootet werden soll... Insofern ist da LILO wohl robuster. Das "merkt" sich einfach nur Device + Sektornummer + Länge (oder so) die es in den Speicher kloppen und dann starten soll... Zeigt ein Eintrag nun auf Datenschrott interessiert das LILO genau gar nicht, erst wenn der Datenschrott dann gestartet werden soll krachts. Die anderen Einträge im LILO sollten nicht beeinflußt werden. Andererseits muß man eben deswegen LILO jedesmal installieren, wenn sich die Sektornummer eines Kernels / einer initrd ändert -- und bei der LILO-Installation müssen die Kernels und initrds via Dateisystem erreichbar sein (d.h. das FS auf dem sie liegen muß gemounted sein)... Soweit meine Spekulation aufgrund meines Wissens über die Funktionsweisen von GRUB und LILO. Allerdings startet das uralt-LILO hier nicht von meinen >127 GB Platten, insofern verwende ich hier z.Z. nur GRUB. -dnh -- Linux ohne Netz ist ja schlimmer als Weihnachtsstollen ohne Rosinen. -- Lothar Klöden -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
participants (4)
-
Andreas Schott -
David Haller -
H.-Peter Baldamus -
Steffen Dettmer