Neuer Kernel, neues Glück?

Ich sags Euch, daß Surface Pro4 Tablet macht mich fertig. Heute mit neuem Kernel gebootet und siehe.. die Lüfter springen wieder an. Ergo, konnte ich den Flackerbildschirm von gestern nicht reproduzieren.

Ob das jetzt am nächtlichen Strom-Aus, neuer Treibern im Kernel oder an geänderter Firmware ( wie auch immer das passiert sein mag ) liegt, ich weiß es nicht.

Microsoft Support

Der M$ Support erschien zwar auf dem Papier gut, aber in der Realität schaffen die es nicht mal einen zurückzurufen.

Wir werden sehen, wie es ausgeht.

UPDATE:

Die Firma Microsoft hätte gern einen Type-Teile-Tausch durchgeführt und spendiert neue HW, weil Serienfehler. Ich halte Euch auf dem Laufenden.

Hat nur drei Stunden gedauert bis im Chat wer aufgetaucht ist.

Das wars dann mit dem Linux Tablet :(

Wenig erfreuliche Nachrichten kommen ja immer im Bundle, so auch hier:

Serienfehler in meinem Surface Pro4 schlägt zu

Da nutzt man so ein Gerät mal 2 Monate und schon geht es kaputt. Vorteil, und das muß man hoch anrechnen, M$ wird es wohl komplett austauschen, weil es noch in Garantie und es ein Serienfehler ist.

Klar, wenn die Lüfter ausfallen, grillt der i7 bei Last mal ganz locker die GPU, auch wenn der i7 Chip bis 100 Grad C angegeben ist, geht das ohne Luft nicht lange gut. So kommt es dann zum Flackern des Bildschirms. Das Schicksal hat also auch mein Tablet jetzt erwischt. Ganz offen, könnte ich kotzen, weil der Tausch der Lüftereinheit ist eigentlich eine Kleinigkeit wenn, ja wenn da nicht das verklebte Display wäre.  Der neue Lüfter kostet lediglich 29 € und ist in 10 Minuten getauscht, wenn man eine Heissluftpistole sein eigenen nennt.

Im Fachhandel soll es auch einen Aufsatz fürs Display geben, mit dem der Kleber thermisch gelöst werden kann, ohne das alles andere auch warm wird.

Mal sehen was M$ nachher im Chat dazu sagen wird.

merkwürdiger Bug: Fenster springen auf und ab

„Stell Dir vor, Du kommst zu Deinem Desktop und die Fenster springen rum!“ Gibts nicht? Virus!? Root-Kit!? Tja, das werden wir dann mal lüften müssen.

Die Beschreibung

Wir haben Fedora 29 , Gnome-Shell 3.22 und als Programme Firefox & den SimpleScreenRecorder laufen.

Nach ca. 8 Stunden mehr oder minder Dauerbetrieb sprangen die beiden Fenster immer gleichzeitig zwei Pixel rauf und wieder runter. So sah es zumindest aus, in Wirklichkeit sprang das ganze Display als Geflacker rauf und runter. Hat man aber erst beim extrem genauen hinsehen bemerkt, weil der Hintergrund monochromatisch und dunkel war.

Ursache

„Thermale Überhitzung durch 8 Stunden Dauerencoden.“

Merke, wer mit einem Tablet Tutorials aufnimmt, sollte ab und zu eine Pause machen. Oder wenigsten mal auf Energiesparmodus schalten, damit die CPU eine Chance hat abzukühlen. Wieso da die Lüfter nicht stärker liefen, bleibt ein Rätsel.

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.