XenServer zu alt um Kernel 5.0 zu laden

Wer XenServer und Kernel 5.0.x einsetzen will, sollte jetzt gut aufpassen, sonst => VM Streik

Kernelimage zu neu für XenServer 6.2.x

Da es sich um etwas handelt, daß international wichtig sein könnte, gibts das auf Deutsch und English,
so don’t wonder if you just understand halve of it 😉

Ihr wollt Eure VM booten, bekommt aber diesen Fehler?
You wanne boot your VM and get this message ?

xenopsd internal error: XenguestHelper.Xenctrl_dom_linux_build_failure(2, “ panic: xc_dom_core.c:616: xc_dom_find_loader: no loader\\\““)

Das passiert, weil das Kernelimage mit einer neuen Compressionmethode gepackt wurde, die das alte XEN nicht kann.  The reason is, that your kernel image file is compressed with a new algorithm, your old XEN can’t handle.

Als erstes brauchen wir die UUID der VM:
First, get the UUID of your VM:

xe vm-list | grep -A5 -B5 <vmname>

Um das zu beheben, braucht man den Befehl: xe-edit-bootloader.sh -u uuid
To fix your vm, you need to execute : xe-edit-bootloader.sh -u uuid

/root/xe-edit-bootloader.patched.sh -u 317fb132-283a-56c6-1627-8b39cf944148 -p 1

Nun kann man die Reihenfolge der Bootmenüeinträge so ändern, daß der bisherige Kernel vorn steht. Dann speichern und Editor beenden und jetzt sollte die VM auch wieder starten.
Now you can change the order of your grub menuentries to the last working kernel being first. When you have saved and exited the editor, the parition will be unmounted and you can start your VM again.

Tipps – Additional hints for you

Der Befehl mountet die Systemplatte der VM und lädt die gebräuchliste grub.conf. Das wird aber vermutlich nicht auf anhieb klappen. Man muß etwas über das Festplattenlayout der VM wissen:
This will mount your VM’s main disk and access the most likely location of your grub.conf, but that will not work without your knowlage of the VMs structure:

-p: Partition number to mount (default: none)
-f: Location of bootloader config file to edit

Wenn man eine traditionelle SDA1 SDA2 Partitionierung in der VM hat, dann gibt man -p die Partitionsnummer der Platte an, wo man /boot/ finden kann. Wer LVM in der VM benutzt, dürfte jetzt so ziemlich am Arsch sein. Kleiner Tip, exportiert die VM auf einen neuern XenServer.

If you have a sda1 and sda2, where sda2 is swap, that -p 1 will mount partition 1 and your good to go.
If you have i.e. a seperate boot partition, you need to know it’s number.
IN CASE you have LVM inside your VM, i guess your screwed now. In this case, export it to a newer XenServer Version.

Weil sich Grub1+2 ein bisschen uneinig wegen der Verzeichnispfade sind, kann man Position der grub.cfg mit -f angeben. Wer eine eigene /boot Partition hat, braucht dann nicht /boot/ hinschreiben, -f grub2/grub.cfg reicht.

Grub1+2 differ a bit, where to find the grub.conf file. Thats where -f will be handy. You can just tell it, if you knew it: -f /boot/grub2/grub.cfg   should usally work, except, you are already on /boot (seperate partition) then it’s just -f grub2/grub.cfg .  As theres only a texteditor loaded, you could try to change other files too 😉

Ich habe einen gepatchten xe-edit-bootloader, der mir erlaubt, gleich die ganze Platte in Dom0 zu mounten. d.h. ich kann alles in der VM anpassen, nicht nur Textdateien, was extrem praktisch ist.
Why is my xe-edit-bootloader.sh  patched? because i adapted it to just mount the disk and wait for me to explore the disk. That’s so helpfull, you won’t believe it.

Bei einigen Systemen kann durch setzen der $EDITOR Variablen auf „/bin/bash“ eine Shell bekommen, aber ich rate davon ab, daß auf Produktivsystemen auszuprobieren, das könnte böse Nebenwirkungen haben.
In rare cases it’s possible to trick the script with the $EDITOR variable set to „/bin/bash“ to open a bash shell for you, but i really suggest not to mess with your dom0 on a production system.

Tablet ohne Tabletfunktionen: INTEL i915 IPTS

