Fahrplan zu Kernel 4.7

Auf der Fedora Entwickler-Liste wurde am Montag der Fahrplan für Fedora zum Kernel 4.7 bekannt gegeben.

Demnach wird es zuerst noch ein Update auf Kernel 4.6.7 geben, welches auch gleichzeitig das letzte Update des Kernel 4.6 für Fedora 23/24 sein wird. Anfang nächster Woche wir dann das Update auf Kernel 4.7.1 oder 4.7.2 in updates-testing landen und dort getestet werden können.

Die veröffentlichten News werden nach bestem Wissen und Gewissen zusammengetragen. Eine Garantie für die Vollständigkeit und/oder Richtigkeit wird nicht übernommen.

Fedora: Erst Kernel 4.5.7, dann 4.6.3

Josh Boyer hat am Mittwoch auf der Entwickler-Liste bekannt gegeben, wann und auf welche Version des Kernels 4.6 Fedora umsteigen wird.

Demnach wird Fedora 24 den Kernel 4.5.7 als sogenanntes 0-Day-Update (Update am Tag der Veröffentlichung) erhalten und kurz danach dann höchstwahrscheinlich das Update auf Kernel 4.6.3. Sollte sich die Veröffentlichung von Kernel 4.6.3 jedoch verzögern, könnte es auch sein, das der Umstieg auf Kernel 4.6 mit Version 4.6.2 erfolgt.

Fedora 23 wird ca 1 bis 2 Wochen später ebenfalls auf den Kernel 4.6 wechseln, während Fedora 22 ein letztes Update für den Kernel 4.4 erhalten wird, bevor es den EOL-Status bekommt.

Neue Nummerierung für Fedora-Kernel

Wie Justin M. Forbes in seinem Blog schreibt, wird der aktuelle Kernel 3.7.2 als 0-Day-Update für Fedora 18 kommen. Zeitgleich wird die Nummerierung für das Release der Kernel-Pakete geändert. Das Release ist die Nummer im Paketnamen nach dem Bindestrich und das Baserelease ist die Nummer, mit der die Releasenummer bei jeder Fedora-Version startet.

Im Falle vom Fedora 18 Kernel-Paket, das den Namen

kernel-3.7.2-201.fc18.x86_64 
kernel-3.7.2-201.fc18.i686

trägt, ist das Release folglich die 201.

Im letzten community kernel meeting wurde jetzt beschlossen, folgende Basereleases für die Kernel zu verwenden:

Fedora-VersionKernel-Baserelease
17101
18201
19301

Dadurch sollten Probleme bei Upgrades verhindert werden, da sich die Release-Nummern der jeweiligen Kernel-Pakete definitiv unterscheiden. Bislang konnte es unter ungünstigen Konstellationen vorkommen, das nach einem Upgrade auf eine neue Fedora Version kein passender Kernel vorhanden war, da die Kernel-Version der alten Fedora-Version zu hoch war. Dies ist mit der genannten Umstellung nicht mehr möglich.

Grub2: Menü nach jedem Kernel-Update automatisch neu erzeugen

Bitte beachtet auch die Anmerkungen zu den HowTos!

So mancher kennt wahrscheinlich das Problem: während

su -c'grub2-mkconfig -o /boot/grub2/grub.cfg'

die installierten Kernel in einer sehr übersichtlichen Art und Weise mit Hilfe eines Untermenüs darstellt, schreibt grubby nach jedem Kernel-Update stumpf den Eintrag für den neu installierten Kernel an die erste Stelle im Grub2-Menü.

Wer jedoch die Darstellung mit den Untermenüs bevorzugt, kann sich eines relativ simplen Tricks bedienen, um auch nach Kernel-Updates diese Untermenüs zu behalten, ohne die grub.cfg jedesmal von Hand neu zu erstellen.

Dazu benötigen wir zuerst das Paket yum-plugin-post-transaction-actions, welches über

su -c'yum install yum-plugin-post-transaction-actions'

