[gelöst]Bootprobleme

[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