[gelöst]Bootprobleme

[fischig]

Ist dir eigentlich schon mal aufgefallen, dass du deine eigenen Beiträge jederzeit editieren kannst, statt ständig neue zu produzieren - und sogar ganz ohne Änderungsvermerk, solange der Beitrag der letzte im Faden ist?

[Tintom]

[...] sogar ganz ohne Änderungsvermerk, solange der Beitrag der letzte im Faden ist?

Danke, jetzt habe ich das endlich auch mal verstanden

[KarlPhilip]

Ey fischic, ich nutze die Funktion eher luschig, werde mich aber gern bemühen. Jetzt ist es nicht der letzte Beitrag. However, noacpi ist nicht die Ursache des Abschmierens und ich muß weiterprobieren. Das ist ziemloch doof. Bill will daß ich Windows benutze. Dies ist jetzt doch der letzte Beitrag, den ich nach Belieben editieren kann. Man lernt doch immer gern dazu. Danke an alle. Nach erneutem dmesg dies gefunden:

The ACPI Warning: ...._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] warning could be annoying but is harmless. The message is shown because Nvidia does not conform to the official ACPI specification.

It can also not be "fixed" by using the required "Package" type because it would break many laptops with Nvidia GPUs, resulting in higher power consumption. For a more technical description, see this discussion.

As a user, the best thing you can do is ignoring it. It will only occur when the GPU driver (nvidia, nouveau, bbswitch) is loaded, or when a GPU in a hybrid graphics laptop is powered off.
Also scheints auch mit der Nvidia zusammenzuhängen. Auch habe ich in grub 'quiet' entfernt und er hat erstmal gebootet. Das Problem scheint weg zu sein. Ohne 'quiet' bootet er wie eh und je. Ich setze das Thema dann, falls er die nächsten Tage auch stabil bootet auf gelöst. Danke an alle die mir geholfen haben. Danke Euch.
Natürlich bootet er nicht, nur weil 'quiet' nicht mehr drin steht. Aber es gibt bessere Bootmeldungen und es sah so aus, daß er abschmiert, wenn 'activate acpi' erricht wird. Wird wohl doch ein acpifehler sein. Von Gates in den Rechner geschmuggelt. Oh

[baeuchlein]

KarlPhilip, sofern du später evtl. doch noch mal auf das Problem zurück kommst, musst du wesentlich mehr System in dein Vorgehen und auch deine Postings bringen. Sonst verliert man völlig die Übersicht.

[KarlPhilip]

Ey Baeuchlein, das habe ich auch schon mit Schrecken festgestellt. Ob ich dazu in der Lage bin, weiß ich nicht so genau, es fasert immer so schnell an allen Ecken und Kanten aus. Die Probleme sind leider auch komplexer Natur und ich leide. Jedenfalls danke Baeuchlein (schwieriger und irgendwie auch komplexer Name) für Deinen Beitrag. Was mache ich denn jetzt? Neues Thema und alles kurz und knacḱigst. Oder ich trage die Kiste gleich zur Schuttkuhle. Hat ja so auch keinen Zweck.Andererseits kann ich kaum glauben, daß es so etwas Schönes wie Debian in dieser Welt überhaupt gibt und das noch völlig kostenlos. Laßt mich jetzt nicht allein mit meinem Problem, daß wäre an dieser Stelle meine Bitte. Wie komme ich an einen passenden Kernel? Wie geht das? Unter Suse habe ich vor vielen Jahren gern Kernelanpassungen vorgenommen. Ansonsten allen ein schönes Wochenende und bleibt gesund und am besten zu Hause.

[KP97]

Wie komme ich an einen passenden Kernel? Wie geht das?

Aus dem Stable-Repo bzw. aus dem Backports-Repo mit apt install.

Dir fehlen grundlegende Basiskenntnisse, ich kann nur immer wieder darauf hinweisen:
https://debian-handbook.info/browse/de-DE/stable/
https://wiki.debianforum.de/Hauptseite

OT:
Deine Anrede mit Ey ist ziemlich respektlos und unhöflich, solltest Du Dir schleunigst abgewöhnen...

