root-Partition pötzlich read-only
Hallo, Seit etwa einer Woche schlage ich mich mit einem Problem herum, ohne dessen Lösung auch nur einen Schritt näher gekommen zu sein: Während des Betriebs ist es plötzlich nicht mehr möglich, Daten auf die Partition mit dem root-Verzeichnisbaum ("/") zu schreiben. Diese Verzeichnisstruktur enthält mit Ausnahmen von /home alle Datenbestände des Systems. Erstmals aufgefallen ist das Problem, weil gimp mit der Meldung startete, das Zugriffe auf die Auslagerungsdatei (in /tmp) wegen nicht ausreichender Rechte nicht möglich sei. mount weist das Laufwerk weiterhin als rw aus. Ein touch auf eine Datei in dem Verzeichnis, wird mit touch: kann ,,file" nicht berühren: Das Dateisystem ist nur lesbar quittiert. Wenn man das System in diesem Zustand herunterfährt und die Protokollmeldungen auf der Konsole verfolgt, sieht man, dass etliche Prozesse nicht sauber beendet werden können, weil die Datei oder das Verzeichnis 'read-only' sind. Ein von einem Rescue-System aus gestarteter fsck findet eine Hand voll suspekter inode, die aber durchaus auf den nicht sauber gelungenen Systemabschluß zurückzuführen sich. smart bescheinigt, dass das Laufwerk keine Fehler hat. Auch in den log-Dateien konnte ich keine Einträge finden, die auf eine möglicher Ursache deuten würden. Eine Suche im Internet brachte auch keine nützlichen Erkenntnisse. Daher meine dringende Bitte um Hilfe an Euch: Kenne jemand das beschriebene Verhalten? Was ist die Ursache und wie - viel wichtiger - kann ich den Fehler beseitigen? Ach, ja: Mein OS ist SuSE Linux 10.0. Vielen Dank für Eure Hilfe. Mit freundlichen Grüssen Uwe Diederich
Am Donnerstag, 6. April 2006 14:00 schrieb Uwe Diederich:
Hallo,
Seit etwa einer Woche schlage ich mich mit einem Problem herum, ohne dessen Lösung auch nur einen Schritt näher gekommen zu sein: Während des Betriebs ist es plötzlich nicht mehr möglich, Daten auf die Partition mit dem root-Verzeichnisbaum ("/") zu schreiben. Diese Verzeichnisstruktur enthält mit Ausnahmen von /home alle Datenbestände des Systems.
Erstmals aufgefallen ist das Problem, weil gimp mit der Meldung startete, das Zugriffe auf die Auslagerungsdatei (in /tmp) wegen nicht ausreichender Rechte nicht möglich sei. mount weist das Laufwerk weiterhin als rw aus. Ein touch auf eine Datei in dem Verzeichnis, wird mit touch: kann ,,file" nicht berühren: Das Dateisystem ist nur lesbar quittiert. Wenn man das System in diesem Zustand herunterfährt und die Protokollmeldungen auf der Konsole verfolgt, sieht man, dass etliche Prozesse nicht sauber beendet werden können, weil die Datei oder das Verzeichnis 'read-only' sind.
Ein von einem Rescue-System aus gestarteter fsck findet eine Hand voll suspekter inode, die aber durchaus auf den nicht sauber gelungenen Systemabschluß zurückzuführen sich. smart bescheinigt, dass das Laufwerk keine Fehler hat. Auch in den log-Dateien konnte ich keine Einträge finden, die auf eine möglicher Ursache deuten würden. Eine Suche im Internet brachte auch keine nützlichen Erkenntnisse.
Daher meine dringende Bitte um Hilfe an Euch: Kenne jemand das beschriebene Verhalten? Was ist die Ursache und wie - viel wichtiger - kann ich den Fehler beseitigen?
ich empfehle vom Rettungssystem ein filesystem-check mit Reperatur durchzuführen. Dazu bootet man das Rettungsystem, wechselt auf eine andere Konsole. Da ich annehme es handelt sich um ein reiserfs: fsck.reiserfs --fix-fixable device und wenn das nicht hilft, dann ein: fsck.reiserfs --rebuild-tree device aber Achtung: das ist nicht ganz ohne (Datenverlust). Danach am besten das System "auomatisch" vom Rettngsystem repapieren lassen, damit evtl. korrupte oder fehlende Dateien neu installiert werden. Bye Jürgen -- Dr.rer.nat. Juergen Vollmer, Viktoriastrasse 15, D-76133 Karlsruhe Tel: +49(721) 92 04 87 1 Fax: +49(721) 92 04 87 2 Juergen.Vollmer@informatik-vollmer.de www.informatik-vollmer.de Internet-Telefonie: www.skype.com Benutzer: juergen.vollmer
Dr. Jürgen Vollmer schrieb:
ich empfehle vom Rettungssystem ein filesystem-check mit Reperatur durchzuführen. Dazu bootet man das Rettungsystem, wechselt auf eine andere Konsole. Da ich annehme es handelt sich um ein reiserfs: fsck.reiserfs --fix-fixable device und wenn das nicht hilft, dann ein: fsck.reiserfs --rebuild-tree device aber Achtung: das ist nicht ganz ohne (Datenverlust).
Danach am besten das System "auomatisch" vom Rettngsystem repapieren lassen, damit evtl. korrupte oder fehlende Dateien neu installiert werden.
Bye Jürgen
Das Dateisystem ist ext3.
Am Donnerstag, 6. April 2006 14:38 schrieb Uwe Diederich:
Dr. Jürgen Vollmer schrieb:
ich empfehle vom Rettungssystem ein filesystem-check mit Reperatur durchzuführen. Dazu bootet man das Rettungsystem, wechselt auf eine andere Konsole. Da ich annehme es handelt sich um ein reiserfs: fsck.reiserfs --fix-fixable device und wenn das nicht hilft, dann ein: fsck.reiserfs --rebuild-tree device aber Achtung: das ist nicht ganz ohne (Datenverlust).
Danach am besten das System "auomatisch" vom Rettngsystem repapieren lassen, damit evtl. korrupte oder fehlende Dateien neu installiert werden.
Bye Jürgen
Das Dateisystem ist ext3.
Dann eben mit: Usage: /sbin/fsck.ext2 [-panyrcdfvstDFSV] [-b superblock] [-B blocksize] [-I inode_buffer_blocks] [-P process_inode_size] [-l|-L bad_blocks_file] [-C fd] [-j external_journal] [-E extended-options] device Notfallhile: -p automatische Reparatur (keine Fragen) ^^^^^^^^^^^^^^^^^^^^^^ oder auch mal: -c suche nach defekten Blöcken ggf: -f erzwinge die Überprüfung auch wenn alles i.O. erscheint Jürgen -- Dr.rer.nat. Juergen Vollmer, Viktoriastrasse 15, D-76133 Karlsruhe Tel: +49(721) 92 04 87 1 Fax: +49(721) 92 04 87 2 Juergen.Vollmer@informatik-vollmer.de www.informatik-vollmer.de Internet-Telefonie: www.skype.com Benutzer: juergen.vollmer
Hallo, Am Thu, 06 Apr 2006, Uwe Diederich schrieb:
Erstmals aufgefallen ist das Problem, weil gimp mit der Meldung startete, das Zugriffe auf die Auslagerungsdatei (in /tmp) wegen nicht ausreichender Rechte nicht möglich sei. mount weist das Laufwerk weiterhin als rw aus.
Das ist eine gern hineingetappte Falle! Denn mount liest aus /etc/mtab und wenn die nicht mehr schreibbar ist bleibt's dort beim 'rw'. Du musst bei sowas 'cat /proc/mounts' verwenden. [..]
Daher meine dringende Bitte um Hilfe an Euch: Kenne jemand das beschriebene Verhalten? Was ist die Ursache und wie - viel wichtiger - kann ich den Fehler beseitigen?
Da faellt mir erstmal auch nix ein, ausser, dass vielleicht irgendwas ein 'mount -o ro,remount' (oder so) ausfuehrt... Aehm, du bist nicht zufaellig auf 'sysrq + u' (also Strg+Alt+Druck+u) gekommen? Irgendwas in /var/log/{warn,messages}? -dnh -- Malicious software is so rampant that the average time it takes for an unpatched Windows XP to be compromised after connecting it directly to the Internet is 16 minutes -- less time than it takes to download and install the patches that would help protect that PC. -- Nicholas Petreley
Hallo David, Am Donnerstag, 6. April 2006 16:30 schrieb David Haller:
ein 'mount -o ro,remount' (oder so) ausfuehrt... Aehm, du bist nicht zufaellig auf 'sysrq + u' (also Strg+Alt+Druck+u) gekommen?
hm, was bewirkt das? Und weißt Du, wo Infos dazu stehen bzw. überhaupt zu solchen Tastenkombinationen? Manfred
Manfred Rebentisch wrote:
Am Donnerstag, 6. April 2006 16:30 schrieb David Haller:
ein 'mount -o ro,remount' (oder so) ausfuehrt... Aehm, du bist nicht zufaellig auf 'sysrq + u' (also Strg+Alt+Druck+u) gekommen?
hm, was bewirkt das? Und weißt Du, wo Infos dazu stehen bzw. überhaupt zu solchen Tastenkombinationen?
less /usr/src/linux/Documentation/sysrq.txt CU, Th.
Thomas Hertweck schrieb:
Manfred Rebentisch wrote:
Am Donnerstag, 6. April 2006 16:30 schrieb David Haller:
ein 'mount -o ro,remount' (oder so) ausfuehrt... Aehm, du bist nicht zufaellig auf 'sysrq + u' (also Strg+Alt+Druck+u) gekommen?
hm, was bewirkt das? Und weißt Du, wo Infos dazu stehen bzw. überhaupt zu solchen Tastenkombinationen?
less /usr/src/linux/Documentation/sysrq.txt
Ich habe diese Kombination ganz bestimmt nicht bewusst ausgeführt (und wenn ich mir die Lage der Tasten anschaue, bin ich mir ganz sicher, dass ich mich an diesen 'Klammergriff' erinnern würde). Ferner kann ich ausschließen, dass diese Tastenkombination über ein Script, Icon, etc. ausgeführt wird: Neben der /-Partition ist mindestens noch meine /home-Partition gemounted. Deren Status ändert sich nicht! Uwe
Hallo, Am Fri, 07 Apr 2006, Uwe Diederich schrieb:
Thomas Hertweck schrieb:
Manfred Rebentisch wrote:
Am Donnerstag, 6. April 2006 16:30 schrieb David Haller:
ein 'mount -o ro,remount' (oder so) ausfuehrt... Aehm, du bist nicht zufaellig auf 'sysrq + u' (also Strg+Alt+Druck+u) gekommen? [..] Ich habe diese Kombination ganz bestimmt nicht bewusst ausgeführt (und wenn ich mir die Lage der Tasten anschaue, bin ich mir ganz sicher, dass ich mich an diesen 'Klammergriff' erinnern würde). Ferner kann ich ausschließen, dass diese Tastenkombination über ein Script, Icon, etc. ausgeführt wird: Neben der /-Partition ist mindestens noch meine /home-Partition gemounted. Deren Status ändert sich nicht!
Aber das 'mount'/'remount' koennte in nem script stehen. Achso: auf Konsole 10 und 8 steht auch nix? dmesg? Dann waere es tatsaechlich mal ne Idee auf ner anderen Partition zu loggen. Das umstellen solltest du im initlevel S machen: init S mkdir -p /home/var/log cd /home/var/log ls /var/log/ | grep -v '\.gz' | xargs touch cd / rcsyslog stop mv -i /var/log /var/log.org && ln -s /home/var/log /var/log rcsyslog start init 3 So muesste das ungefaehr klappen. -dnh -- Disarmament separates you from your phallic substitute. Walking around nude shows the world why you need one. -- The Usenet Oracle
David Haller schrieb:
Aber das 'mount'/'remount' koennte in nem script stehen. Achso: auf Konsole 10 und 8 steht auch nix? dmesg? Zu meiner Schande muss ich gestehen dort nicht nachgesehen zu haben. Bei mir läuft display_messages, das mir das log auf dem Hintergrund anzeigt. Im allgemeiner sehr brauchbar, um das System im Auge zu behalten. In diesem besonderen Fall habe ich allerdings nicht berücksichtigt, das dabei auch nur die Datei angezeigt wird, ähnlich einem tail -f. Dann waere es tatsaechlich mal ne Idee auf ner anderen Partition zu loggen. Das umstellen solltest du im initlevel S machen:
init S mkdir -p /home/var/log cd /home/var/log ls /var/log/ | grep -v '\.gz' | xargs touch cd / rcsyslog stop mv -i /var/log /var/log.org && ln -s /home/var/log /var/log rcsyslog start init 3
So muesste das ungefaehr klappen.
Ich habe das von einem Rettungssystem aus mit einem tar c quelle | (cd ziel; tar xv) und dem anschließend verlinken durchgeführt. Der dann erforderliche reboot hat den grundsätzlichen Fehler an dieser Idee sofort deutlich gemacht: Während des Systemstarts wird bereits zu einem sehr frühen Zeitpunkt auf Dateien im var-Verzeichnis zugegriffen. Die home-Partition ist dann noch nicht gemounted. Da auch der remount nicht zu funktionieren scheint, wären selbst bei einem ständig laufendem Rechner erhebliche Maßnahmen an einem nicht sauber heruntergefahrenen System notwendig, ehe er wieder gestartet werden kann. Daher sehe ich das nicht für ein wirklich praktikable Verfahren an. Ich werde also auf die Ausgabe von Konsole 10 zurückgreifen müssen. Uwe
Hallo, Am Sat, 08 Apr 2006, Uwe Diederich schrieb:
und dem anschließend verlinken durchgeführt. Der dann erforderliche reboot hat den grundsätzlichen Fehler an dieser Idee sofort deutlich gemacht: Während des Systemstarts wird bereits zu einem sehr frühen Zeitpunkt auf Dateien im var-Verzeichnis zugegriffen. Die home-Partition ist dann noch nicht gemounted.
Prinzipiell geht das schon, bei mir ist /var/ nicht auf der /-Partition: ==== /var/log/boot.msg ==== <6>kjournald starting. Commit interval 5 seconds <6>EXT3-fs: mounted filesystem with ordered data mode. <4>VFS: Mounted root (ext3 filesystem) readonly. <6>Freeing unused kernel memory: 304k freed <6>Adding Swap: 530136k swap-space (priority 666) <6>Adding Swap: 530136k swap-space (priority 666) <6>EXT3 FS 2.4-0.9.19, 19 August 2002 on ide1(22,5), internal journal <6>kjournald starting. Commit interval 5 seconds <6>EXT3 FS 2.4-0.9.19, 19 August 2002 on ide1(22,8), internal journal <6>EXT3-fs: mounted filesystem with ordered data mode. <6>kjournald starting. Commit interval 5 seconds <6>EXT3 FS 2.4-0.9.19, 19 August 2002 on ide1(22,9), internal journal <6>EXT3-fs: mounted filesystem with ordered data mode. [..] <6>EXT3-fs: mounted filesystem with ordered data mode. Kernel logging (proc) stopped. Kernel log daemon terminating. ==== ide1(22,9) ist /dev/hdc9 und die Partition auf der /var/ liegt. Auf der Konsole folgt erst dann "creating /var/log/boot.msg", was bei mir der erste Zugriff auf /var/ ist. Mein System basiert aber auf einer SuSE 6.2 / Kernel 2.4.25 und es kann sein, dass es bei neueren SuSEn schon frueher zu Zugriffen kommt, aber bei der 9.1 scheint dies nicht der Fall zu sein. Achso: wenn du in den initlevel S bootest, dann werden ausser der /-Partition _keine_ Partitionen gemounted, dann kommt es natuerlich zu Fehlermeldungen wenn /var/ auf ner anderen Partition liegt. Im Normalbetrieb (initlevel 1-5) werden die Partitionen mit 'auto' in der fstab aber ja gemounted und dann sollte es klappen -- ich kenne aber die aktuellen SuSEn nicht.
Da auch der remount nicht zu >funktionieren scheint,
Woran machst du das fest? Weil 'mount' das nicht ausgibt? Nimm 'cat /proc/mounts' wenn du wissen willst, was wie wo gemounted ist.
Ich werde also auf die Ausgabe von Konsole 10 zurückgreifen müssen.
Das kann / sollte man zusaetzlich. Und auch auf Konsole 8 sollte man
nen Blick werfen. Mach z.B. mal SysRq + s und schau auf tty8.
-dnh
--
"Being disintegrated makes me ve-ry an-gry!"
David Haller schrieb:
Hallo,
Am Sat, 08 Apr 2006, Uwe Diederich schrieb:
und dem anschließend verlinken durchgeführt. Der dann erforderliche reboot hat den grundsätzlichen Fehler an dieser Idee sofort deutlich gemacht: Während des Systemstarts wird bereits zu einem sehr frühen Zeitpunkt auf Dateien im var-Verzeichnis zugegriffen. Die home-Partition ist dann noch nicht gemounted.
Prinzipiell geht das schon, bei mir ist /var/ nicht auf der /-Partition:
==== /var/log/boot.msg ==== <6>kjournald starting. Commit interval 5 seconds <6>EXT3-fs: mounted filesystem with ordered data mode. <4>VFS: Mounted root (ext3 filesystem) readonly. <6>Freeing unused kernel memory: 304k freed <6>Adding Swap: 530136k swap-space (priority 666) <6>Adding Swap: 530136k swap-space (priority 666) <6>EXT3 FS 2.4-0.9.19, 19 August 2002 on ide1(22,5), internal journal <6>kjournald starting. Commit interval 5 seconds <6>EXT3 FS 2.4-0.9.19, 19 August 2002 on ide1(22,8), internal journal <6>EXT3-fs: mounted filesystem with ordered data mode. <6>kjournald starting. Commit interval 5 seconds <6>EXT3 FS 2.4-0.9.19, 19 August 2002 on ide1(22,9), internal journal <6>EXT3-fs: mounted filesystem with ordered data mode. [..] <6>EXT3-fs: mounted filesystem with ordered data mode. Kernel logging (proc) stopped. Kernel log daemon terminating. ====
ide1(22,9) ist /dev/hdc9 und die Partition auf der /var/ liegt.
Soweit ich mich erinnere bietet YaST während der Installation auch an, /var auf eine andere Partition zu verlegen (allerdings nicht in ein Verzeichnis auf eine andere Partition).
Auf der Konsole folgt erst dann "creating /var/log/boot.msg", was bei mir der erste Zugriff auf /var/ ist.
Mein System basiert aber auf einer SuSE 6.2 / Kernel 2.4.25 und es kann sein, dass es bei neueren SuSEn schon frueher zu Zugriffen kommt, aber bei der 9.1 scheint dies nicht der Fall zu sein.
Achso: wenn du in den initlevel S bootest, dann werden ausser der /-Partition _keine_ Partitionen gemounted, dann kommt es natuerlich zu Fehlermeldungen wenn /var/ auf ner anderen Partition liegt. Im Normalbetrieb (initlevel 1-5) werden die Partitionen mit 'auto' in der fstab aber ja gemounted und dann sollte es klappen -- ich kenne aber die aktuellen SuSEn nicht.
Ich habe in meinem Grub-Menü zwei Einträge: Der eine startet das System im Default-Runlevel, der in der inittab festgelegt ist. Das ist bei mir 5. Der zweite ist auf runlevel 1 fest verdrahtet (ggf. für Wartung, Reparatur, etc.). Wenn ich var nach /home/var auslagere, dann startet Linux eine Konsole, die mich zur Eingabe des /root-Passwortes /*und* die ich nur via Control-D wieder verlassen (=reboot) kann. Das dürfte der initlevel S sein.
Da auch der remount nicht zu >funktionieren scheint,
Woran machst du das fest? Weil 'mount' das nicht ausgibt? Nimm 'cat /proc/mounts' wenn du wissen willst, was wie wo gemounted ist.
mount - das habe ich bereits gelernt - scheint nur dazu nützlich, um anzuzeigen, welche Partition eingebunden sind und wie sie ursprünglich gemounted wurden. Hier zeigte aber auch /proc/mounts immer noch ro an. Auch ein touch auf eine Datei in diesem Verzeichnisbaum schlug fehl, weil read-only. Andererseits kann ich einen logischen Fehler im Aufruf von remount nicht ausschließen, der zum einen keine Fehlermeldung hervorruft, zum anderen aber auch nicht wirlich das tat, was ich wollte.
Ich werde also auf die Ausgabe von Konsole 10 zurückgreifen müssen.
Das kann / sollte man zusaetzlich. Und auch auf Konsole 8 sollte man nen Blick werfen. Mach z.B. mal SysRq + s und schau auf tty8.
Auf meiner Konole 8 sehe ich nur einen einsamen Cursor blinken. Ein SysRq + s (Crtl+Alt+Druck+s?) zeigt keine Wirkung. Auch meine /etc/syslog.conf enthält keinen Eintrag für tty8. Fehlt da vielleicht eine Zeile? Uwe
Hallo, Am Sun, 09 Apr 2006, Uwe Diederich schrieb:
David Haller schrieb: [..] Ich habe in meinem Grub-Menü zwei Einträge: Der eine startet das System im Default-Runlevel, der in der inittab festgelegt ist. Das ist bei mir 5. Der zweite ist auf runlevel 1 fest verdrahtet (ggf. für Wartung, Reparatur, etc.). Wenn ich var nach /home/var auslagere, dann startet Linux eine Konsole, die mich zur Eingabe des /root-Passwortes /*und* die ich nur via Control-D wieder verlassen (=reboot) kann. Das dürfte der initlevel S sein.
Jep. Merkmal ist eben auch, dass nur die /-Partition und nur read-only gemounted wird, daher kann die /etc/mtab nicht aktualisiert werden und somit zeigt mount was falsches an.
mount - das habe ich bereits gelernt - scheint nur dazu nützlich, um anzuzeigen, welche Partition eingebunden sind und wie sie ursprünglich gemounted wurden. Hier zeigte aber auch /proc/mounts immer noch ro an.
Auch nach einem 'mount -o rw,remount /'? Das waere dann sehr eigenartig.
Das kann / sollte man zusaetzlich. Und auch auf Konsole 8 sollte man nen Blick werfen. Mach z.B. mal SysRq + s und schau auf tty8.
Auf meiner Konole 8 sehe ich nur einen einsamen Cursor blinken. Ein SysRq + s (Crtl+Alt+Druck+s?) zeigt keine Wirkung.
Normal ist der SysRq-Key die in DE mit "Druck" und S-Abfr(!) beschriftete Taste (also ja: Strg+Alt+Druck+s). Ausserdem muss aber auch noch sysrq aktiviert werden, keine Ahnung, was SUSE da inzwischen voreinstellt. # cat /proc/sys/kernel/sysrq 1 Bei Kernel 2.6 ist das wohl nun unter /sys/kernel/sysrq? Aktivieren kann man mit sysctl oder einem einfachen echo 1 > [/proc]/sys/kernel/sysrq Wenn man's dauerhaft haben will (was IMO sinnvoll ist) stellt man das bei neueren SUSE sinnvollerweise in /etc/sysconfig/sysctl ein: ENABLE_SYSRQ="yes" Dann sollte ein SysRq+s auf tty8 eine Ausgabe wie: SysRq : Emergency Sync Syncing device 16:05 ... OK [..] Syncing device 03:4a ... OK Done. bewirken.
Auch meine /etc/syslog.conf enthält keinen Eintrag für tty8. Fehlt da vielleicht eine Zeile?
Noe. Mit dem syslog hat das garnix zu tun. -dnh -- Nature and nature's laws lay hid in night, God said, "Let Newton be," and all was light. It did not last; the devil howling "Ho! Let Einstein be!" restored the status quo.
David Haller schrieb:
Hallo,
Am Sun, 09 Apr 2006, Uwe Diederich schrieb:
David Haller schrieb:
[..]
mount - das habe ich bereits gelernt - scheint nur dazu nützlich, um anzuzeigen, welche Partition eingebunden sind und wie sie ursprünglich gemounted wurden. Hier zeigte aber auch /proc/mounts immer noch ro an.
Auch nach einem 'mount -o rw,remount /'? Das waere dann sehr eigenartig.
Deshalb vermute ich, dass ich einen Fehler bei Eintippen gemacht habe, der allerdings nicht zu einer entsprechenden Fehler - weil syntaktisch korrekt - führte. Leider lässt sich sich das nicht durch die History überprüfen.
Das kann / sollte man zusaetzlich. Und auch auf Konsole 8 sollte man nen Blick werfen. Mach z.B. mal SysRq + s und schau auf tty8.
Auf meiner Konole 8 sehe ich nur einen einsamen Cursor blinken. Ein SysRq + s (Crtl+Alt+Druck+s?) zeigt keine Wirkung.
Normal ist der SysRq-Key die in DE mit "Druck" und S-Abfr(!) beschriftete Taste (also ja: Strg+Alt+Druck+s). Ausserdem muss aber auch noch sysrq aktiviert werden, keine Ahnung, was SUSE da inzwischen voreinstellt.
# cat /proc/sys/kernel/sysrq 1
Bei Kernel 2.6 ist das wohl nun unter /sys/kernel/sysrq?
Aktivieren kann man mit sysctl oder einem einfachen echo 1 > [/proc]/sys/kernel/sysrq
Wenn man's dauerhaft haben will (was IMO sinnvoll ist) stellt man das bei neueren SUSE sinnvollerweise in /etc/sysconfig/sysctl ein:
ENABLE_SYSRQ="yes"
Hab' ich geändert und werde in Zukunft öfter einmal einen Blick darauf werfen. Nachdem ich jetzt am Wochenende noch einmal ein fsck -f auf die widerborstige Partition losließ, ist der Fehler nicht mehr aufgetreten. Der Test fand einige defekte inodes. Ob dieser die Ursache oder nur eine Folge aus nicht richtig durchgeführte Shutdonws waren, kann ich nicht sagen. Daher möchte ich auch noch keine Entwarnung geben, sondern das Verhalten des System erst einmal kritisch beobachten. Standby... Vielen Dank an Dich, David, und an alle anderen, für Ihre Hilfe. Mit freundlichen Grüssen. Uwe Diederich
David Haller schrieb:
[..]
Daher meine dringende Bitte um Hilfe an Euch: Kenne jemand das beschriebene Verhalten? Was ist die Ursache und wie - viel wichtiger - kann ich den Fehler beseitigen?
Da faellt mir erstmal auch nix ein, ausser, dass vielleicht irgendwas ein 'mount -o ro,remount' (oder so) ausfuehrt... Aehm, du bist nicht zufaellig auf 'sysrq + u' (also Strg+Alt+Druck+u) gekommen?
Irgendwas in /var/log/{warn,messages}?
Leider nicht, aber das ist auch weiter nicht verwunderlich, da dieser Zweig sich auch in dem betroffenen Bereich befindet. Eine Möglichkeit wäre, das log-Verzeichnis temporär auf eine andere Partition auszulagern und dann zu warten, bis der Fehler wieder auftritt. Uwe
* Uwe Diederich schrieb:
mit dem root-Verzeichnisbaum ("/") zu schreiben. Diese Verzeichnisstruktur enthält mit Ausnahmen von /home alle Datenbestände des Systems.
Dann poste doch mal /var/log/messages! Dort stehen dann ja alle Meldungen bis zum ro von / drinnen. Sind die Meldungen immer die gleichen bis zum Stillstand? Außerdem poste mal dmesg, zumindest die letzen 30 Zeilen. Ekkard
Ekkard Gerlach schrieb:
* Uwe Diederich schrieb:
mit dem root-Verzeichnisbaum ("/") zu schreiben. Diese Verzeichnisstruktur enthält mit Ausnahmen von /home alle Datenbestände des Systems.
Dann poste doch mal /var/log/messages! Dort stehen dann ja alle Meldungen bis zum ro von / drinnen. Sind die Meldungen immer die gleichen bis zum Stillstand? Außerdem poste mal dmesg, zumindest die letzen 30 Zeilen.
Ekkard
Ich bin der Anregung und Dr. Jürgen Vollmer gefolgt, noch einmal ein fsck durchzuführen. Seither ist das Problem nicht mehr aufgetreten. Ob die Ursache dadurch beseitigt wurde, weiß ich nicht. Falls nicht, werde ich mich noch einmal melden und dann den entsprechenden Abschnitt der messages und dmesg posten. Ich danke für deine Hilfe. Mit freundlichen Grüßen. Uwe Diederich
participants (6)
-
David Haller -
Dr. Jürgen Vollmer -
Ekkard Gerlach -
Manfred Rebentisch -
Thomas Hertweck -
Uwe Diederich