„Das kann nicht wahr sein!?“ Durchatmen.. “ ***** **** *** ***** *********** **** *********!“ ist besser so. Das kann einfach nicht wahr sein, oder ? Da hatte man ein Probegerät, daß sofort ging, und dann sowas. Stand der Dinge: Ein sehr teures, wenn auch recht leistungsfähiges Laptop mit nur einem USB Anschluß und einem Pappdeckel als Tastatur!

INTEL i915 IPTS

Das Ende vom Lied, M$ hatte dem Pro4 neue spezial Hardware von Intel spendiert um es mit dem i7-6th Gen auch voll ausreizen zu können. Natürlich hatte Intel M$ alle Infos gegeben um mit dem Chipsatz zu arbeiten, aber der freien Welt hatte man das nicht rechtzeitig mitgeteilt. Also: kein Touch, WLAN nur begrenzt, keine Kameras, und davon hat das Tablet gleich zwei Stück.

Auch wenn es im Dorf Braunschweig das zweite Tablet mit Linux war, in der Welt war es das nicht. Andere hatten das Problem auch schon vorgefunden und keine Lösung gehabt, bis Jake Day in seinem GithubRepo eine Patchserie für den Kernel veröffentlichte, und damit einen Teil des Problems löste.

Kernel selber bauen

Oh man, den Kernel also selbst bauen. Wieso nicht, habe ich früher öfter gemacht und einige GrSecurity Bugs behoben. Eigentlich hatte ich ja gehofft, daß diese Zeiten vorbei wären, aber watt mutt, datt mutt sagten sie auf dem Dorf meines Onkels immer. Daher für Euch jetzt die Anleitung, wie man das macht.

Jetzt muß ich vorher sagen, daß Jake seine Anleitungen für Ubuntu & Co geschrieben hat, was einige Adaptionen für Fedora nötig gemacht hat. Die kommen teilweise von Zak Myth.

Vorbereitungen

Ich habe mir das Leben einfacher gemacht und erstmal den SSHD so umkonfiguriert, daß ich mit Schlüssel auf das Surface drauf konnte und alle Kommandos vom PC absetzen konnte. Solltet Ihr auch machen, weil das TypeCover zwar funktioniert, aber nicht so schön, wie die eigene Tastatur ist 🙂

Zunächst mal die Tools, die wir brauchen werden installieren:

dnf groupinstall „Development Tools“
dnf groupinstall „C Development Tools and Libraries“
dnf install elfutils-devel openssl-devel perl-devel perl-generators pesign ncurses-devel

Dann brauchen wir natürlich den Source:

cd /root
mkdir -p kernel/4.19.23
mkdir -p patche/4.19
cd patche/4.19
git clone https://github.com/jakeday/linux-surface.git

Jetzt Setupen, also einstellen was man an Patchen haben will. Hibernate wäre clever, wenn man keine verschlüsselte Festplatte hat.

chmod 700 setup.sh
./setup.sh
cd /root/kernel/4.19.23
git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git .
git checkout v4.19.23
vi Makefile

Hier ändern wir jetzt den Wert für „EXTRAVERSION“ auf z.B. „-surface-pro4“ . Damit bekommt man einen Zusatz am Kernelfile, was im Grubmenü später für Klarheiten sorgt. Wir wenden die Patche auf den Kernel an:

