Rechner "tot" - HD-LED leuchtet dauernd
Ich habe einen Fileserver, der seit Suse 8.1 Schwierigkeiten macht und zwar funktioniert der Rechner stundenlang normal und plötzlich ist der Rechner "abgestürzt", d.h. kein ping ist mehr möglich und die HD-LED leuchtet permanent. ext3 hat bis jetzt brav restauriert. :-) Es reicht nicht einmal die Reset-Taste am Rechner zu drücken, sondern man muß den Rechner am Netzteil ausschalten, damit er wieder hochfährt. Danach läuft er wieder ganz normal ohne Probleme. Gemerkt wurde das jedesmal, nachdem ein Zugriff via Samba nicht reagierte. Der PC enthält 3 HDs, eine 40GB, 60GB und 80GB HD, wobei ich noch nicht herausgefunden habe, aufgrund welcher HD die LED leuchtet. Albert
Am Montag, 4. November 2002 22:30 schrieb Al Bogner:
Ich habe einen Fileserver, der seit Suse 8.1 Schwierigkeiten macht und zwar funktioniert der Rechner stundenlang normal und plötzlich ist der Rechner "abgestürzt", d.h. kein ping ist mehr möglich und die HD-LED leuchtet permanent. ext3 hat bis jetzt brav restauriert.
:-) Es reicht nicht einmal die Reset-Taste am Rechner zu drücken,
sondern man muß den Rechner am Netzteil ausschalten, damit er wieder hochfährt. Danach läuft er wieder ganz normal ohne Probleme. Gemerkt wurde das jedesmal, nachdem ein Zugriff via Samba nicht reagierte. Der PC enthält 3 HDs, eine 40GB, 60GB und 80GB HD, wobei ich noch nicht herausgefunden habe, aufgrund welcher HD die LED leuchtet.
Albert
Hallo Albert, in einigen Konfigurationen mit mehreren IDE-Festplatten hat der Kernel von der 8.1 anscheinend einige Probleme. Über die Liste ging heute das der Kernel von ftp://ftp.suse.com/pub/people/mantel/ den Fehler behebt. Jörg -- Jörg Frings-Fürst 54526 Landscheid http://www.fixundfoxi.dydndns.info -- Registered Linux User # 280687 ICQ 170365098 GPG Key ID : EB8A FFC8 1314 12E1
On 04.11.2002 23:50, Joerg Frings-Fuerst wrote:
in einigen Konfigurationen mit mehreren IDE-Festplatten hat der Kernel von der 8.1 anscheinend einige Probleme. Über die Liste ging heute das der Kernel von
ftp://ftp.suse.com/pub/people/mantel/
Allerdings nur der in ftp://ftp.suse.com/pub/people/mantel/test/, also k_deflt-2.4.19-126.i586.rpm. Der andere in /next hat das selbe Problem... Ralf PS: Falls sich das heute nicht geändert hat.
On Dienstag, 5. November 2002 00:51 Ralf Ebeling wrote:
On 04.11.2002 23:50, Joerg Frings-Fuerst wrote:
in einigen Konfigurationen mit mehreren IDE-Festplatten hat der Kernel von der 8.1 anscheinend einige Probleme. Über die Liste ging heute das der Kernel von
ftp://ftp.suse.com/pub/people/mantel/
Allerdings nur der in ftp://ftp.suse.com/pub/people/mantel/test/, also k_deflt-2.4.19-126.i586.rpm. Der andere in /next hat das selbe Problem...
Also ist es sicherer den alten Kernel von Suse 8.0 zu installieren? Albert
Al Bogner wrote:
On Dienstag, 5. November 2002 00:51 Ralf Ebeling wrote:
On 04.11.2002 23:50, Joerg Frings-Fuerst wrote:
in einigen Konfigurationen mit mehreren IDE-Festplatten hat der Kernel von der 8.1 anscheinend einige Probleme. Über die Liste ging heute das der Kernel von
ftp://ftp.suse.com/pub/people/mantel/
Allerdings nur der in ftp://ftp.suse.com/pub/people/mantel/test/, also k_deflt-2.4.19-126.i586.rpm. Der andere in /next hat das selbe Problem...
Also ist es sicherer den alten Kernel von Suse 8.0 zu installieren?
Nein, der hat das gleiche Problem mit den IDE-Festplatten! CU, Th. -- Thomas Hertweck, Dipl.-Geophys. Geophysikalisches Institut, Universitaet Karlsruhe (TH)
On Dienstag, 5. November 2002 19:15 Thomas Hertweck wrote:
in einigen Konfigurationen mit mehreren IDE-Festplatten hat der Kernel von der 8.1 anscheinend einige Probleme. Über die Liste ging heute das der Kernel von
ftp://ftp.suse.com/pub/people/mantel/
Allerdings nur der in ftp://ftp.suse.com/pub/people/mantel/test/, also k_deflt-2.4.19-126.i586.rpm. Der andere in /next hat das selbe Problem...
Also ist es sicherer den alten Kernel von Suse 8.0 zu installieren?
Nein, der hat das gleiche Problem mit den IDE-Festplatten!
Mit 8.0 hatte ich keine Probleme, allerdings in leicht anderer Konfiguration. ftp://ftp.suse.com/pub/people/mantel/test/ enthält *Test*. Das hört sich nicht gut für ein System an, das funktionieren soll. Was soll ich nun tun? Experimentieren möchte ich nicht, ich fürchte Datenverlust. Theoretische Frage: Seit 7.x habe ich wegen des modularen Aufbaus keine Kernel mehr kompiliert. Wie integriert man diesen Testkernel am besten in das System? make cloneconfig und dann mit den neuen Sourcen kompilieren? Albert
Al Bogner wrote:
[...] Mit 8.0 hatte ich keine Probleme, allerdings in leicht anderer Konfiguration.
Wir hatten hier schwere Probleme!
ftp://ftp.suse.com/pub/people/mantel/test/ enthält *Test*. Das hört sich nicht gut für ein System an, das funktionieren soll. Was soll ich nun tun? Experimentieren möchte ich nicht, ich fürchte Datenverlust.
Nun ja, da diesen Kernel wohl in letzter Zeit so einige Leute auf ihr System aufgespielt haben (wegen dem IDE-Bug) solltest Du da auf der einigermassen sicheren Seite sein, sonst haette man hier wohl schon Wehklagen gehoert :-) Du kannst theoretisch auch einen Vanilla-Kernel nehmen, wenn Du auf SuSE-Patches verzichten kannst/willst. Aber den musst Du halt auf alle Faelle selbst compilieren.
Theoretische Frage: Seit 7.x habe ich wegen des modularen Aufbaus keine Kernel mehr kompiliert. Wie integriert man diesen Testkernel am besten in das System? make cloneconfig und dann mit den neuen Sourcen kompilieren?
Am einfachsten ist sicher das fertige RPM zu verwenden. Natuerlich kannst Du Dir auch die Sourcen ziehen und com- pilieren, was Dir halt lieber ist. Zu beachten gibt es in beiden Faellen so einiges... Gruesse, Thomson -- Thomas Hertweck, Dipl.-Geophys. Geophysikalisches Institut, Universitaet Karlsruhe (TH)
On Dienstag, 5. November 2002 19:56 Thomas Hertweck wrote:
ftp://ftp.suse.com/pub/people/mantel/test/
Am einfachsten ist sicher das fertige RPM zu verwenden. Natuerlich kannst Du Dir auch die Sourcen ziehen und com- pilieren, was Dir halt lieber ist. Zu beachten gibt es in beiden Faellen so einiges...
Auf was sollte man bei der rpm-Version achten? Lohnt es sich noch ein paar Tage zu warten? Albert
Al Bogner wrote:
On Dienstag, 5. November 2002 19:56 Thomas Hertweck wrote:
ftp://ftp.suse.com/pub/people/mantel/test/
Am einfachsten ist sicher das fertige RPM zu verwenden. Natuerlich kannst Du Dir auch die Sourcen ziehen und com- pilieren, was Dir halt lieber ist. Zu beachten gibt es in beiden Faellen so einiges...
Auf was sollte man bei der rpm-Version achten? Lohnt es sich noch ein paar Tage zu warten?
Na, wenn Du das Kernel-RPM als Update einspielst, dann wird vermutlich der alte Kernel in /boot ueberschrieben - das ist ungeschickt. Besser waere es, den alten Kernel + System.map aus /boot zu sichern und ebenso die Module unter /lib/modules, dann das neue RPM einspielen, die alten Sachen unter geeigne- tem Namen zurueckspielen und die /etc/lilo.conf anpassen, so dass sowohl der neue als auch (vorerst) der alte gebootet werden kann. Aber ich bin mir nicht 100% sicher, was beim Updaten des Kernel-RPM genau ausgetauscht wird, ich nehme eigentlich immer die Sourcen und compiliere selbst - mit Hil- fe von Davids Multikernel-Howto ist das dann auch alles recht einfach. Ach ja, den Aufruf von "lilo" nicht vergessen. Wenn Dir das fertige Kernel-RPM unsympathisch ist, nimm halt den Quellcode. Auf was moechtest Du denn ein paar Tage warten? Kernel-Ver- sionen gibt es staendig neue, da kannst Du quasi endlos war- ten. Wenn Du vom IDE-Bug betroffen bist und die Kiste staen- dig abschmiert, dann kannst Du nicht mit arbeiten. Was hast Du mit einem neuen Kernel zu befuerchten? Backup ist ja vor- handen, wenn nicht... - naja, das ist dann Dein Problem. Dann hast Du die "oberste Direktive[1]" verletzt :-) Gruesse, Thomson [1] Fuer die StarTrek Fans wohl etwas bekanntes... -- Thomas Hertweck, Dipl.-Geophys. Geophysikalisches Institut, Universitaet Karlsruhe (TH)
Thomas Hertweck wrote:
[...] Ach ja, den Aufruf von "lilo" nicht vergessen.
Ich vergass, SuSE-Kernel brauchen ja auch noch ein mkinitrd :-) Naja, wenn man selbst compiliert, kommt man meist ohne diesen Schnickschnack aus, da vergisst man so etwas schon mal *lach* Th. -- Thomas Hertweck, Dipl.-Geophys. Geophysikalisches Institut, Universitaet Karlsruhe (TH)
On Dienstag, 5. November 2002 20:33 Thomas Hertweck wrote:
ftp://ftp.suse.com/pub/people/mantel/test/
Am einfachsten ist sicher das fertige RPM zu verwenden. Natuerlich kannst Du Dir auch die Sourcen ziehen und com- pilieren, was Dir halt lieber ist. Zu beachten gibt es in beiden Faellen so einiges...
und die /etc/lilo.conf anpassen,
interessant, dass wiederholt lilo angesprochen wird. Verwendet ihr weiter lilo anstatt grub, das Standard unter 8.1 ist?
Updaten des Kernel-RPM genau ausgetauscht wird, ich nehme eigentlich immer die Sourcen und compiliere selbst - mit Hil- fe von Davids Multikernel-Howto ist das dann auch alles recht einfach.
Also Kernel kompilieren fand ich früher nicht so schwierig, außer man wirft zu viel raus, was mir auch schon passiert ist. Funktioniert das make cloneconfig gut? Werden die augenblicklichen Kerneleinstellungen richtig übernommen? Ich habe früher Kernel so erstellt: cd /usr/src/linux make xconfig make dep clean bzImage > /dev/tty5 make modules > /dev/tty5 make bzlilo > /dev/tty5 make modules_install > /dev/tty5 make bzdisk > /dev/tty5 Sollte ich da was ändern? Wie läuft das jetzt mit grub anstatt bzlilo?
Auf was moechtest Du denn ein paar Tage warten? Kernel-Ver- sionen gibt es staendig neue, da kannst Du quasi endlos war- ten. Wenn Du vom IDE-Bug betroffen bist und die Kiste staen- dig abschmiert, dann kannst Du nicht mit arbeiten.
Ich habe eine Alternative, denn ich könnte einen anderen Rechner mit *1* HD zum vorübergehend zum Fileserver machen, der bis jetzt unter 8.1 problemlos lief.
Backup ist ja vor- handen, wenn nicht... - naja, das ist dann Dein Problem. Dann hast Du die "oberste Direktive[1]" verletzt :-)
Ähm, 1 Backup habe ich nicht - es sind mehrere :-) Albert
Al Bogner wrote:
[...] interessant, dass wiederholt lilo angesprochen wird. Verwendet ihr weiter lilo anstatt grub, das Standard unter 8.1 ist?
Ich habe keine 8.1, brauche ich nicht, daher bleibe ich auch bei meinem vertrauten und hier einwandfrei funktionierenden "lilo"!
[...] Funktioniert das make cloneconfig gut? Werden die augenblicklichen Kerneleinstellungen richtig übernommen?
"make cloneconfig" ist AFAIK ein Feature des SuSE-Kernels und bedarf einer /proc/config.gz. Das sollte dann schon einwandfrei funktionieren. Alternativ kannst Du die alte Konfigurationsda- tei in den Kernelbaum der neuen Quellen kopieren (als .config) und dann ein "make oldconfig" aufrufen - da wirst Du dann nur nach Sachen gefragt, die sich gegenueber dem alten Kernel ge- aendert haben (z.B. neu dazu gekommen sind). Funktioniert i.d.R. ebenfalls ohne Probleme.
Ich habe früher Kernel so erstellt:
cd /usr/src/linux make xconfig make dep clean bzImage > /dev/tty5 make modules > /dev/tty5 make bzlilo > /dev/tty5 make modules_install > /dev/tty5 make bzdisk > /dev/tty5
Sollte ich da was ändern? Wie läuft das jetzt mit grub anstatt bzlilo?
"grub" kenne ich nicht, dazu kann ich nichts sagen. Ich habe auch nie bzlilo und bzdisk verwendet sondern meine lilo.conf lieber von Hand angepasst und die Kernel mit korrektem Namen selbst kopiert, usw. Siehe dazu Davids Multikernel-HOWTO, http://www.dhaller.de/linux/multikernel.html.
Ähm, 1 Backup habe ich nicht - es sind mehrere :-)
Brav! ;-) Gruesse, Thomson -- Thomas Hertweck, Geophysicist Geophysical Institute, Karlsruhe University (TH)
Hallo Albert, Am Dienstag, 5. November 2002 20:14 schrieb Al Bogner:
On Dienstag, 5. November 2002 19:56 Thomas Hertweck wrote:
ftp://ftp.suse.com/pub/people/mantel/test/
Am einfachsten ist sicher das fertige RPM zu verwenden. Natuerlich kannst Du Dir auch die Sourcen ziehen und com- pilieren, was Dir halt lieber ist. Zu beachten gibt es in beiden Faellen so einiges...
Auf was sollte man bei der rpm-Version achten? Lohnt es sich noch ein paar Tage zu warten?
Auf gar nichts. Über rpm auf der Kommandozeile einspielen, das mK_initrd hinterher schieben und neu booten, damit der alte Kernel rausgeschmissen wird. Meine Probleme jedenfalls hat dieser Kernel behoben. Andernfalls hätte ich jetzt eine andere Distri oder ein anderes Betriebssystem auf dem Rechner. Helga -- ## Content Developer OpenOffice.org: lang/DE ## Office-Suite für Linux, Mac, Windows -- http://de.openoffice.org/ ## OpenOffice.org1.0.1 jetzt auch als deutsches Release erhältlich ## Netikette, nein Danke? -- http://www.suse-etikette.de.vu/
Helga Fischer wrote:
Am Dienstag, 5. November 2002 20:14 schrieb Al Bogner:
[...] Auf was sollte man bei der rpm-Version achten? Lohnt es sich noch ein paar Tage zu warten?
Auf gar nichts. Über rpm auf der Kommandozeile einspielen, das mK_initrd hinterher schieben und neu booten, damit der alte Kernel rausgeschmissen wird.
Ist nur dumm, wenn der neue Kernel (warum auch immer) nicht booten will. Ich wuerde immer den alten Kernel etc. und die alten Module sichern. In Falle des IDE-Bugs wirkt das natuerlich wie ein Schuss ins Knie, den buggy Kernel zu sichern, aber das ist ja nicht immer der Fall. Manchmal macht man ein Update ja auch wegen einem neuen Kernel- Feature, und wenn ich dann notfalls bei Bedarf den alten nochmal schnell booten kann, das ist mir schon lieber! Nur so als Idee. Gruesse, Thomson -- Thomas Hertweck, Dipl.-Geophys. Geophysikalisches Institut, Universitaet Karlsruhe (TH)
Hallo Thomas, Am Dienstag, 5. November 2002 20:43 schrieb Thomas Hertweck:
Helga Fischer wrote:
Am Dienstag, 5. November 2002 20:14 schrieb Al Bogner:
[...] Auf was sollte man bei der rpm-Version achten? Lohnt es sich noch ein paar Tage zu warten?
Auf gar nichts. Über rpm auf der Kommandozeile einspielen, das mK_initrd hinterher schieben und neu booten, damit der alte Kernel rausgeschmissen wird.
Ist nur dumm, wenn der neue Kernel (warum auch immer) nicht booten will. Ich wuerde immer den alten Kernel etc. und die alten Module sichern.
Yo, da hast Du schon recht.
In Falle des IDE-Bugs wirkt das natuerlich wie ein Schuss ins Knie, den buggy Kernel zu sichern, aber das ist ja nicht immer der Fall.
Richtig, deswegen auch mein energisches Wech-damit.
Manchmal macht man ein Update ja auch wegen einem neuen Kernel- Feature, und wenn ich dann notfalls bei Bedarf den alten nochmal schnell booten kann, das ist mir schon lieber! Nur so als Idee.
Ich widerspreche gar nicht. Sicher werde ich mir bei Gelegenheit noch ein Testsystem aufsetzen und das so einrichten, daß ich mit mehreren Kernels arbeiten kann. Aber das ist alles gar keine Alternative, wenn man mit seinem Betriebssystem einfach nur arbeiten will. Helga -- ## Content Developer OpenOffice.org: lang/DE ## Office-Suite für Linux, Mac, Windows -- http://de.openoffice.org/ ## OpenOffice.org1.0.1 jetzt auch als deutsches Release erhältlich ## Netikette, nein Danke? -- http://www.suse-etikette.de.vu/
Am Dienstag, 5. November 2002 19:46 schrieb Al Bogner:
On Dienstag, 5. November 2002 19:15 Thomas Hertweck wrote:
in einigen Konfigurationen mit mehreren IDE-Festplatten hat der Kernel von der 8.1 anscheinend einige Probleme. Über die Liste ging heute das der Kernel von
ftp://ftp.suse.com/pub/people/mantel/
Allerdings nur der in ftp://ftp.suse.com/pub/people/mantel/test/, also k_deflt-2.4.19-126.i586.rpm. Der andere in /next hat das selbe Problem...
Also ist es sicherer den alten Kernel von Suse 8.0 zu installieren?
Nein, der hat das gleiche Problem mit den IDE-Festplatten!
Mit 8.0 hatte ich keine Probleme, allerdings in leicht anderer Konfiguration. ftp://ftp.suse.com/pub/people/mantel/test/ enthält *Test*. Das hört sich nicht gut für ein System an, das funktionieren soll. Was soll ich nun tun? Experimentieren möchte ich nicht, ich fürchte Datenverlust.
Theoretische Frage: Seit 7.x habe ich wegen des modularen Aufbaus keine Kernel mehr kompiliert. Wie integriert man diesen Testkernel am besten in das System? make cloneconfig und dann mit den neuen Sourcen kompilieren?
Albert
Hallo Albert, der Kernel liegt als rpm-Paket vor. Den Kannst Du einfach mit rpm -Uvh "Paketname.rpm" und anschließendem mk_initrd installieren. Sollte der Kernel wieder Erwarten Probleme machen, kannst Du den Orginal-Kernel einfach mit Yast wieder einspielen. Die Mantel-Kernel haben sind zwar Test, laufen bei mir aber ohne Probleme. Gruß Jörg -- Jörg Frings-Fürst 54526 Landscheid http://www.fixundfoxi.dydndns.info -- Registered Linux User # 280687 ICQ 170365098 GPG Key ID : EB8A FFC8 1314 12E1
On Dienstag, 5. November 2002 20:32 Joerg Frings-Fuerst wrote:
rpm -Uvh "Paketname.rpm" und anschließendem mk_initrd
Muß man mk_initrd wirklich noch machen? Der Rechner fuhr nach einem reboot problemlos hoch. Das war die Ausgabe bei der Installation: server:~ # rpm -Uvh /usr/src/packages/RPMS/i586/k_deflt-2.4.19-135.i586.rpm k_deflt ################################################## using "/dev/hdb10" as root device (mounted on "/" as "ext3") creating initrd "/boot/initrd" for kernel "/boot/vmlinuz" (2.4.19-4GB) - insmod jbd (lib/modules/2.4.19-4GB/kernel/fs/jbd/jbd.o) - insmod ext3 (lib/modules/2.4.19-4GB/kernel/fs/ext3/ext3.o) - splash picture (800x600) creating initrd "/boot/initrd.shipped" for kernel "/boot/vmlinuz.shipped" (2.4.19-4GB) - insmod jbd (lib/modules/2.4.19-4GB/kernel/fs/jbd/jbd.o) - insmod ext3 (lib/modules/2.4.19-4GB/kernel/fs/ext3/ext3.o) - splash picture (800x600) Gibt es einen Test für den IDE-Bug? Albert
Al Bogner wrote:
On Dienstag, 5. November 2002 20:32 Joerg Frings-Fuerst wrote:
rpm -Uvh "Paketname.rpm" und anschließendem mk_initrd
Muß man mk_initrd wirklich noch machen? Der Rechner fuhr nach einem reboot problemlos hoch.
Das war die Ausgabe bei der Installation:
[...creating initrd "/boot/initrd" for kernel "/boot/vmlinuz"...]
Es scheint so, als haette SuSE dafuer gesorgt, dass nach dem Installieren des RPMs ein mkinitrd aufgerufen wird (das ist ja ein Feature, was man bei RPM verwenden kann). Insofern kannst Du es Dir hinterher sparen, schaden tut es aber auch nicht.
Gibt es einen Test für den IDE-Bug?
Einige Leute sagen, dass sie einen Kernel-Panic "triggern" konn- ten. Das war bei mir nicht der Fall. Zum Testen wuerde ich ein- fach im Hintergrund jede Menge Daten zwischen den Festplatten hin- und herschaufeln und dabei ganz normal weiter arbeiten... Das hat hier frueher oder spaeter immer zu einem Freeze gefuehrt. Mit dem neuen Kernel (damals noch unter <pthomas>/IDE/) waren hier die Probleme jedenfalls behoben. Du kannst auch in die Changelog Datei schauen, dort sollte irgendwo etwas von "remove write barrier feature, since it seems to cause problems on some machines" stehen. Dieser Write-Barrier-Patch war wohl die Ur- sache fuer den IDE-Bug im SuSE-Kernel. Gruesse, Thomson -- Thomas Hertweck, Dipl.-Geophys. Geophysikalisches Institut, Universitaet Karlsruhe (TH)
participants (5)
-
Al Bogner -
Helga Fischer -
Joerg Frings-Fuerst -
Ralf Ebeling -
Thomas Hertweck