Hallo,
ein Bekannter arbeitet mit LaTeX und CVS. Er hat sich irgendwann ein SuSE 8.2 eingerichtet und dabei die Systemplatte mit ReiserFS formatiert. Um die Jahreswende ist darauf ein Fehler aufgetreten und der Rechner bootete nicht mehr. Er hatte leider auch das /home- Verzeichnis auf der selben Partition liegen.
Was er selbst daran versucht hat, kann ich nicht sagen. Er sagte etwas von einem SuSE-rescue-System, aber damit hat es nicht funktioniert.
Ich habe den Rechner mit einer KNOPPIX-CD gebootet und man konnte dann auch die Platte mounten. Somit konnten wir sein CVS-Verzeichnis und auch alle Benutzerdaten auf einen anderen Rechner kopieren. Erst danach habe ich mit dem reiserfsck einen Check und danach die Reparatur des Filesystems durchgefuehrt. Die Fehler wurden mit der Option --rebuild-tree behoben und seitdem zeigt reiserfsck --check keine Fehler mehr an (alle Angaben beziehen sich auf ein gebootetes KNOPPIX).
Nun bootet der Rechner auch wieder.
Leider kann man sich auf dem Rechner nicht anmelden. Egal, was man fuer einen Benutzernamen versucht, es kommt immer die Meldung "incorrect login". Auch von aussen ist es nicht moeglich, sich per Netz anzumelden. Woran kann das liegen? Was kann ich versuchen?
Wenn der Rechner neu aufgesetzt werden muss: Wie kann ich am besten die physisch gesicherten CVS-Daten wieder verfuegbar machen?
vielen Dank, Stefan
.
On Mon, Jan 12, 2004 at 08:52:08AM +0100, Stefan Lagotzki wrote:
Hallo,
Leider kann man sich auf dem Rechner nicht anmelden. Egal, was man fuer einen Benutzernamen versucht, es kommt immer die Meldung "incorrect login". Auch von aussen ist es nicht moeglich, sich per Netz anzumelden. Woran kann das liegen? Was kann ich versuchen?
Na - sind denn /etc/passwd /etc/shadow & Co noch vorhanden? Unter Knoppix kannste doch draufgucken. Eventuell auch andere Files aus /etc (pam.d, ...)?
Wenn der Rechner neu aufgesetzt werden muss: Wie kann ich am besten die physisch gesicherten CVS-Daten wieder verfuegbar machen?
?? Draufkopieren?
Heiko
/me:
Wenn der Rechner neu aufgesetzt werden muss: Wie kann ich am besten die physisch gesicherten CVS-Daten wieder verfuegbar machen?
Heiko Schlittermann wrote:
?? Draufkopieren?
Ja, danke, ich habe jetzt noch mal nach den Systemvariablen (hier: CVSROOT) geschaut. Hatte ich mir komplizierter vorgestellt.
Stefan
.
Hi!
Am 2004-01-12 8:52 +0100 schrieb Stefan Lagotzki:
Leider kann man sich auf dem Rechner nicht anmelden. Egal, was man fuer einen Benutzernamen versucht, es kommt immer die Meldung "incorrect login". Auch von aussen ist es nicht moeglich, sich per Netz anzumelden. Woran kann das liegen? Was kann ich versuchen?
Hier kann man natürlich wirklich nur im Trüben stochern. Ich würde mir erstmal anschauen, ob /etc/passwd und /etc/shadow plausibel aussehen, ob /etc/nologin nicht vorhanden ist (das sollte eigentlich so sein) und dann mal das root-Passwort neu setzen. Das geht entweder so:
- booten mit "linux init=/bin/bash" - mount -o remount,rw / - passwd
oder mit einer Knoppix-CD, dann root-Partition mounten, da hinein chrooten und dann passwd.
Wenn dann root-Login wieder möglich ist, hat es Dir nur die Passwörter zerschossen. Wenn nicht, dann liegt es wohl eher an der PAM-Konfiguration. Evtl. ist irgendein PAM-Modul (in /lib/security/*.so) oder /etc/pam.d/* zerschossen. Da könnte man in einer root-shell das PAM-Paket neu installieren.
Mehr fällt mir spontan jetzt auch nicht ein, da müsste man davorsitzen.
Viel Glück!
Pitti
Martin Pitt wrote:
Hier kann man natürlich wirklich nur im Trüben stochern. Ich würde mir erstmal anschauen, ob /etc/passwd und /etc/shadow plausibel aussehen,
Die /etc/passwd ist in Ordnung. Die /etc/shadow *scheint* in Ordnung zu sein. Ich muss dazu sagen, dass wir beide auf einem bestimmten Stand (vom Herbst 2003) gefunden und wiederhergestellt haben. Datum und Zeit waren identisch. Die Originaldateien waren nicht mehr vorhanden, sondern es lagen nur eine /etc/passwd- und eine /etc/shadow- vor. Die waren aber kaputt.
ob /etc/nologin nicht vorhanden ist (das sollte eigentlich so sein)
Das muss ich nachsehen. Das kann ja aber eigentlich niemand dort hineingeschrieben haben.
Wenn dann root-Login wieder möglich ist, hat es Dir nur die Passwörter zerschossen. Wenn nicht, dann liegt es wohl eher an der PAM-Konfiguration. Evtl. ist irgendein PAM-Modul (in /lib/security/*.so) oder /etc/pam.d/* zerschossen. Da könnte man in einer root-shell das PAM-Paket neu installieren.
Danke fuer den Hinweis.
Stefan
.
On Mon, Jan 12, 2004 at 10:23:16AM +0100, Stefan Lagotzki wrote:
Martin Pitt wrote:
Hier kann man natürlich wirklich nur im Trüben stochern. Ich würde mir erstmal anschauen, ob /etc/passwd und /etc/shadow plausibel aussehen,
Die /etc/passwd ist in Ordnung. Die /etc/shadow *scheint* in Ordnung zu sein. Ich muss dazu sagen, dass wir beide auf einem bestimmten Stand (vom Herbst 2003) gefunden und wiederhergestellt haben. Datum und Zeit waren identisch. Die Originaldateien waren nicht mehr vorhanden, sondern es lagen nur eine /etc/passwd- und eine /etc/shadow- vor. Die waren aber kaputt.
ok, ein reiserfs Fehler. Ich gehe mal davon aus, daß du kein Log vom reiserfsck --rebuild-tree hast, aber du kannst mal schauen, was so im Verzeichnis /lost+found 'rumliegt. Die Dateien dort haben nicht mehr den richtigen Namen, aber evtl. noch den richtigen Inhalt. passwd und shadow würde ich mit "grep ^root: /lost+found/*" suchen, auch das Login deines Freundes ist ein guter Suchansatz.
Ansonsten kannst du mittels "rpm -Va 2>&1 | tee /tmp/rpm-V-log" mal schauen, bei welchen Dateien "missing" steht, die entsprechenden Pakete dann evtl. neu installieren. Achtung, nach einem rebuild-tree kann es auch passieren, daß Dateien zwar noch da sind, aber mit ungültigem Inhalt (typischerweise Null- Bytes).
Wenn du meine Meinung hören willst: wenn du alle wichtigen Daten sichern konntest, dann installiert neu und spielt das backup wieder ein. So ein Filesystemfehler hinterlässt meiner Erfahrung nach oft Spuren, die sich erst mit der Zeit unangenehm bemerkbar machen.
Viel Glück :-)
Hallo Stefan,
ich bin jetzt nicht in Verbindung mit diesem Rechner, aber alle Logdateien des reiserfsck (Kontrolle und Reparatur) habe ich mir natuerlich mit KNOPPIX auf einen anderen Rechner gesichert. Nur reingeschaut hatte ich am Freitag nicht. --> ich werde berichten, was wir letztlich gemacht haben :-)
Stefan
.
On Tue, Jan 13, 2004 at 11:55:01AM +0100, Stefan Lagotzki wrote:
Hallo Stefan,
ich bin jetzt nicht in Verbindung mit diesem Rechner, aber alle Logdateien des reiserfsck (Kontrolle und Reparatur) habe ich mir natuerlich mit KNOPPIX auf einen anderen Rechner gesichert. Nur reingeschaut hatte ich am Freitag nicht. --> ich werde berichten, was wir letztlich gemacht haben :-)
ok, im Log steht drin, in welchen Verzeichnissen Fehler gefunden wurden und die dazugehörigen inode-Nummern (ich weiss, daß reiserfs keine inodes hat, aber es werden irgendwelche Nummern angezeigt), mit denen du dann die Files aus lost+found leichter wieder zuordnen kannst.
Aber: Wenn die wichtigen Daten ($HOME) gesichert werden konnten, würde ich auf jeden Fall neu installieren oder zumindest komplettes Backup -> mkfs -> restore, denn einem Journaling-Filesystem, das einmal so einen Hau weg hatte, würde ich aus leidvoller Erfahrung nicht mehr so richtig über den Weg trauen. Ich habe da meine schlechten Erfahrungen sowohl mit reiserfs als auch mit ext3 gemacht. Ein Symptom war, daß ich das Gefühl hatte, daß die Filesysteme nach solch schweren Fehlern dann so vor sich hin "verrotteten", daß immer öfter "seltsame und unerklärliche Phänomene" auftraten. Das läßt sich schwer in wenigen Worten beschreiben, aber ein beherztes "mkfs" hat die ganzen seltsamen Erscheinungen (von seltsamen Kernel oopses bis zu plötzlich verschwindenden Dateien) typischerweise beendet.
Viel Glück :-)
Am Mittwoch, 14. Januar 2004 08:51 schrieb Stefan Seyfried:
Wenn die wichtigen Daten ($HOME) gesichert werden konnten, würde ich auf jeden Fall neu installieren oder zumindest komplettes Backup -> mkfs -> restore, denn einem Journaling-Filesystem, das einmal so einen Hau weg hatte, würde ich aus leidvoller Erfahrung nicht mehr so richtig über den Weg trauen. Ich habe da meine schlechten Erfahrungen sowohl mit reiserfs als auch mit ext3 gemacht. Ein Symptom war, daß ich das Gefühl hatte, daß die Filesysteme nach solch schweren Fehlern dann so vor sich hin "verrotteten", daß immer öfter "seltsame und unerklärliche Phänomene" auftraten. Das läßt sich schwer in wenigen Worten beschreiben, aber ein beherztes "mkfs" hat die ganzen seltsamen Erscheinungen (von seltsamen Kernel oopses bis zu plötzlich verschwindenden Dateien) typischerweise beendet.
ACK. Kann das mit ReiserFS _voll_ bestädigen. (Mit ext3 hatte hatte ich bisher noch nicht das "Vergnügen"). Es bringt auch nicht's alle Programm drüber zu installieren. So was in der Art rpm -qa | rpm -i --force bringt dir deine Programmdateien zurück. Das musst du jeden zweiten Tag wiederholen. Auf Dauer macht das keinen wirklichen Spaß.
Viel Glück :-)
Kann er gebrauchen. Besonders wenn er deinen Rat missachtet.
Jens
Hallo Jens und Stefan,
vielen Dank fuer Eure guten Wuensche, der Besitzer des Rechners wird SuSE neu aufsetzen. Wir waren zwar heute soweit, dass man sich wieder einloggen konnte (es hat eine der libcrypt.* - Dateien gefehlt und wir haben auch noch 'pam' neu installiert. Aber wir merkten dann, dass auch etliche Module nicht mehr richtig geladen wurden. Es war also ziemlich kaputt. Leider konnte ich ihn nicht von Debian ueberzeugen :-) Mit ext3 auf der Systemplatte habe ich noch keine schlechten Erfahrungen gemacht, auch nach Stromausfaellen funktionierte die Systemplatte in sehr kurzer Zeit nach dem erneuten Booten wieder ordentlich. Ich lege immer /home auf eine extra Partition.
Stefan
.
On Wed, Jan 14, 2004 at 08:01:23PM +0100, Stefan Lagotzki wrote:
vielen Dank fuer Eure guten Wuensche, der Besitzer des Rechners wird SuSE neu aufsetzen. Wir waren zwar heute soweit, dass man sich wieder einloggen konnte (es hat eine der libcrypt.* - Dateien gefehlt und wir haben auch noch 'pam' neu installiert. Aber wir merkten dann, dass auch etliche Module nicht mehr richtig geladen wurden. Es war also ziemlich kaputt.
Ja, in so einem Fall ist neu installieren wirklich die beste Lösung. Online-Update nicht vergessen, damit der neueste Kernel verwendet wird, da evtl. darin auch Filesystem-Treiber gefixed sind.
Leider konnte ich ihn nicht von Debian ueberzeugen :-) Mit ext3 auf der Systemplatte habe ich noch keine schlechten Erfahrungen gemacht, auch nach Stromausfaellen funktionierte die Systemplatte in sehr kurzer Zeit nach dem erneuten Booten
Stromausfälle sind für journaling-Filesysteme typischerweise kein Problem, dafür wurden sie ja schliesslich gemacht :-). Kritischer sind Fehler an anderen Stellen im Kernel bzw. "leicht" kaputte Hardware. Da diese Filesysteme komplexer sind, geht da auch gerne mehr kaputt (ver- einfacht ausgedrückt :-) Ich habe z.B. an Weihnachten ein uraltes Parallell- port CDROM am 2.6.0 ausprobiert... naja, irgendwann half nur noch Ausschalten, der Treiber war wohl nicht soo 100%ig. Danach war das Filesystem reichlich kaputt. Das als Beispiel.
Ob ext3 oder reiser "besser" ist, mag ich nicht beurteilen. Ich hatte auch mit ext3 auf RedHat ähnliche Probleme (inodes, die einen Kernel-oops verursachten, wenn man darauf zugriff, auch ein fsck hat nicht wirklich geholfen). Ich verwende typischerweise das Filesystem, das von der Distribution als default vorgeschlagen wird, denn suse hat vermutlich mehr Tests mit reiserfs gemacht (die internen Maschinen laufen praktisch alle mit reiserfs), bei RedHat wird es wohl mit ext3 genauso sein. Des weiteren kommt es natürlich auf den Anwendungszweck an, einen News-Spool legt man besser auf reiserfs, weil das besser mit tausenden Dateien in einem Verzeichnis zurechtkommt, wenn es notwendig ist, die Platte mit einem alten Kernel zu booten, ist ext3 evtl. besser, denn das ist AFAIK abwärtskompatibel zu ext2.
wieder ordentlich. Ich lege immer /home auf eine extra Partition.
das ist sowieso klar, da ich regelmäßig (manchmal mehrmals pro Woche) Betaversionen probieren muss, habe ich sogar die wichtigsten Sachen (mutt, mplayer,...) statisch kompiliert in meinem $HOME/bin :-)
lug-dd@mailman.schlittermann.de
-
Heiko Schlittermann -
Jens Weisse -
Martin Pitt -
Stefan Lagotzki -
Stefan Seyfried