[baeuchlein]

KarlPhilip, weggeschmissen werden muss hier jetzt erst mal gar nix. Mit Windows läuft die Kiste ja, d.h. wahrscheinlich ist nichts kaputt, sondern Linux steuert es nur falsch an, oder sowas in der Art.

Hektisches Herumprobieren von irgendwas hilft normalerweise nicht. Hier muss man Sherlock Holmes spielen und das Problem suchen/identifizieren, und zwar methodisch und mit ausreichender Geduld. Im Falle deines Rechners habe ich den Eindruck, dass das Problem bei gleichen Kernel-Parametern (wie z.B. diesem "noacpi" u.ä.) manchmal auftritt und manchmal nicht. Sprich: Der Fehler tritt nicht immer auf, sondern sporadisch. Dann muss man mehr Geduld haben, denn wenn der Fehler mal nicht auftritt, weiß man nicht, ob's Zufall ist, oder ob man gerade irgendwas gemacht hat, was den Fehler tatsächlich verhindert. (Ich selber gehe auch gerade auf einem Rechner einem Problem nach und muss jetzt erst mal ca. zwei Monate lang schauen, ob es nicht mehr kommt. Gerade ist "Halbzeit"...)

Frage: Weißt du, ob dieses Problem mit dem "Ausgehen" des Rechners bei unveränderten Kernel-Parametern (angegeben in der grub-Konfiguration oder auch nach dem Drücken von "e" im grub-Menü) manchmal auftritt und manchmal nicht?

Um 'rauszukriegen, an welcher Stelle das Problem überhaupt liegt, muss man anhand der ganzen Meldungen eine Überlegung anstellen, was denn vermutlich das Problem ist. Dann muss man schauen, wie man dieses Problem möglichst einfach mit Kernel-Parametern (wie z.B. diesem "noacpi" u.ä.) umgehen können müsste. Klappt der Umgehungsversuch, dann liegt das Problem wahrscheinlich an dem, was durch's Umgehen eben umgangen wurde.

Da diverse Meldungen deines Linux' darauf hindeuten, dass das Problem irgendwas mit den Stromsparmodi zu tun hat (vermutlich übrigens mit dem "Aufwachen" aus so einem Sparmodus), wollten wir die ganzen Stromsparmodi mal mit "acpi=off" oder "noacpi" (bewirkt dasselbe) ausschalten und dann schauen, ob der Rechner danach stets läuft.

Frage: Tritt das Problem auch schon mal auf, bevor im grub ein Betriebssystem zum Booten ausgewählt wurde? Oder kommt es erst, nachdem man eine Auswahl getroffen hat und grub das ausgewählte System booten will?

Frage: War ursprünglich in der grub-Konfiguration "acpi=off" oder "noacpi" schon drin?

Wenn nicht: Was passierte, als du den Rechner mal mit "acpi=off" oder "noacpi" gestartet hast?

Falls nichts Besonderes in diesem Falle passierte: Hast du das Starten mit "acpi=off" oder "noacpi" nur einmal probiert, oder mehrmals?

Falls du es mehrmals probiert hast: War das Ergebnis jedes Mal das Gleiche?


Das "Bauen" eines neuen Kernels ohne Stromsparmodi stellen wir erst mal zurück, bis wir über dieses "acpi=off"/"noacpi" herausgefunden haben, ob das Problem mit dem Stromsparmodus zu tun hat oder doch nicht.

[willy4711]

Da diverse Meldungen deines Linux' darauf hindeuten, dass das Problem irgendwas mit den Stromsparmodi zu tun hat (vermutlich übrigens mit dem "Aufwachen" aus so einem Sparmodus), wollten wir die ganzen Stromsparmodi mal mit "acpi=off" oder "noacpi" (bewirkt dasselbe) ausschalten und dann schauen, ob der Rechner danach stets läuft.

Suche den ersten Eintrag ,nach dem du im Grub Menü "e" gedrückt hast.
die Zeile sieht so aus:

Code: Alles auswählen

