kein su möglich: su: pam_start: system error

crotchmaster

crotchmaster

happy BSD user
Hallo Forenleser,

ich habe hier eine Maschine, bei der ich als User, der Mitglied von wheel ist, nicht mehr zum root-User mittels su wechseln kann. Ein Login mit SSH klappt noch.

Beim su erhalte ich:

Code: 
[user@server ~]$ su - root
su: pam_start: system error

In /var/log/messages habe ich folgendes gefunden:

Code: 
Jan 25 18:13:15 server su: in openpam_load_module(): no pam_unix.so found
Jan 25 18:13:15 server su: pam_start: system error
Jan 25 18:21:05 server su: in openpam_load_module(): no pam_unix.so found
Jan 25 18:21:05 server su: pam_start: system error
Jan 25 18:30:22 server su: in openpam_load_module(): no pam_unix.so found
Jan 25 18:30:22 server su: pam_start: system error
Jan 25 18:33:46 server su: in openpam_load_module(): no pam_unix.so found
Jan 25 18:33:46 server su: pam_start: system error
Jan 25 18:34:03 server su: in openpam_load_module(): no pam_unix.so found
Jan 25 18:34:03 server su: pam_start: system error

Der Link /usr/lib/pam_unix.so und die Lib /usr/lib/pam_unix.so.3 selber existieren und sind soweit ok.

Das System lief lange problemlos. Heute Nacht ist die Maschine nach einem Crash neugestartet. Unmittelbar vor dem Crash waren folgende Meldungen in /var/log/messages:
Code: 
Jan 25 03:48:07 server kernel: twed0: controller error - device failure (flags = 0x40)
Jan 25 03:48:07 server kernel: GEOM_ELI: g_eli_read_done() failed twed0s1g.eli[READ(offset=720841654272, length=16384)]
Jan 25 03:48:07 server kernel: g_vfs_done():label/jails[READ(offset=720841654272, length=16384)]error = 5
Jan 25 03:53:26 server kernel: twed0: controller error - device failure (flags = 0x40)
Jan 25 03:53:26 server kernel: GEOM_ELI: g_eli_read_done() failed twed0s1g.eli[READ(offset=720493920256, length=16384)]
Jan 25 03:53:26 server kernel: g_vfs_done():label/jails[READ(offset=720493920256, length=16384)]error = 5
Jan 25 03:56:09 server kernel: twed0: controller error - device failure (flags = 0x40)
Jan 25 03:56:09 server kernel: GEOM_ELI: g_eli_read_done() failed twed0s1g.eli[READ(offset=720841670656, length=16384)]
Jan 25 03:56:09 server kernel: g_vfs_done():label/jails[READ(offset=720841670656, length=16384)]error = 5
Jan 25 03:57:08 server kernel: twed0: controller error - device failure (flags = 0x40)
Jan 25 03:57:08 server kernel: GEOM_ELI: g_eli_read_done() failed twed0s1g.eli[READ(offset=720841654272, length=16384)]
Jan 25 03:57:08 server kernel: g_vfs_done():label/jails[READ(offset=720841654272, length=16384)]error = 5

Danach war das HW RAID-1 (3ware Controller) degraded. Ich habe mit tw_cli einen rebuild angestoßen. Die pam-Probleme gingen mit dem Verlassen von tw_cli los. Bei dem System handelt es sich um ein FreeBSD 6.3-RELEASE-p3 auf i386.

Ich bin mit meinem Latein am Ende und hoffe Ihr könnt mir noch einen Tipp geben.
 
Code: 
[user@server ~]$ ldd /usr/lib/pam_unix.so
/usr/lib/pam_unix.so:
        libutil.so.5 => /lib/libutil.so.5 (0x28169000)
        libcrypt.so.3 => /lib/libcrypt.so.3 (0x28175000)
        libypclnt.so.2 => /usr/lib/libypclnt.so.2 (0x2818d000)
        libpam.so.3 => /usr/lib/libpam.so.3 (0x28191000)
Da ich ein zweites, indentisches System habe, habe ich mal auf beiden Systemen mit md5 die Prüfsummen verglichen. Bis auf die libypclnt.so.2 sind sie identisch. Die Größe und das Datum der libypclnt.so.2 sind aber gleich auf beiden Systemen. Sieht so aus, als ob die einen weg hat. Da das heute ja noch ging, ist da wohl etwas mit dem Plattensystem im argen.

Gruß c.
 
Mein Tipp wäre ein defekter Controller oder ein Problem mit einer Platte, was er nicht sieht. Theoretisch können auch die Kabel und / oder die Backplane schuld sein... Man weiß es nicht und es wird eine schwierige Suche werden.

Deine Daten kannst du zumindest vergessen. Da hat wer irgendwelchen Müll ins Dateisystem geschrieben, bzw. Daten sind an der falschen Stelle gelandet. UFS + GELI kann es ohne GELIs Hashmechanismus nicht erkennen, den nutzt du aber sicher nicht... Hilft also nur das Rückspielen eines Backups oder - wenn da keine Nutzdaten drauf waren - ein Neuinstallieren der Welt und aller Ports. Bei den Ports mag dir pkg_validate aus Kamikazes bsdadminscripts helfen. :)
 
Heute morgen konnte ich sehen, dass der rebuild nicht klappte und der Controller einen drive error meldete. Ich habe nun einen Check des Controllers und der Platten veranlasst. Funktionierende Backups habe ich, nur die Arbeit und die damit verbundene Zeit hätte ich mir gerne erspart, da ich an einem Projekt arbeite, das am Freitag fertig werden soll und ich so schon nicht weiß, wie ich das schaffen soll. Und nun das noch. Shit happens kann ich da nur sagen.

Danke für Eure Hilfe.

Gruß c.
 
So Problem ist nach einer Tauschorgie inzwischen gelöst. Zuerst wurde die defekte HDD getauscht, als das nicht half, wurden der Controller und die Backplane getauscht, half auch nicht. Dann wurde nochmal die defekte HDD getauscht, mit dem Ergebnis, das es auch nichts half, und schließlich wurde die eigentlich heile HDD getauscht und nun ist das RAID wieder ok.

Gruß c.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben