Du bist nicht angemeldet.

#26 28.10.2014 13:04:30

chepaz
Mitglied

Re: Änderungen am Kernel hinsichtlich Microcode

Kabbone schrieb:

Das zähle ich jetzt mal nicht als Argument, weil wenn ich ein Feature nutzen will, muss ich es eben einrichten und das in diesem Fall 1x, sei es direkt in der Grub-config oder z.B. wenn man sich diese öfter generieren lässt in dem default-file.

Beide Varianten sind nicht Updatefest. Und wenn das überschrieben wird bekommst du es mit Sicherheit nicht mit. --> Notlösung.

Offline

#27 28.10.2014 13:43:49

Martin-MS
Mitglied

Re: Änderungen am Kernel hinsichtlich Microcode

Also die Bedenken bzgl. "Updatefestigkeit" kann ich so nicht teilen. Ich boote mit syslinux, dort muss lediglich in syslinux.cfg die INITRD-Zeile um einen Eintrag erweitert werden. Und bei grub ist es ähnlich, dort wird die Erweiterung in /etc/grub.d/10_linux vorgenommen. Beide Änderungen sind in sofern upgradefest als dass pacman eine pacnew-Datei anlegt, falls eine zu ersetzende Datei vom Benutzer modifiziert wurde. Die Änderung überlebt also ein Update. Wie mit der pacnew-Datei zu verfahren ist bleibt dem Benutzer überlassen, das Prozedere kennt man ja schon von anderen Paketen. Wobei ich mir dazu diff-Dateien erstellt habe die ich als Patch auf die pacnew-Dateien ausführe und damit wieder meine Änderungen in einer aktuellen Konfigurationsdatei wiederfinde, aber das nur am Rande.

Und selbst wenn pacman an der Stelle patzt, was kann denn dann maximal passieren? Ein in /boot hinterlegtes Image wird beim booten nicht mehr geladen, mehr nicht. Das wird wahrscheinlich nicht einmal groß auffallen und erst recht nicht den Systemstart verhindern (außer man benötigt die Microcode-Patche zwingend).

Offline

#28 28.10.2014 14:41:14

chepaz
Mitglied

Re: Änderungen am Kernel hinsichtlich Microcode

Martin-MS schrieb:

Und selbst wenn pacman an der Stelle patzt, was kann denn dann maximal passieren? Ein in /boot hinterlegtes Image wird beim booten nicht mehr geladen, mehr nicht.

Das ist gar nicht das Thema. Die gebotenen Lösungen für Grub sind einfach nicht gut. Da gibt es für mich gar keine Diskussion.

Martin-MS schrieb:

Das wird wahrscheinlich nicht einmal groß auffallen und erst recht nicht den Systemstart verhindern (außer man benötigt die Microcode-Patche zwingend).

Dann mach das mal in einer Umgebung mit >1000 Computenodes und schau wie sich die Anwender freuen wenn ihre Simulationssoftware andere Ergebnisse ausspukt weil nur 50% den uCode geladen haben.
Mag übertrieben sein aber dann gilt das gleiche wie oben. Vorher gab es einen Automatismus (der funktioniert hat) jetzt gibt es nur eine nicht gute Lösung.

Offline

#29 28.10.2014 15:42:47

Kabbone
Mitglied

Re: Änderungen am Kernel hinsichtlich Microcode

Ob die aktuelle Lösung gut oder schlecht ist, sei mal dahin gestellt. Mir ging es eigentlich eher um die Diskussion von Privatanwendern bzgl. "never touch a running system" oder doch laden wink

Beitrag geändert von Kabbone (28.10.2014 15:42:57)

Offline

#30 28.10.2014 16:20:27

ArchChem
Mitglied

Re: Änderungen am Kernel hinsichtlich Microcode

Kabbone schrieb:

Ob die aktuelle Lösung gut oder schlecht ist, sei mal dahin gestellt. Mir ging es eigentlich eher um die Diskussion von Privatanwendern bzgl. "never touch a running system" oder doch laden wink

Wie gesagt, wenn du keine Probleme mit deinem Prozessor hast – trotz evt. veralteter Firmware, dann würde ich dir "never change a running system" empfehlen – solange bis es eine komfortable Lösung für GRUB gibt.

Beste Grüße
ArchChem

Offline

#31 28.10.2014 17:58:24

Martin-MS
Mitglied

Re: Änderungen am Kernel hinsichtlich Microcode

Die einzige komfortable Lösung die ich mir vorstellen könnte und die keine Änderung am Bootloader notwendig macht wäre, den Microcode wieder als Kernelmodul anzubieten und dieses in MODULES der initramfs aufzunehmen so wie es mit anderen Modulen auch gemacht wird, die zeitig zur Verfügung stehen müssen. Um das aber zu beurteilen müsste man erst einmal die Gründe kennen, die überhaupt zur Verlagerung aus dem Kernelmodul in das Image geführt haben.

Aber noch mal: eine Konfigurationsänderung in grub ist komfortabel weil pacman bei einem Update die Änderungen respektiert und nicht überschreibt. Als Beispiel wurde ja schon dm-crypt genannt, das auch eine manuelle Erweiterung der Bootloaderkonfiguration nötig macht. Das läuft doch auch, und da gibt es auch keine "komfortable" Lösung. Deswegen verstehe ich die Aufregung nicht, warum man das jetzt mit dem Microcode nicht genau so machen möchte.

Offline

#32 28.10.2014 19:33:21

Photor
Mitglied

Re: Änderungen am Kernel hinsichtlich Microcode

ArchChem schrieb:
Kabbone schrieb:

Nach dieser Theorie sollte man auch keine Updates bei Arch machen. Ich sehe soweit eigentlich keine größeren Risiken den Microcode upzudaten, lasse mich aber gerne eines besseren belehren

Risiken entstehen dabei nicht, wie du ja schon sagst. Es ist aber halt eine Frage des Aufwandes, ob ich Lust habe, meinen GRUB mittels einer temporären Notlösung zu konfigurieren (siehe Wiki-Artikel), die beide eher schlecht als recht sind, oder ob man erst einmal abwartet.

ArchChem trifft es schon ganz gut: mich hat die Anleitung für Grub auch erstmal abgeschreckt. Beide angebotene Lösungen sind irgendwie ziemlich provisorisch, mit der Folge, dass ich beim Update von Grub wieder irgendwo nachsehen muss. Mir war es daher schon ganz recht, dass mein Lappy erstmal ohne Eingriff weiter leben konnte.

Ich habe ja keine Angst, an meinem System herumzukonfigurieren, wenn es was bringt - und sei es nur der Spaß, dass es jetzt besser läuft; sonst wäre ich nicht bei Archlinux, bei Linux überhaupt gelandet. Aber ich freue mich auch über ein System, was einfach so jeden Tag nebenbei geupdatet werden kann und so eben aktuell.
Deshalb meine Nachfrage hier: habe ich Vorteile, ist es angeraten, upzudaten, ist es reines tunen am System; ich will mir erst ein Bild machen, bevor ich meinem Forschertrieb nachgebe oder meinem Sicherheitsdenken den Vorzug gebe wink

Ciao,

Photor
(übrigens ohne "f", "s" und "e" wink )

Offline

#33 28.10.2014 19:44:12

chepaz
Mitglied

Re: Änderungen am Kernel hinsichtlich Microcode

Martin-MS schrieb:

Aber noch mal: eine Konfigurationsänderung in grub ist komfortabel weil pacman bei einem Update die Änderungen respektiert und nicht überschreibt.

Dann probier das mal aus. Die Scripte in /etc/grub.d/ werden gnadenlos überschrieben.

Martin-MS schrieb:

Als Beispiel wurde ja schon dm-crypt genannt, das auch eine manuelle Erweiterung der Bootloaderkonfiguration nötig macht. Das läuft doch auch, und da gibt es auch keine "komfortable" Lösung. Deswegen verstehe ich die Aufregung nicht, warum man das jetzt mit dem Microcode nicht genau so machen möchte.