linux   /boot/vmlinuz-4.19.0-12-amd64 root=UUID=6b819ab0-2982-4b37-a960-f1c158d213cf ro  quiet

die änderst du dann so:

Code: Alles auswählen

linux   /boot/vmlinuz-4.19.0-12-amd64 root=UUID=6b819ab0-2982-4b37-a960-f1c158d213cf ro  quiet noacpi

Zwischen "quiet und noacpi muss ein Leerzeichen sein
Die Änderung bezieht sich nur auf diesen Start, und ist nicht dauerhaft. Sollte das klappen, sieht man weiter.

Weitere Optionen, die man testen kann sind hier sehr schön aufgeführt:
https://wiki.mageia.org/de/Wie_man_Kern ... _einstellt

Hat er schon probiert (sagt er jedenfalls)
Ich hatte vorgeschlagen, dass er sich eine Live-Version auf einen USB Stick packt (eben nicht Debian 8 ) und das testet.
Will er aber nicht. Ein USB- Stick dafür bekommt man für 2 - 3 € . Scheint nicht drin zu sein.

Außerdem hat er ja - soweit ich das verstehe - noacpi in die Bootzeile eingebaut und der Rechner läuft.

Also ist das - so ist inzwischen mein Eindruck - alles eine ziemlich nutzlose Unterhaltung.

[baeuchlein]

Ich war mir nicht sicher, wie ich einige seiner Rückmeldungen verstehen soll. Darum das Nachfragen - kaum etwas ist ärgerlicher, als aufgrund von Mißverständnissen einem "Phantom" nachzujagen. Aus demselben Grund will ich auch einigermaßen sicher sein, ob das Problem nun mit ACPI zusammenhängt oder nicht. Ohne diese Information wird das ein langwieriges Herumstochern im Nebel.

[KarlPhilip]

Nun bin ich aber erschlagen und auch überfordert. So viele Antworten, teils widersprüchlich etc.. Dann das mit dem "EY" als Anrede war ganz sicher nicht unhöflich gemeint! Unhöflich bin ich jedenfalls nicht. Um Missverständnissen vorzubeugen - nichts ist einfacher - als das "EY" schlicht nicht mehr zu verwenden.
Konkret:; Der Fehler tritt bis jetzt meines Wissens, immer noch auf. Ganz egal, was ich bisher unternommen habe. Und zwar unregelmäßig. Manchmal klappt das Booten mehrfach hintereinander, manchmal eben nicht. Eben wollte er so gar nicht booten, da habe ich in Grub und mit den Bootoptionen herumgespielt (ziellos), daraufhin fing er zu Booten an und es sah stark nach MInt 10 Ulyana aus, bin aber überraschenderweise in Debian herausgekommen. Was bitte, könnte das gewesen sein. Ich möchte baeuchling an dieser Stelle besonders für seine Hilfe danken und Willy schließe ich gleich mit ein. Im Moment ist alle zu verwirrend und ich muß neu mit allem starten. Ich fange mit dem Bootstick an und werde meine Grundkenntnisse versuchen zu erweitern. Bleibt alle gesund und ich wünsche Euch ein schönes Restwochenende.

[TRex]

Um Missverständnissen vorzubeugen - nichts ist einfacher - als das "EY" schlicht nicht mehr zu verwenden.

Danke, hatte auch eher die Tendenz dazu, das als störend zu empfinden - aber Erinnerung auch wieder an KP97, das nicht immer gleich mit einer Unterstellung zu verbinden, vielleicht eher mit "ich empfinde das Ey als herabwertend, kannst du das bitte lassen?" formuliert und schon wirkt das nicht gleich wie ein Urteil.

[KarlPhilip]

