Beiträge von alpilotx

Was "irgendwie" auch dazu gehört ist es die Zeit anderer Leute nicht mit schlauen Kommentaren zu "binden" ... und Threads nicht mit unnötigen Belehrungen zu überfrachten.
Und eventuell zu lesen(!), was andere - zum Beispiel ich - nur wenige Posts (Post 14) weiter oben bereits geschrieben haben:

Zitat von alpilotx

und auf den Hinweis im englischen Forum habe ich es jetzt auch mal als Bugreport bei Suse eingestellt (denn wie ein User dort korrekt feststellte, passiert sonst - möglicherweise - nichts ... oder nicht zeitnah):

Bug 1074919 – Boot Probleme with Intel Microcode on Core i7 6800K (Broadwell E) and latest Intel microcode

Sieht für mich wie ein Link zu einem Bug aus.

Zitat von Berichtigung

Hast du, bevor du deinen Bugreport geschrieben hast, auch sorgfältig gesucht, ob das nicht schon als Bug erfasst wurde?
i.d.R. erzeugen Neulinge allenfalls Duplikate, die sinnlos Arbeit machen.

Ja, Neulinge ...

Zitat von Berichtigung

Die Leute, die da näher dran sind, merken die Bugs i.d.R. sehr viel früher.

Ich denke, dass ist eine ziemliche Fehleinschätzung. Gerade sehr komplexe Software (wozu ich Betriebssysteme zähle) die auf - geschätzt - hunderttausend verschiedener Hardware läuft können Entwickler niemals in allen möglichen Konstellationen testen (weil sie eben nicht alle diese Varianten bei sich haben). Von daher hilft ihre "Nähe" nichts, wenn sie eines der problematischen Permutationen selber gerade nicht da haben. Daher sind sie eben auf Bugreports angewiesen ...

Keine Frage. Für mich geht es nur darum - und das ist auch aus Entwickler-Sicht wichtig - dass es mal dokumentiert ist. Ob, wann, wie sie es angehe können ist dann erst mal "zweitrangig" (weil ja zum Glück erst mal ein funktionierender Workaround da ist).

und auf den Hinweis im englischen Forum habe ich es jetzt auch mal als Bugreport bei Suse eingestellt (denn wie ein User dort korrekt feststellte, passiert sonst - möglicherweise - nichts ... oder nicht zeitnah):

• Bug 1074919 – Boot Probleme with Intel Microcode on Core i7 6800K (Broadwell E) and latest Intel microcode

Habe das Thema jetzt im englischen Forum auch noch angehängt, da dort jetzt auch einige User das gleiche problem haben, dass sie beim laden des "initial ramdisk" hängen bleiben.

• LEAP 42.2 boot hangs with kernel 4.4.104

Zitat von Sauerland

Mit diesem Patch gibt es anscheinend doch Probleme...
LEAP 42.3 CPU critical bugs Meltdown and Spectre

Und dein spezielles Problem ist gestern im IRC auch aufgetaucht, mit identischem Prozessor.
Aber keine Lösung, also warten wir die Bugreports mal ab....

Vielen Dank dass du mich auf dem laufenden hältst!

Zitat von Berichtigung

Was gibst du denn vor, was meine Beiträge zu vermitteln suchen?

--> "... und wenn nicht, ist es besser wenn es unkommentiert bleibt "

Gute Nacht

Danke .... Ich liebe Kunst, und das ist schon fast Kunst

(auf jeden Fall "erzählen" deine Beiträge mehr über dich als über die Inhalte die sie zu vermitteln vorgeben)

Falls jemand dazu noch - rein technisch - was beitragen kann, bin ich daran interessiert (und wenn nicht, ist es besser wenn es unkommentiert bleibt).

Zitat von Sauerland

Das hindert ja auch den Kernel, den micocode zu laden.........

Das ist mir absolut klar, nur wäre ich jetzt mal aus dem Stand nie auf die Idee gekommen, dass mir das hier den Tag rettet. Weil ich selber erst mal keinen Verdacht auf dem Microcode hatte ... und erst dieser - erfolgreiche - Workaround brachte mir den verdacht.

Zitat von Suerland

PS:
Was Intel da in den Paketen hat, hat mich noch nie interessiert........
Ich baue es halt.

Und hab seit gestern auf einen Patch gewartet....
Den ich jetzt eingebaut habe, aber das Paket ist noch nicht veröffentlicht.......

Alles anzeigen

Das ist mir auch klar (war also in keinster Weise ein Vorwurf) ... Ich habe auch nur einfach mal einen Quärcheck gemacht welche unterschiedliche Versionen denn so im Umlauf sind. Auch - wie gesagt - um überhaupt einen Plan zu bekommen wo das Problem liegen könnte.

Ein bisschen weniger Polemik hätte es auch getan .

Bin zwar sicher kein Linux-Guru, aber auch seit über 20 Jahren in der IT tätig und seit über über 12-Jahren auch - male mehr, mal weniger - intensiv mit Linux in Berührung (auf jeden Fall seit dieser Zeit privat mit SUSE/OpenSUSE unterwegs). Sprich, ich kenne durchaus was eine "Falle" ist (bin in viele rein getappt ), was "microcode" ist (das habe ich sogar vor laaanger Zeit mal im Studium gehabt) und was Microsoft ist (durfte die halbe Woche zuschauen und mitbetreuen wie Microsoft wegen dieser "Riesenbohei" Problematik im Azure Cloud eine große Serverinstallation meiner Firma komplett neu re-deployed hat ... weil sie es wohl nicht für sooo banal halten ... es sah eher bisschen nach Panik bei einem der größten Cloud Dienstleister aus). Ich behaupte auch mal vorsichtig, dass ich dieses "Riesenbohei" Thema durchaus zu einem nicht unwesentlichen Teil verstanden habe .... und nein, ich würde es lieber nicht verharmlosen (auch eine - wirklich - alter Prozessor Profi, Andreas Stiller aus den alten Zeiten der C't bezeichnet es als Security-Supergau : Analyse zur Prozessorlücke: Meltdown und Spectre sind ein Security-Supergau |
heise online ).

Außerdem möchte ich vorsichtig darauf hinweisen, dass mein Problem nach einem ganz normalen Systemupdate entstanden, bei dem der Kernel und die Microcodes NICHT aus irgendwelchen fadenscheinigen Repos stammten sondern aus der offiziellen Repository für OpenSUSE Leap 42.3 (die ganzen anderen Versionen habe ich nur angeschaut um zu verstehen wo die Unterschiede liegen könnten). Also durchaus eine Quelle aus der auch andere User schnell, ohne groß etwas "Unsauberes" zu machen ein update bekommen könnten (und dann womöglich auf dem Trockenen sitzen).

Auch war die "Lösung", also der Rücksprung auf eine alte Version aus der offiziellen Leap 42.3 Repository.

Kurz: ja, sicher bin ich nicht Unschuldig wenn man mal verschieden Repos für die Installation von ausgefalleneren Paketen aufnimmt, aber zumindest im Bereich Kernel / Microcodes habe ich mir - zumindest definitiv nicht Bewusst - keine "Unreinheiten" erlaubt.