Das landet alles in /etc/default/grub. Und das wird beim Update in Ruhe gelassen.

Offline

#34 28.10.2014 19:47:22

chepaz
Mitglied

Re: Änderungen am Kernel hinsichtlich Microcode

Photor schrieb:

Deshalb meine Nachfrage hier: habe ich Vorteile, ist es angeraten, upzudaten, ist es reines tunen am System; ich will mir erst ein Bild machen, bevor ich meinem Forschertrieb nachgebe oder meinem Sicherheitsdenken den Vorzug gebe wink

Wenn du keine Probleme hast und das kleine "weil ichs kann und bleeding edge sein will" nicht zu laut schreit: Lass es ;-)

Und wenn das kleine "weil ichs kann" doch lauter ist weisst du ja wie man die Änderungen wieder rückgängig macht ;-P

Offline

#35 28.10.2014 19:50:05

Photor
Mitglied

Re: Änderungen am Kernel hinsichtlich Microcode

Danke chepaz,

ich werde noch ein bischen auf die "kleinen" hören und dann entscheiden smile

Ciao,

Photor

Offline

#36 28.10.2014 20:11:07

nik
Mitglied

Re: Änderungen am Kernel hinsichtlich Microcode

Ich versteh den Aufriss hier nicht.

Wenn man eine "neuere" Intel-CPU nutzt, ist es in meinen Augen durchaus sinnvoll, das Paket zu installieren und die entsprechenden Anpassungen im Bootloader vorzunehmen, da die Wahrscheinlichkeit groß genug ist, dass man davon profitiert. Was bringt mir mein aktuelles "running system", wenn ich in Zukunft durch fehlerhaften Microcode nen Kernelpanic bekomme und dort dann unnötig viel Zeit in die Ursachensuche investiere, nur um jetzt 5min Zeit zu sparen?

Ich habe die grub.cfg direkt editiert - so wie es im englischen Wiki-Artikel unter anderem beschrieben wird - und kann versichern, dass die grub.cfg ohne Benutzerinteraktion nicht geändert wird.

Offline

#37 29.10.2014 00:07:46

Martin-MS
Mitglied

Re: Änderungen am Kernel hinsichtlich Microcode

So, es gibt ein grub-Update, dass sich zur Zeit noch in Testing befindet und die notwendigen Erweiterungen für das Laden des Microcode-Images in 10_linux aufnimmt:
https://projects.archlinux.de/svntogit/ … a12dbf02b7

Des weiteren wird für Interessierte hier https://lists.archlinux.org/pipermail/a … 26690.html vom Entwickler Thomas Bächler beschrieben, weswegen die Verschiebung überhaupt notwendig wurde (Crash auf Haswell-Systemen).

Offline

#38 30.10.2014 04:14:51

LinuxFan4543e5
Gast

Re: Änderungen am Kernel hinsichtlich Microcode

Ich habe das Paket intel-ucode jetzt einfach installiert und passe nichts weiter an. Werde warten bis die Grub die Aktualisierung abgeschlossen hat, dann wird das ganze automatisch wieder geladen. Und gut ist.

#39 30.10.2014 19:50:57

Greg
Mitglied

Re: Änderungen am Kernel hinsichtlich Microcode

microcode, ... nie gehört.
Microcodes werden im Bios normalerweise aktualisiert?
Dank dieses Beitrages habe ich dann auch mal beim Mutterbretthersteller nachgesehen ob da was neues drin steht.
Im changelog steht doch glatt drin changed microcode...
Also her damit.
Einen Unterschied kann man zwar nicht merken aber es wird schon was dran sein.

Ich danke Allen für die Aufklärungen!!
Bis denn..
Greg

Offline

#40 31.10.2014 09:33:38

tapsiturtle
Mitglied

Re: Änderungen am Kernel hinsichtlich Microcode