Erstmal danke TRex für Deinen sachdienlichen Hinweis. Mich hat das Ey auch noch beschäftigt und es sollte Hey heissen. Also vertippt. Ich bin ein alter Sack und die Augen sind schon ziemlich hinne, ich springe nicht mehr so wie früher. Es kann auch durch Fehler zu scheinbaren Unfreundlichlkeiten kommen. However, für Hinweise bin ich immer dankbar. Und wegen der Sachdienlichkeit gleich nochmal ein dmesgauszug unter besonderer Berücksichtigung von acpi. Manchmal fühlt man sich hier auf den Schlips getreten und dann ist man für Außerungen wie von TRex dankbar, das geht dann runter wie ÖL. https://nopaste.debianforum.de/41185
Hier grub.cfg: linux /boot/vmlinuz-4.19.0-12-amd64 root=UUID=6b819ab0-2982-4b37-a960-f1c158d213cf ro Hm, da steht ja gar nichts von noacpi. Kopfkratz
"ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver" Was heißt das? Was soll man da tun? Native driver = vom Hersteller, wie kriegt man den hier eingebaut, so es ihn gibt.

Neue Erkenntnisse: Mit acpi= off bootet der Rechner, aber funktioniert nicht. Nicht benutzbar. acpi=noirq bringt es leider auch nicht. Kann man daraus jetzt Erkenntnisse ziehen? Ich bitte um Antworten. Danke

[baeuchlein]

ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver" Was heißt das? Was soll man da tun? Native driver = vom Hersteller, wie kriegt man den hier eingebaut, so es ihn gibt.

Der "native driver" muss nicht zwingend einer vom Hersteller sein.

Prinzipiell bedeutet diese Nachricht und ein oder zwei weitere davor, dass hier ein Treiber (und zwar jener "native driver") irgendein Gerät oder Bauteil im Rechner benutzt, dass aber dieses ACPI auch gerne was mit diesem Gerät/Bauteil anstellen würde. Wenn es einen ACPI-Treiber für dieses Gerät gibt, sollte man den benutzen.

Ich habe sowas bei einem recht alten Mainboard. Da gibt es Temperaturfühler für die CPU und andere Sensoren zur "Selbstdiagnose" des Rechners. Für diese Sensoren gibt es schon seit Langem einen speziellen Treiber, eben den "native driver". Dann aber kam irgendwann eine Änderung in den für ACPI zuständigen "Teilen" von Linux, und der Linux-Kernel hatte zusätzlich zu dem "native driver" auch die Möglichkeit, über ACPI an die Daten dieser Sensoren 'ran zu kommen. Allerdings kloppten sich der "native driver" und ein ACPI-Treiber darum, wer denn nun die Sensoren auslesen durfte. Es konnten nicht beide Treiber zugleich 'ran. Das alte "Highlander"-Motto eben: Es kann nur einen geben!

Da bekam ich dann auch diese Meldungen, die mir im Prinzip sagten: Leg' mal den "native driver" (also den "Nicht-ACPI-Treiber") lahm! Nachdem ich das getan hatte, übernahm der ACPI-Treiber das Auslesen der Sensoren, und das ganze Theater hörte auf.

In deinem Fall kann man das aber wohl erst mal ignorieren, da mit "acpi=off" offenbar das eigentliche Problem nicht verschwindet - falls ich das Folgende richtig verstehe:

Neue Erkenntnisse: Mit acpi= off bootet der Rechner, aber funktioniert nicht. Nicht benutzbar. acpi=noirq bringt es leider auch nicht. Kann man daraus jetzt Erkenntnisse ziehen?

Was genau bedeutet "der Rechner bootet, aber funktioniert nicht"? Startet er erst, und dann geht er wieder aus?

In einem deiner früheren Postings hast du geschrieben, dass der Rechner mit "noacpi" schon mal gebootet hat. Da "noacpi" genau dasselbe bewirkt wie "acpi=off", bedeutet das anscheinend, dass "noacpi"/"acpi=off" manchmal funktioniert und manchmal nicht. Stimmt das?

Wenn "acpi=off" das "Abschalten" des Rechners nicht verhindert, liegt das Problem womöglich nicht an ACPI. Dann wird es langsam schwierig. "acpi=noirq" ist dann auch nicht hilfreich, weil das auch nur einen Teil von dem tut, was auch "acpi=off" macht.

[KarlPhilip]

Hallo Baeuchlein, bei acpi=off fährt der Rechner ganz normal hoch. Will man dann Programme starten oder ihn benutzen, friert er ein bzw. verhält sich merkwürdig. Browser funktionieren überhaupt nicht. acpi=off verhindert das Abschalten definitiv. Er schaltet dann nicht ab. Somit wird klar, es liegt an acpi ganz eindeutig, womit wir uns dem Problem entscheidend genähert haben, hoffe ich jedenfalls. Erstmal danke ich Dir, daß Du Dich kümmerst. Das Linux um die Minen von Microsoft herumentwickelt werden muß, ist natürlich megablöd. Was hätten wir für tolle Rechner, wenn dem nicht so wär. Es ist zum Haare raufen und Schlimmerem.

[KP97]

... aber Erinnerung auch wieder an KP97, das nicht immer gleich mit einer Unterstellung zu verbinden...

Wenn es nur zwei- oder dreimal und nicht jeder Beitrag gewesen wäre, hätte ich auch nix gesagt, aber so konnte ich es mir nicht verkneifen...

@KarlPhilip
Wäre es nicht langsam an der Zeit, ein Backup zu machen und das System neu zu installieren?
Da bist jetzt schon seit einer Ewigkeit damit zugange, ohne großen Erfolg. Klar, eine Reparatur ist immer besser als eine Neuinstallation (wir sind ja schließlich nicht bei Windows),
aber wenn so gar nichts fruchtet, sollte man das doch in Erwägung ziehen.
Nimm eine Netinstall mit Firmware und versuche es.
http://cdimage.debian.org/cdimage/unoff ... -firmware/
Falls es dann noch Fragen gibt, frage - aber in einem neuen Thread.

OT
Hier sind übrigens viele Ruheständler unterwegs, auch aus dem IT-Bereich.
Das muß also nicht besonders erwähnt werden, wichtig ist, daß man sich beschäftigt und nicht einrostet...
Zeit haben wir ja nun genug...

[baeuchlein]

Okay, KarlPhilip, dann versuchen wir doch mal, die Stromsparmodi "abzustellen". Dazu muss man den Kernel mal mit "idle=halt" starten; das "acpi=off" oder "noacpi" lässt man dann wieder weg. Mit etwas Glück benutzt der Prozessor mit "idle=halt" nicht mehr alle Stromsparmodi - mal sehen, ob das was bringt.

Schaltet der Rechner dann wieder unerwünscht ab, kann man statt "idle=halt" mal "idle=nomwait" ausprobieren. Was das ganz genau macht, habe ich zwar nicht verstanden, aber es beeinflusst auch irgendwas bei den Stromsparmodi.

Hilft auch das nicht, dann könnte sich "powersave=off" lohnen.

[KarlPhilip]

Grade startete der Rechner mit idle=halt. Bin mal gespannt! Danke KP 97 für Deinen Beitrag, ich verstehe Dich nur zu gut. Wenn ich "ey" schrieb hatte ich immer ein ungutes Gefühl, ohne zu wissen warum. Jetzt weiß ich es. Ey
Ich habe den Thread hier eröffnet, um eine Neuinstallation zu umgehen. Alle Diskussionen hier um diese Maschine endeten häufig mit dem Rat eine Neuinstallation zu machen. Kollege "Niemand" z. B. rät z.B. gern dazu. (jedenfalls bei dieser Maschine). However, Ihr seid alle miteinander, wie Ihr da seid, einfach große Klasse (ob jung, ob alt)!!!! Und Ihr helft ganz selbstlos. Eben Opensource, daß macht unsere Welt, entscheidend besser. Ich danke Euch.

[eggy]

Kollege "Niemand" z. B. rät z.B. gern dazu.

Wird er einen Grund für haben, der macht den Krams ja auch nicht erst seit gestern.
Neuinstalation bei Debian dauert wie lange? Selbst bei langsamer Handware solltest Du nach zwei Stunden damit durch sein.
Ich bin zwar auch eher dafür den Problemen auf den Grund zu gehen, aber irgendwann ist nen Punkt erreicht, wo es keinen Sinn macht, weiter im Nebel zu fischen. Dann kann man es auch einfach mal mit der Holzhammermethode versuchen, schlimmer kanns ja nicht werden

@baeuchlein: https://www.kernel.org/doc/html/v5.0/ad ... uidle.html

[KarlPhilip]

Ich habe jetzt einen Stick mit frischem Mate gebootet und melde mich von hier. Ich poste jetzt die dmesg Ausgaben. Unter besonderer Berücksichtigung von acpi https://nopaste.debianforum.de/41191 Kann man jetzt vielleicht abschätzen, ob eine Neuinstallation das Problem behebt? Oder eher nicht? Bitte schaut mal nach und gebt eine Rückmeldung. Danke Ich will auch xfce noch booten. Was ich jetzt grade getan habe. Das ist ein sehr schönes Debian xfce, gefällt mir sehr.
Idle=halt scheint es gebracht zu haben. Mit diesen Optionen fährt er hoch und ist vollumfänglich nutzbar. Ich glaube das Thema ist gelöst. Obwohl ich eine Neuinstallation mittels netinstall xfce/Buster auch reizvoll finde und gegebenenfalls auch vornehme. An alle Beteiligten geht mein Dank für die Mühen und das Interesse. Bleibt gesund und bis bald KarlPhilip

[baeuchlein]

Wenn der Rechner die problematische Debian-Installation nun mit "idle=halt" ohne Probleme auch weiterhin betreibt, dann kann man erst mal 'ne Weile alles so lassen. Man kann ein Bißchen drauf achten, ob das Abschalten vieler Stromsparmodi irgendwelche Nachteile hat (z.B. häufig anlaufender Ventilator o.ä.), oder ob nach ein, zwei Wochen vielleicht doch noch mal das unerwünschte Abschalten des Rechners auftritt. Aber wenn da nix passiert, dann kann man die weitere Suche auch bleiben lassen und so weiter machen.

Falls hingegen wieder Ärger auftritt, dann kann man auch die jetzt genutzte Installation sichern (vulgo: ein Backup machen, z.B. als Datenträger-Image mit partimage) und dann eine Neuinstallation machen. So optimistisch wie eggy und womöglich "Niemand" bin ich da aber nicht. Und "nach zwei Stunden damit durch" ist nur der, der hinterher wenig konfigurieren will/muss - bei mir hingegen dauert sowas üblicherweise viel, viel länger als das bloße Installieren. Ein bis zwei Wochen sind da bei mir normal. Solche Zeiten sollte man auch nicht vergessen, wenn man an eine Neuinstallation denkt.

@eggy: Danke für's Link-Raussuchen. Hilft mir allerdings nicht, so weit war ich auch schon. Die Beschreibungen dort sowie in meinen Internet-Funden sagen mir wenig über die Auswirkungen dessen, dass da der MWAIT-Befehl nicht genutzt werden soll. Bedeutet das, dass gar keine Stromspar-Funktionen mehr bei der CPU genutzt werden? Verletzt man ohne MWAIT irgendeinen Standard, und ist das ein echtes Problem? Da ich selber aber kein Problem habe, was IMHO was mit dieser MWAIT-Geschichte zu tun hat, bohre ich hier auch nicht weiter nach. Ich hab' genug relevante Baustellen hier, da kümmer' ich mich lieber da drum.

[willy4711]

Man solle aber dabei bedenken, das Mint offensichtlich problemlos startet.

Daher habe eher die Vermutung, dass eine Fehlkonfiguration oder seltsame Paketkonfiguration bei der
besprochenen Installation von Debian vorliegt.

So wie ihn verstehe, fährt ja dieses Mate vom Stick auch problemlos hoch. Bei einer Standart-Installation
sollte es an sich auch nicht anders sein ??

[KarlPhilip]

Ich schließe jetzt diesen Thread (Faden). War ja hart genug für alle Beteiligten. idle=nomwait war es auch nicht. Rechner macht pfffffffttt. Idle=halt löst wenn auch nicht optimal (wer weiß, was dieser Kernelparameter so alles anrichtet) das Problem. Wie ich letztendlich weiter verfahre oder nicht, steht zur Zeit noch in den Sternen. Danke an alle die kritisch oder konstruktiv sich beteiligt haben. Ich ziehe meinen Hut vor Euch. Danke Ich würde mich freuen, wenn jemand Willys Fragen noch beantworten könnte, mich interessiert das auch brennend. Dafür bleibt der Thread noch auf.

[baeuchlein]

Ich habe mal selber bei einem Rechner mit einer ähnlichen CPU (Core 2 Duo E6750) das "idle=halt" ausprobiert (Debian 9.13, selbstgebauter Kernel 4.15.7 von kernel.org). Bis auf eine einzige Zeile in dmesg, die wohl die Veränderungen durch "idle=halt" bestätigt, gibt es keine Änderung. Während des mehrstündigen Betriebs mit verschiedenen Programmen traten keine Probleme auf, die ich mit "idle=halt" in Verbindung bringe. Das "Aufheizverhalten" der CPU zeigte gegenüber dem Betrieb ohne "idle=halt" keine erkennbare Veränderung. Es passiert also für gewöhnlich nix Schlimmes, wenn man diesen Parameter beim Linux-Start drin hat. Ich würde ihn also in die Konfigurationsdatei von grub eintragen (vermutlich /boot/grub/custom.cfg) und das Problem als erledigt betrachten, falls es nicht doch noch mal auftritt.

Ich bin mir nicht sicher, was ganz genau "idle=halt" macht. Es schaltet sehr wahrscheinlich zwei Stromsparmodi der CPU ab (bzw. verhindert, dass diese Modi von Linux genutzt werden). Ob die im Normalbetrieb nennenswert oft vorkommen, ist mir nicht klar.

Meine Core2Duo-CPU ist eine "Desktop-Version" (für "normale" Computer), KarlPhilips CPU dagegen eine Mobil-Version (für Läptöpper/Notebooks). Es könnte sein, dass KarlPhilips CPU mit "idle=halt" wärmer wird als ohne diesen Parameter, aber wenn die CPU nicht gerade wärmer wird als 55-60°C im Betrieb, dann würde ich mir da keine Sorgen machen. Meine CPU wird etwas mehr als 50°C (auf 1-2 Kernen) warm, wenn sie ordentlich zu tun hat, während sie im Faulenzer-Modus auf 34-35°C 'runter geht. Wie warm KarlPhilips CPU für gewöhnlich wird und ob das dann jeweils normal für seine CPU ist, kann ich nicht sagen, aber 60°C sollten ohne jegliche Gefahr für die CPU möglich sein.

Willys letzte zwei Postings enthalten genau genommen nicht eine einzige Frage; auch der Satz mit den zwei Fragezeichen ist eigentlich keine Frage. Ich schätze mal, die Frage nach den Fragen des Willy bezog sich auf die Überlegungen in seinem letzten Posting. Nun, es kann zwar sein, dass irgendeine merkwürdige Paket- oder Linux-Konfiguration für die Probleme verantwortlich ist, aber erstens kenne ich keine Konfiguration, die mit den Stromspareinstellungen der CPU zu tun hat (würde mich aber nicht wundern, wenn's eine gäbe), und zweitens ist das Problem ja mit "idle=halt" offenbar problemlos abzustellen. Von daher: Siehe oben! "idle=halt" für diese Distribution benutzen, und wenn das problemlos geht, dann is' es ja gut.-schulterzuck-

[KarlPhilip]

Hallo Baeuchlein, vielen Dank für Deinen durchaus erhellenden Beitrag. Der Rechner verhält sich exakt so, wie Du es beschrieben hast. Ich hatte die Hardware grade überholt, sprich die Kühlung aufgefrischt. Die CPU wird mit idle=halt nur mäßig warm und nie so warm wie vor der Überholung. Diese Temperaturen erreicht sie nicht. Also alles wirklich im grünen Bereich. Die Kerneloption habe ich fest in Grub implementiert.
Und das Problem ist tatsächlich gelöst. Nochmals ein großes Danke an Euch. Apropos: "Bleibt alle gesund". KarlPhilip