Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
festplattenkontrollerissues
das ein festplattencontroller im eimer ist, ist schon selten.
bei mir ist es schon das zweite mal, dass der controller das spinnen anfängt … 
ich hatte ja mal eine meiner 80er platten gegen ne baugleiche getauscht.
zwei/drei monate später musste ich ein hdd-password (?) beim bootscreen (??) angeben und ich hätte max. 5 versuche (???)
nach dem ich n mal resettet hab gings dann, 2h nach betrieb ist er immer mit einem ext3 fs error ausgestiegen (“can’t write journal …”)
das passierte andauernd und ging ziemlich auf die nerven, weswegen ich die alte wieder einbaute
und das dd-spiel (diesmal ohne gemountete partitionen, knoppix sei dank) wiederholte 
ok, das ging ca. ne woche gut, danach hat er die festplatte mal nicht erkannt, mal hatte die einen seltsamen ID-string <SEAGATE Axxxxx “”“”“”“”> (sic! die eckigen klammern begrenzen), öfters ist entweder lilo oder der kernel selbst beim booten (genauer: einhängen des rootfs) ausgestiegen … ab und zu funktioniert es … ein rumgeeier gr
das doofe: der kernel steigt beim mounten des root-fs aus, aber irgendwie auch nicht, denn wenn das passiert, dann ist der superblock des root-fs weg (bis jetzt 1:1 vfs-kernelpanic <=> kaputter superblock im rootfs). bis jetzt war alles behebbar.
was tun? ein neuer festplattencontroller und dann von dem booten?
lass dir doch mal so einen PCI-controller raus, sind glaub ich nicht sehr teuer, und teste mit dem…
btw wenn der Superblock im eimer ist, ist nicht so schlimm, also falls dir was an der entspr. partition gelegen ist…
Addendum: Wenn es am Controller liegt, wundert es mich, dass dein Kernel scheinbar keine entspr. Fehlermeldungen ausgibt.
Ich hatte schon ein paar Probleme mit Controllern und dmesg bzw. die Ausgabe auf der Konsole haben mir bei der Ursachenfindung weitergeholfen.
Das gilt btw. auch für Probleme, die mit der Festplatte direkt auftreten (davon kann ich seit kurzem ein Lied singen…)
naja, wenigstens funktioniert mit der alten platte die kiste wieder tagelang am stück, und nicht nur 2h.
dmesg scheint ja nur den eintrag vom aktuellen boot zu benutzen …
und wenn der kernel was dazu sagt, dann kann ich kein dmesg mehr eingeben 
naja, momentan mach ichs so: beim ersten start sofort ins bios-menü, dort fünf minuten warten (“warm werden lassen” ), dann bootet er normal. das kann natürlich kein dauerzustand sein …
danke fürs mitdenken.
also folgender stand: die neue konfiguration hat ebenfalls die macke gezeigt.
ich konnte die beiden 80er aber nicht einfach trennen, weil ich iio ein lvm über beide platten gespannt hatte.
glücklicherweise hatte ich noch ne alte kiste mit ner 3ten 80er platte (alle baugleich). also fix ein debian-testing druf (das vom linux-magazin special 3 - linux im netz), ssh+rsync installiert, und daten backupen.
mein echter rechner hat jetzt nur noch eine 80er platte, neuformatiert, debian ebenfalls neu installiert (ebenfalls fluxbox-user thx@FP für deine detaillierten ausführungen im anderen thread!). die platte hängt am primary slave, und es funzt alles 
die zweite 80er, die ursprünglich im rechner war, hab ich bei der gelegenheit auch in meine backup-kiste eingebaut. ein cron-job übernimmt die spiegelung der daten, so dass sie auf beiden platten liegen. hoffe, das macht sinn
:cheesy:
ende eines produktiven (?!) freitagnachmittags