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

suchen nach INTEL_IPTS und auf „m“ setzen.

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 😀

Games: Astrolords mit Touchsupport?

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

Games: Astrolords mit Touchsupport?