Ubuntu-Forum & Kubuntu-Forum | www.Ubuntu-Forum.de

Zitat von »linux-krause«

Jetzt habe ich mal den Grub-Editor aufgerufen,

Wenn du es so machst, wie ich es oben beschrieben habe, ersparst du dir das fehlerträchtige Umstochern in config-files und weißt auch gleich ob die Option überhaupt was bringen würde.
Von einer zweiten Zeile war aber keine Rede.

Für einen "linux-krause" entwickelst Du aber sehr wenig Eigenideen, dafür. dass es DEIN System ist.

Ich würde mal nach dem Gnome Disk Tool suchen und schauen, ob man die Fehlermeldung abstellen kann.

So wie hier zum Beispiel in der Antwort geschrieben:

https://askubuntu.com/questions/38281/di…warning-message

Ich denke, den Rest des Problems mußt Du selber lösen, wenn hier nicht jemand rein zufällig genau das gleiche Problem hatte.
Für eine Qucik and dirty Lösung ist dein Problem zu speziell und zu selten.

Zitat von »linux-krause«

welches ist die Zeile mit dem Kernel-Aufruf?

Die, wo links "linux" steht und der Pfad zu vmlinuz-* vorkommt. Am Ende stehen die Bootoptionen, meist "quiet" und "splash". Da gehören die Optionen zum Testen drangehängt.

Zitat von »linux-krause«

Hat sich ja aber wahrscheinlich sowieso erledigt, weil das so nicht funktioniert!

Wieso weißt du das schon?

Zitat von »Fredl«

Wieso weißt du das schon?

Weil er meinen Weg über die grub Datei auch ausprobiert hat.

Ich glaube auch, Du vernachlässigst, dass es hier eine Fehlermdeldung ist, die unter X erscheint, also auf dem Desktop. NICHT beim Booten!
Glaub mir, dass kommt von dem Gnome Tool. Ich habe es ja schon fast bewiesen, mit der ps Ausgabe.

Zitat von »Horsemanchip«

Weil er meinen Weg über die grub Datei auch ausprobiert hat.

Probiert ja, aber so wie er es beschrieben hat, kann es kaum funktionieren. Zweite Zeile...

Zum Rest: Mir ist schon klar, daß es sich um ein tool unter X handelt. Auch daß es dieses disk-utility ist, scheint naheliegend. Es ergibt sich nämlich auch aus den rdepends der installierten Pakete einer früheren dpkg-Abfrage.

Wie auch immer, wenn der kernel ein device ignoriert, können selbst am höchsten Level keine Tools was damit anfangen. Und für den Rest des Systems wär's sicher auch kein Schaden, ein kaputtes Bauteil gar nicht erst zu sehen. Von daher war die vom TE aufgegriffene Idee imho nicht die schlechteste.

Plan B wäre vielleicht die Deinstallation des Utilitys, sofern dabei nicht weitere, nützliche Teile mit baden gehen. Bliebe aber immer noch ein defektes Bauteil im System liegen....

Zitat von »Fredl«

Probiert ja, aber so wie er es beschrieben hat, kann es kaum funktionieren. Zweite Zeile...

Nein, er hat 2 Sachen ausprobiert. Einmal hat er im Grub-Editor rumgefummelt mit einer zweiten Zeile, wobei ich überlesen habe, wer ihm das so geraten hat.
Dann hat er meinen Vorschlag mit der /etc/default/grub ausprobiert. Die Vorgehensweise in #17 war ja eindeutig, ohne zweite Zeile!

Ich würde nachwievor in dem Gnome Tool einstellen, dass Fehlermeldungen für /dev/sdb nicht angezeigt werden. Genau dafür ist dieses Häkchen da.

Zitat von »Horsemanchip«

Die Vorgehensweise in #17 war ja eindeutig

Zustimmung. Aber ich finde keinen Hinweis, daß es auch wirklich so gemacht wurde. Eine Kopie der Datei zur Ansicht wäre nicht schlecht. Fände es seltsam, wenn der kernel eine Bootoption einfach ignoriert. Könnte aber auch sein, daß der kernel das Ding immer noch als "hdb" benennt, wie es mancherorts heißt.

Zitat von »Horsemanchip«

in dem Gnome Tool einstellen, dass Fehlermeldungen für /dev/sdb nicht angezeigt werden

Hast das Teil jetzt extra installiert? Wie aufopfernd

Es wäre natürlich die schnellste und einfachste Abhilfe. Allerdings nur Bekämpfung der Symptome und nicht der Ursache.

Ne, ich hab das nicht installiert. Ich hab mir nur einen Screenshot von dem gefunden Gnome Tool gesucht.

Die Ursache wirst Du wohl nicht beheben können, wenn der feste Teil Speicher dauerhaft kaputt ist. Von daher wäre eine Symptombekämpfung doch ausreichend. sdb wird ja eh nicht benötigt.

Zitat von »Horsemanchip«

Die Ursache wirst Du wohl nicht beheben können, wenn der feste Teil Speicher dauerhaft kaputt ist.

Nicht ohne Lötwerkzeug, ist klar. Deshalb macht es auch keinen Sinn, wenn ihn der Kernel trotzdem noch sieht. Ist so ähnlich wie badblocks, memmap oder badram. Offenbar erkennt er den Defekt auch nicht von selbst, daher spielt das Utilty im Betrieb noch damit herum.
Wie man sieht, wäre sogar Zugriff durch den User nicht verwehrt, was aber in I/O-Errors endet. Wenn andere Systemkomponenten da auch was wollen, kann das auch eine Performance-Bremse sein.

Am Ende ist es aber wie ich immer sage... (rechts unten)

Zitat von »Fredl«

Am Ende ist es aber wie ich immer sage... (rechts unten)

Bei mir is wie auch rechts unten.