for i in ../../patche/4.19.23/patches/4.19/*.patch; do patch -p1 < $i; done

kopieren die aktuelle Fedora Kernelconfiguration, die ja so schlecht nicht ist :

cp /boot/config-4.20.6-200.fc29.x86_64 .config

man muß aber beachten, daß Ihr den für Euch neuesten Kernel und dessen Config benutzt! Dann erzeugen wir ein Backup:

make oldconfig

passen die config an :

vi .config

make -j `getconf _NPROCESSORS_ONLN` bzImage
make -j `getconf _NPROCESSORS_ONLN` modules
make -j `getconf _NPROCESSORS_ONLN` modules_install
make -j `getconf _NPROCESSORS_ONLN` install

und reboot.

Und wer vorher mal das Bootmenü wie im Artikel Wie man den GRUB2-EFI-Bootfont ändert beschrieben angepaßt hat, der kann sich jetzt auch den eigenen Kernel aussuchen ohne Augenschäden befürchten zu müssen.

Der Rückschlag

„Nichts ist, wie es scheint.“ der Leitspruch aus dem Film 23 trifft natürlich mal wieder voll ins Mark. Surface bootet nicht, weil dem Kernel nicht vertraut wird. Also muß man dem Surface Bios sagen, daß es doch bitte mitspielen soll. Am Ende wollte es nicht mitspielen ohne einen roten Balken einzublenden, daß wir ohne trusted Plattform usw. arbeiten und dann gings.

Der Kernel triggert dann im Bootprozess SELinux an, doch mal alles umzulabeln, weil ist ja jetzt per Se unsicher usw. Nervig 5 Minuten später der nächste Reboot und nun kanns endlich losgehen.

Und ja.. TOUCH GEHT! \o/

Wie jetzt, daß geht nur 5 Minuten lang ?

Mehr dazu im nächsten Teil der Serie 😀

Das Surface Pro 4 mit dem Linux Touch

Surface Pro4 … und nichts ist wie es sein sollte

Das Surface Pro4 kam prompt. Der Verkäufer war seriöse, das Gerät in Ordnung, genau wie in der Beschreibung. Eigentlich ein idealer Zeitpunkt vor Freude in die Luft zu springen. Ok, es kam aus der Kälte, also durfte es erst einmal warm werden.

Die Generation macht den Unterschied

Dann der Boot. Der Erzfeind erscheint: Windows 10. Der alte Besitzer hatte es frisch reinstalliert. Ok. Also dann USB-Stick dran und davon booten. Das ging noch. Der Livestick lies sich booten, wenn man im Bios den Bootmanager benutzt und per „Wischen“ sagt: „boote von dem wo ich gewischt habe“. Ja, man hat schon einfachere Bootmanager gesehen 🙂

Fedora bootet. So weit, so gut. Erstmal ein Backup von der alten Platte machen, besonders von der Windows Recovery. Gnome-Disks führte das anstandslos durch. Ein paar Gigabytes später, lagen zwei Partitionen der SSD auf meiner Backupplatte, vielleicht will man das Gerät ja mal weiter verkaufen, da könnte unschönerweise Windows helfen.

Die Installation

Ok, jetzt Fedora installieren. Jooooo.. wie man das von einem i7 und SSD erwarten würde, war das in wenigen Minuten erledigt. Neustart ausgewählt und ….  ging natürlich nicht so einfach. Der wollte doch jetzt glatt primär den Stick booten. Ernsthaft?! Da half nur das Tutorialvideo der M$ Hilfeseite ansehen, etwas textlich zu beschreiben reicht heute offensichtlich nicht mehr 🙁  Na gut. Bootmanager umgestellt, permanent gemacht, und nun bootet auch die SSD durch. Hat ja nur eine halbe Stunde Zeit gekostet. Wer braucht schon benutzerfreundliche und einsichtige Biosware ?

Also auch das Hindernis genommen, aber jetzt kann es … was zum Geier … wer soll das denn lesen können? Das Grubmenü war nur schwer mit Ü40 Augen zu lesen um nicht zu sagen, der klassische Sherlock hätte seine helle Freude gehabt. 3k Display halt, das war zu erwarten gewesen, aber eigentlich hoffte ich auf eine automatische Anpassung, weil die Riesenauflösung ja bekannt zu seien schien. Jetzt wisst Ihr auch, wieso es diesen Beitrag zu Die Schriftgröße des Bootprozesses anpassen gab 😉

Es bootet ja, da kann ja nicht all zu viel schief gehen, denkt man so. Naiv, ich weiß. Die nächste Hürde, und gut, daß ich ein gebrauchtes Gerät mit TypeCover ( so heißt das anflanschbare Keyboard von M$ ) bestellt habe, weil sonst wäre ich an der Festplattenverschlüsselung gescheitert. Ja, ich Wahnsinniger wagte eine Festplattenverschlüsselung bei einem Tablet einzusetzen und hoffte doch tatsächlich auf ein OSK ( On Screen Keyboard ) mit dem man das Passwort eingeben kann. Die Hoffnung war vergebens. Wo GRUB, wir reden vom Bootloader, also dem primitivsten Teil des Systems, der eigentlich kaum Userinteraktivität nötig hat, schon ein virtuelles Keyboard einblendete!!! da wagt es der Luksunlocker wirklich, ohne ein OSK daher zu kommen 🙁

Und Gnome startet

Fairerweise muß ich sagen, hatten wir das bei dem Pro3 im Januar nicht mit Krypto gemacht, daher war es ein Wagnis. Ok, verloren. Naja, nicht so schlimm, Bugreport an Red Hat, mal sehen was passiert. Krypto muß halt sein, schon falls das geklaut wird, da habe ich keinen Bock drauf, daß einer auf meine SSD glotzt. Hey, ein Loginscreen… 🙂  Ein Klick und Gnome ist da.

Hinweis: die meisten Screenshots sind auf FullHD reduziert worden.

Gnome Terminal mit OSKDas OSK von Gnome ist staaaaarkkkkkk verbesserungswürdig, weil:

– keine Umlaute
– keine Cursorsteuertasten
– kein deutsches Layout (mit Umlauten)

Auch dazu ist bereits ein Bugreport abgesetzt, denn schliesslich gibt es da eine Regions&Sprach Taste, die auch das Keyboardlayout umstellt, nur halt nicht im OSK 😀

Jetzt haben wir uns soweit vorgekämpft, dann laß uns mal das Touchgerät austesten…

What the Fuck !?!?!

„Herzlichen Glückwunsch zu Ihrem neuen Angeberlaptop! … und jetzt nerven Sie uns nicht weiter.“

Im nächsten Teil geht es um : INTEL i915 IPTS

Tablet ohne Tabletfunktionen: INTEL i915 IPTS

Linux – Kernel 4.15.x starten unter 32Bit nicht mehr

Schlechte Nachrichten aus der 32bit Welt.. okok, Insel, soviele sind es ja nicht mehr 😉 Die Fedora Kernel der 4.15er Serie starten bislang nicht in einer paravirtualisierten Xen VM.

Es gibt keinerlei Hinweise auf die Gründe, da die VM nicht mal Dracut starten kann. Bugreport an RedHat ist raus, warten wir es ab. Ich kann derzeit nur abraten 32Bit Kernel mit 4.15 starten zu wollen. 4.14er funktionieren. Ich tippe ja auf die im Kernel verbauten Specture und Meltdown Patche.

Kernel 4.14.14 OOPSt rum

Heute soll es einen kleinen Bericht aus der Praxis mit den neuen Kernelpatchen geben. Seit 2 Wochen bauen die Kernelentwickler an den Patches für Spectre & Meltdown rum. Vermutlich schon länger, aber seit 2 Wochen sind die Ergebnisse im Umlauf 😉 Nach anfänglichen Erfolgen gegen den Angriff, wurden schnell die Probleme zu Tage gefördert, die durch den Patch verursacht werden.

Massenbetatests

Da ich auf unserer Serverfarm die neuen Kernel ausprobiert habe, habe ich die gefundenen Fehler an Redhat gemeldet. Das war vor 14 Tagen, als die Patche rauskamen. Seitdem sind „wir“ (an dem Bugreport sind viele Leute beteiligt) im ständigen Dialog und testen die neuen Kernel unter „real“(tm) Bedingungen aus.

Stand ist, die Kernel funktionieren soweit stabil. Aber einzelne Prozesse in der Virtualisierung und bei JAVA führen immer wieder zu Fehlern. Zwei von den vielen Fehlern, habe ich Euch mal mitgebracht:

Jan 21 06:04:21 xxx kernel: BUG: unable to handle kernel NULL pointer dereference at 0000000000000003
Jan 21 06:04:21 xxx kernel: IP: 0x99cf048
Jan 21 06:04:21 xxx kernel: PGD 461b067 P4D 461b067 PUD 57fd067 PMD 0
Jan 21 06:04:21 xxx kernel: Oops: 0002 [#3] SMP NOPTI
Jan 21 06:04:21 xxx kernel: Modules linked in: nfsv3 nfs fscache fuse nfsd auth_rpcgss nfs_acl lockd grace xt_owner xt_multiport ip6table_filter ip6_tables cfg80211 rfkill xenfs xen_privcmd sunrpc edac_mce_amd crct10dif_pclmul crc32_pclmul ghash_clmulni_intel xen_netfront xen_blkfront crc32c_intel
Jan 21 06:04:21 xxx kernel: CPU: 0 PID: 6020 Comm: xenstore-read Tainted: G D W 4.14.14-201.fc26.x86_64 #1
Jan 21 06:04:21 xxx kernel: task: ffff880005708000 task.stack: ffffc90000d18000
Jan 21 06:04:21 xxx kernel: RIP: e030:0x99cf048
Jan 21 06:04:21 xxx kernel: RSP: e02b:ffffc90000d1bfd0 EFLAGS: 00010206
Jan 21 06:04:21 xxx kernel: RAX: 0000000000000003 RBX: 0000000000000003 RCX: 00000000099cf048
Jan 21 06:04:21 xxx kernel: RDX: 0000000000000002 RSI: 00000000099cf048 RDI: 0000000000000000
Jan 21 06:04:21 xxx kernel: RBP: 00000000ffddc0a8 R08: 0000000000000000 R09: 0000000000000000
Jan 21 06:04:21 xxx kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
Jan 21 06:04:21 xxx kernel: R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
Jan 21 06:04:21 xxx kernel: FS: 00007f8761262b40(0000) GS:ffff88007f400000(0000) knlGS:0000000000000000
Jan 21 06:04:21 xxx kernel: CS: e033 DS: 002b ES: 002b CR0: 0000000080050033
Jan 21 06:04:21 xxx kernel: CR2: 0000000000000003 CR3: 0000000003556000 CR4: 0000000000000660
Jan 21 06:04:21 xxx kernel: Call Trace:
Jan 21 06:04:21 xxx kernel: ? switch_to_thread_stack+0x21/0x40
Jan 21 06:04:21 xxx kernel: Code: Bad RIP value.
Jan 21 06:04:21 xxx kernel: RIP: 0x99cf048 RSP: ffffc90000d1bfd0
Jan 21 06:04:21 xxx kernel: CR2: 0000000000000003
Jan 21 06:04:21 xxx kernel: ---[ end trace 50c257ff957ddb5b ]---
Jan 21 08:17:31 xxx kernel: invalid opcode: 0000 [#4] SMP NOPTI
Jan 21 08:17:31 xxx kernel: Modules linked in: nfsv3 nfs fscache fuse nfsd auth_rpcgss nfs_acl lockd grace xt_owner xt_multiport ip6table_filter ip6_tables cfg80211 rfkill xenfs xen_privcmd sunrpc edac_mce_amd crct10dif_pclmul crc32_pclmul ghash_clmulni_intel xen_netfront xen_blkfront crc32c_intel
Jan 21 08:17:31 xxx kernel: CPU: 0 PID: 7087 Comm: xenstore-read Tainted: G D W 4.14.14-201.fc26.x86_64 #1
Jan 21 08:17:31 xxx kernel: task: ffff88007a873c00 task.stack: ffffc900008c8000
Jan 21 08:17:31 xxx kernel: RIP: e030:0xffd9af11
Jan 21 08:17:31 xxx kernel: RSP: e02b:ffffc900008cbfd0 EFLAGS: 00010206
Jan 21 08:17:31 xxx kernel: RAX: 0000000000000004 RBX: 0000000000000003 RCX: 00000000ffd9af11
Jan 21 08:17:31 xxx kernel: RDX: 0000000000000022 RSI: 00000000ffd9af11 RDI: 0000000000000000
Jan 21 08:17:31 xxx kernel: RBP: 00000000ffd99b58 R08: 0000000000000000 R09: 0000000000000000
Jan 21 08:17:31 xxx kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
Jan 21 08:17:31 xxx kernel: R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
Jan 21 08:17:31 xxx kernel: FS: 00007f2cc2baeb40(0000) GS:ffff88007f400000(0000) knlGS:0000000000000000
Jan 21 08:17:31 xxx kernel: CS: e033 DS: 002b ES: 002b CR0: 0000000080050033
Jan 21 08:17:31 xxx kernel: CR2: 00000000088bb004 CR3: 0000000079d66000 CR4: 0000000000000660
Jan 21 08:17:31 xxx kernel: Call Trace:
Jan 21 08:17:31 xxx kernel: ? switch_to_thread_stack+0x21/0x40
Jan 21 08:17:31 xxx kernel: Code: Bad RIP value.
Jan 21 08:17:31 xxx kernel: RIP: 0xffd9af11 RSP: ffffc900008cbfd0
Jan 21 08:17:31 xxx kernel: ---[ end trace 50c257ff957ddb5c ]---

Die sind vom Kernel 4.14.14, also von gestern 🙂 und wie man an dem Datum sehen kann, sind die Kernel OOPS von heute morgen. Die Beschreibungen die gleich kommen, sind extra simple gehalten, da wohl die wenigsten wissen, was ein IP oder eine NULL POINTER Dereferenz ist. Wer schonmal in Assembler programmiert hat, dem wird das sofort was sagen, dem Rest eher nicht 🙂

Ein Opcode ist eine definierte Bitfolge, welche die CPU als Assemblerbefehl interpretiert und dann macht, was der Befehl meint.

„invalid opcode: 0000 [#4] SMP NOPTI“

Meint, daß die CPU über eine Anweisung gestolpert ist, die nicht definiert ist, in dem Fall eine 0x0000 = 0W . 0W meint den Wert Null (0) auf einer Bitbreite von 16 Bit (= 1 WORD daher das W von 0W => 00000000 00000000. 0L wäre Null(0) auf 32bit auch bekannt als LONGWORD = 00000000 00000000 00000000 00000000).

Das kann nur passieren, wenn ein IP ( Instruction Pointer ) im Speicher wohin gezeigt hat, wo „NICHTS“ war. Das da NICHTS war, war gut so, weil sonst hätte die CPU womöglich die dortigen Bits&Bytes als Befehle interpretiert und wäre Amok gelaufen.

Trivia: Wenn man eine CPU dazu bekommt, so einen Fehler zumachen während sie einen fremden Prozess(z.b. für root) ausführt UND bestimmen kann, WO im Speicher weitergemacht wird, hat man einen EXPLOIT geschafft, also einen ANGRIFF durchgezogen. Das ist dann immer das, was in den Medien landet 🙂

NULL pointer dereference

kernel: BUG: unable to handle kernel NULL pointer dereference at 0000000000000003
kernel: IP: 0x99cf048
kernel: Oops: 0002 [#3] SMP NOPTI

Das ist eine NULL POINTER Exception. Da ist die CPU über einen falschen IP(siehe oben) zu einer Adresse im Speicher gesprungen, wo ein weiterer Zeiger(Pointer) hätte sein sollen, es stand aber nur „0L“  dort.

Das ist eigentlich ein Programmierfehler, denn man müßte Zeiger genau auf „0L“ prüfen, bevor man sie benutzt. Da stellt sich jetzt die Frage, reagiert der Kernel seit den Patchen empfindlicher auf den Fehler ( der womöglich schon seit Jahren da war) oder ist der Fehler durch den Patch entstanden?

IMHO:

Es zeigen sich jetzt lustige Programmierfehler in allen möglichen Sachen/Kernel, weil der schlampige Stil jetzt nicht mehr hinhaut 😀 In C und C++, worin die Masse des Kernelcodes und der Anwendungen geschrieben ist, gibt es das Konstrukt des Doppelzeigers, also einem Zeiger auf einen Zeiger. Natürlich gibt es dafür eine Abkürzung im C Code die auch gern genommen wird, nur daß dabei der Code nicht prüft, ob da 0 als Zeiger steht. Das würde nämlich Performance kosten und genau die will man ja damit erreichen. Der Code geht also davon aus, daß die Zeiger immer stimmen, also optimistische Grundeinstellung des Entwicklers. Seit dem Patch kann man sich da wohl nicht mehr drauf verlassen.

Fazit

Aber zurück zur Situation, wenn man unbedingt muß, kann man die 64Bit Kernel benutzen. Für daheim ist das eh kein Problem, so weit ich das von meiner Serverfarm ableiten kann, betrifft es nur VM und JAVA Prozesse (z.b. Jitsi / Tomcat usw.). Die 32Bit Kernel sind besonders anfällig und derzeit noch nicht zu empfehlen, aber wer braucht auch noch 32bit ?

Die meisten werden die neuen Kernel also ohne Probleme fahren können.

Wer den 4.14.14 Kernel für Fedora 26 haben will :  https://koji.fedoraproject.org/koji/taskinfo?taskID=24303894

Eure Distros werden ähnliche Buildumgebungen haben, wo die aktuellen Testkernel gebaut werden.