Ich boote direkt über EFI. Also habe ich nach dem Pacman Update mit efibootmgr meinen UEFI eintrag neu eingetragen mit der zusätzlichen initrd Zeile. Ergebnis: efibootmgr hat mir mein UEFI zerschossen. Nach dem starten ist kein Eintrag mehr für Arch im UEFI vorhanden, ein Boot Stick wird auch nicht mehr erkannt, das betreiben des ganzen im BIOS Modus und dem verwenden eines USB-Sticks dafür funktioniert ebenfalls nicht. Dafür kommt gelegentlich nach dem starten eine Fehlermelduung mit "CRC Error" und "EFI". Sowas liebe ich ja so richtig....

Offline

#41 31.10.2014 14:56:12

Creshal
Mitglied

Re: Änderungen am Kernel hinsichtlich Microcode

Notebook reklamieren, die Hersteller sollen endlich funktionierende UEFI-Implementierungen benutzen.

Offline

#42 31.12.2014 14:12:29

katsumoto
Mitglied

Re: Änderungen am Kernel hinsichtlich Microcode

Auch wenn das Thema hier schon zwei Monate alt ist - ich habe es jetzt erst entdeckt und anscheinend Glück, dass mein System immer fröhlich hochfuhr! Mit dem intel-ucode Paket scheint es jetzt irgendwie "runder" zu laufen und etwas schneller. Zumindest was GNOME angeht, bilde ich mir das gerade ein.
Von meinem Mainboardhersteller (Gigabyte) kommen leider seit Mitte 2013 keine Updates mehr, von daher denke ich ist es das Beste für mich, wenn ich das Paket laufen lasse.

just my 2 cents...

Offline

#43 18.06.2015 01:37:40

demi
Gast

Re: Änderungen am Kernel hinsichtlich Microcode

Wird intel-ucode inzwischen von der aktuellen Grub Version automatisch geladen?

#44 18.06.2015 13:32:14

Baldr
Gast

Re: Änderungen am Kernel hinsichtlich Microcode

Hab's mit vorgestern (endlich mal) installiert.

Ja, Grub findes das Image und bindet es mit

# grub-mkconfig -o /boot/grub/grub.cfg

automatisch unter

initrd 	/intel-ucode.img /initramfs-linux.img

ein, sofern du das Skript "10_linux" in /etc/grub.d/ nicht geändert hast.

#45 19.06.2015 01:22:09

frostschutz
Mitglied

Re: Änderungen am Kernel hinsichtlich Microcode

Nachdem mir das Haswell-System bei microcode-Updates immer abgeschmiert ist, hab ichs jetzt mal mit early-microcode (also per initrd) probiert. Funktioniert gut.

Merke aber auch keinen Unterschied nach wochenlangem Betrieb ohne microcode. smile System lief immer stabil.

Aber solangs mit dem Update auch funktioniert, darf es drinbleiben. Danke für den Hinweis.

Offline

#46 19.06.2015 07:37:55

Baldr
Gast

Re: Änderungen am Kernel hinsichtlich Microcode

Bei mir ist ein i7-4702MQ (also auch Haswell) verbaut. Probleme habe ich über initrd keine (ok, ok.. bei mir erst ganz frisch installiert...).

Einen (offensichtlichen) Unterschied kann ich aber auch nicht feststellen. Denke mal dass der "normale Anwender" das auch nicht merkt.

Aber warum sollten wir vorhandene Updates nicht einspielen? Dafür haben wir hier ja alle Arch installiert… gell…?! smile

#47 19.06.2015 18:25:03

frostschutz
Mitglied

Re: Änderungen am Kernel hinsichtlich Microcode

niemand schrieb:

Bei mir wird entsprechender μcode via grub geladen

Um jetzt Missverständnisse zu vermeiden... hat Grub dafür eine direkte Option oder meinst du auch die initrd ucode ...?

Mit initrd ucode ... lädt ja nicht Grub den Microcode sondern immer noch der Kernel. Wenn Grub das selbst machen würde (auch wenn man dann damit z.B. FreeDOS bootet) wäre das natürlich noch toller...

Offline

Schnellantwort auf dieses Thema

Schreibe deinen Beitrag und versende ihn
Deine Antwort

Fußzeile des Forums