installiert wird. Anschließend kopieren wir die Sample-Action mittels in das Verzeichnis für die Actions und bearbeiten diese anschließend

su -
cp /usr/share/doc/yum-plugin-post-transaction-actions-1.1.31/sample.action /etc/yum/post-actions/
nano /etc/yum/post-actions/sample.action

Im ersten Schritt entfernen wir nun alle Zeilen, die nicht mit einem Raute-Symbol beginnen und fügen anschließend folgende Zeile ein:

kernel:install:grub2-mkconfig -o /boot/grub2/grub.cfg

Diese Zeile bewirkt, das nach jedem Update des Kernels automatisch eine neue grub.cfg erzeugt wird. Auf eine entsprechende Zeile für die Deinstallation eines Kernels können wir verzichten, da Kernel üblicherweise nur während eines Kernel-Updates entfernt werden und ansonsten die grub.conf mehrmals nacheinander erzeugt werden würde, was darüber hinaus den Update-Vorgang unnötig in die Länge ziehen würde.

Für den Fall, das man einen Kernel manuell deinstalliert, empfiehlt es sich, auch die grub.conf manuell neu zu erstellen.

VirtualBox: dkms.conf wird nicht gefunden

Wer die proprietäre Version von VirtualBox nutzen möchte und bei der Installation die Fehlermeldung

Error! Could not locate dkms.conf file.
File:  does not exist.

bekommt, sollte einfach mal folgendes probieren:

Mittels cd /var/lib/dkms/vboxhost in der dkms-Verzeichnis für die VirtualBox-Kernelmodule wechseln und folgendes Kommando ausführen:

su -c'rm -r 4.1*'

Durch diesen Befehl werden alle dkms-Einstellungen für VirtualBox gelöscht und die Kernelmodule sollten sich anschließend mittels

su -c'/etc/init.d/vboxdrv setup'

ohne Probleme compilieren lassen.

Nichts desto trotz übernehmen wir keine Verantwortung, falls das eigene System durch diese Anleitung unbrauchbar gemacht werden sollte. Das Befolgen dieser Anleitung geschieht somit auf eigene Gefahr!

Kommt grubby auf das Abstellgleis?

Ben Roser hat auf der Entwickler-Mailingliste vorgeschlagen, bei der Installation von Kernel-Paketen grubby durch grub2-mkconfig zu ersetzen.

Er begründet seinen Vorschlag damit, das grub2-mkconfig nur einen Eintrag für Fedora erstellt und sämtliche installierten Kernel in einem Untermenü verbirgt, was seiner Ansicht nach deutlich übersichtlicher ist. Grubby hingegen fügt alle installierten Kernel direkt ins Hauptmenü ein, was auf Dauer und vor allem bei Multiboot-Systemen zu Lasten der Übersichtlichkeit geht.

Dem momentanen Verlauf der Diskussion nach zu urteilen, stehen die Chancen für eine Umsetzung des Vorschlags nicht schlecht, da die übrigen Teilnehmer der Diskussion mit der momentanen Situation ebenfalls nicht zufrieden sind. So merkt Andre Robatino in seinem Beitrag zu der Diskussion beispielsweise an, das er momentan dazu tendiert, grub2-mkconfig nach jedem Kernel-Update manuell auszuführen, um das Grub-Menü übersichtlich zu halten.

Fedora 16 bekommt Kernel 3.2

Ausgelöst durch die Ankündigung von Linus Torvalds auf Google+, das der Support für den Kernel 3.1 mit dem 3.1.9 Release endet, wurde auf der Entwickler-Liste von Fedora die Frage gestellt, ob Fedora 16 auf den Kernel 3.2 „rebased“ wird.

Josh Boyer hat diese Frage in einer Mail an die Entwickler-Liste mit einem eindeutigen „Ja“ beantwortet. Sobald der Kernel 3.2.1 freigegeben wird, wird auch das Update für Fedora 16 auf den Kernel 3.2 vorbereitet.