Hallo,
Bin neu - als Schreiber - hier im Forum, wollte aber mal kurz zu einem Problem was schreiben, welches mich den halben Abend beschäftigte.
Im Rahmen der aktuellen kernel und Microcode Updates habe ich heute mein OpenSUSE 42.3 geupdatet. Also folgende Pakete:
- kernel : 4.4.104-39.1
- ucode-intel : 20170707-13.1
Anschließend konnte ich nicht mehr meinen Rechner booten! Er kam immer noch zum Grub2 Menü und anschließend erschien das üblich "loading initil ramdisk" .... und blieb dort unendlich hängen (auch alle Eingaben weg - d.h. Tastaur aus etc.)
Nach längerem hin-und-her recherchieren wurde ich auf einige Threads aufmerksam, welche als Idee angaben, man möge den kernel Parameter "dis_ucode_ldr" mal ausprobiere.
Und schon konnte ich wieder ganz normal booten!
Nun habe ich mit verschiedenen ucode Versionen hin-und-her experimentiert und habe herausgefunden, dass - so scheint es zumindest bis jetzt nach einigen reboots - bei mir nur die Version hier läuft:
- ucode-intel : 20170511-8.1
Also falls jemand ähnliche Probleme hat, könnte das helfen.
Aber richtig "spannend" finde ich , was in den verschiedenen microcode Paketen alles für Microcode Versionen angeboten werden. Denn das erscheint mir auf den ersten Blick recht merkwürdig. Ich habe mir das mal mit dem iucode_tool rausgesucht 8und vorher mein CPU Model bestimmen lassen).
Als laut iucode_tool habe ich folgende CPU:
- iucode_tool: system has processor(s) with signature 0x000406f1
Das aktuelle ucode Pakete für OpenSUSE Leap 42.3 .... also ucode-intel-20170707-13.1.x86_64.rpm bietet dabei folgende Microcode Revisionen (interessant, dass das paket noch 20170707 heißt, aber ein ucode von 2017-11-18 anbietet!):
085/001: sig 0x000406f1, pf_mask 0xef, 2017-03-01, rev 0xb000021, size 26624
085/002: sig 0x000406f1, pf_mask 0xef, 2017-03-01, rev 0xb000021, size 26624
085/003: sig 0x000406f1, pf_mask 0xef, 2017-11-18, rev 0xb000025, size 27648
Ein alternatives ucode Paket aus der Repository (home:Sauerland) ucode-intel-20171117-18.1.x86_64.rpm bietet folgende (das hier heiß zwar 20171117 ... beinhaltet aber nur 2017-03-01-er ucodes ??? 
089/001: sig 0x000406f1, pf_mask 0xef, 2017-03-01, rev 0xb000021, size 26624
089/002: sig 0x000406f1, pf_mask 0xef, 2017-03-01, rev 0xb000021, size 26624Und nun zuletzt gehe ich direkt zu Intel (dem aktuellen Meltdown Artikel von news.opensuse.org folgend: Security Vulnerability: "Meltdown" and "Spectre" side channel attacks against modern CPUs. | Support | SUSE ) um den aktuellen ucode mal zu laden. Dort findet man auch das latest tgz Paket: Download Linux* Processor Microcode Data File
Aber da bekommt man dann nur noch (also im 20171117-er paket bieten die offiziell für meiner CPU nur 2017-03-01-er ucode an 
) :
089/001: sig 0x000406f1, pf_mask 0xef, 2017-03-01, rev 0xb000021, size 26624
Thja, daraus soll man mal schlau werden.
Übrigens habe ich aktuell - was eben scheinbar zumindest beim Booten funktioniert - aus dem ucode-intel-20170511-8.1.rpm folgendes:
048/001: sig 0x000406f1, pf_mask 0xef, 2017-03-01, rev 0xb000021, size 26624
048/002: sig 0x000406f1, pf_mask 0xef, 2017-03-01, rev 0xb000021, size 26624Also nur mal so eine Vermutung. Könnte es es sein, dass dieser 2017-11-18-er ucode womöglich Probleme macht? Und Intel es womöglich schon aus dem offiziellen paket wieder entfernt hat und nur die offizielle OpenSUSE Repository ... das woher ich ucode-intel-20170707-13.1.x86_64.rpm habe ... es noch nicht mitbekommen hat??
Also falls jemand etwas Erhellendes dazu beitragen könnte, wäre ich sehr dankbar (denn womöglich bin ich auf dem falschen Dampfer und habe nur per Zufall mein System wieder zum Laufen gebracht).
Ansonsten hoffe ich, dass es wenigstens anderen Hilft, die in die selbe "Boot hängt mit Initial ramdisk" Falle getappt sind.
.
), 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 : 
