Monthly Archives: September 2024

Tablets: Was man für 3 Watt mehr an Leistung bekommt

Posted on by

Den Artikel habt Ihr bestimmt gelesen:

Linux auf dem TerraPad 1262v2 von Wortmann

Tablets: Was man für 3 Watt mehr an Leistung bekommt

Es sind ein paar Tage ins Land gegangen und ich möchte ein bisschen von meinen Erlebnissen berichten.

Das TerraPad läuft bis auf das bekannte Problem mit der Kamera gut. Der Chip kann per i2c nicht sauber angesprochen werden, das ist alles. Wie ich am Surface schon festgestellt habe, ist im Treiber für das Keyboard ein fett krasser Bug drin, den ich mal irgendwem mitteilen müßte, zum Teil werden Phantomanschläge und Mausklicks durch Tastatureingabe „erzeugt“, was nervig ist wenn man was schreiben will.

Das Laufzeitverhalten ist genauso wie prognostiziert ca. 9h bei moderater Nutzung, sprich Videogames oder -filme gehören nicht zum Nutzungsprofil 🙂

Standbye-Mode und ähnliches läuft astrein, keine Probleme festzustellen.

Die „Super“ Taste auf dem Touchfscreen ist genau das: super 😀  Allerdings lassen sich kleinere Probleme beim Treffen der Taste feststellen, besonders im Dunkeln.

Apropos Dunkel, die -> beleuchtete <- Tastatur vom Surface ist einfach besser, auch die Softtasten sind insgesamt wertiger.  Die linke Shifttaste ist nicht nur bei mir etwas schwergängig, was gerade bei Passworteingaben nervt. Da muß man einen höheren Anpressdruck einplanen.

Jetzt tauchte das StarLite Tablet auf meinem Horizont auf: https://de.starlabs.systems/pages/starlite?shpxid=2a0cdff5-d669-43ba-8759-734df0f0d896 das mit 6W weniger Strom verbraucht als das TerraPad mit 9W und einige Spezialanpassungen brauchte. Es wäre für 668€ (vermutlich brutto) zu haben.

Für die 3 Watt die die CPU vom TerraPad mehr vom Batteryblock haben will, habe ich hier mal eine Übersicht, was man dafür bekommen:

Quelle: https://www.cpubenchmark.net/compare/5178vs4890/Intel-N200-vs-Intel-i5-1230U

Man bekommt also mehr als doppelt soviel Rechenleistung raus und das merkt man auch z.b. beim Spielen. Das StarLite meint zwar, es hätte 12 Stunden Laufzeit, aber wohl eher nur, wenn man es nicht benutzt. Das kann fast jeder 😉

Kleine Probleme mit dem Wechsel von Bluetooth-Geräten

Wer gerne und gut Musik hören will, besonders wenn man niemanden stören möchte, setzt Kopfhörer oder InEar-Plugs ein. Die letzteren kommen oft als schnurlos per Bluetooth daher. Wenn man diese Buds häufig zwischen verschiedenen Endgeräten tauscht, dann klappt das mit dem Verbinden nicht mehr. Die Lösung ist einfach: Gerät entfernen und neu Pairen. Meisten passiert das, wenn die InEar-Plugs neugestartet (Reset) werden müssen, weil sie nicht mehr wollen.

Ein Gerät aus der BT-Liste zu entfernen ist bei Gnome per se kein Problem, aber braucht leider einige Klicks mehr 🙁 Da könnte man bei Gnome auch mal über eine Verbesserung der Usability nachdenken.

Kleiner Nachtrag: So siehts aus 😀

PVA: ups … da fehlte was bei der „KI“

Benutzer, die Carola PVA per RPM installiert haben, mußten leider feststellen, daß Ihr Assistent nicht funktioniert hat.

PVA: ups … da fehlte was bei der „KI“

Der Push der „KI“ Funktion hat leider bei allen, die keine „KI“ Config hatten, und das dürften viele gewesen sein, zu einem kleinen Startproblem geführt. Wer die Githubversion benutzt hat, hatte da weniger Probleme.

Die Patche dafür sind raus, die RPM’s auch, also updated jetzt bitte und startet dann den Clienten neu.

Wenn Grub nicht mehr bootet

Posted on by

Manchmal haben Bugs eine Geschichte und die Geschichte dieses Grubbugs wird heute erzählt werden.

Wenn Grub nicht mehr bootet

Damit der Eintrag nicht zu lang wird, gibt es nur die Highlights. Nehmt einfach an, daß da noch viel mehr in Spiel war 😉

Vor ein paar Jahren stellte ich auf meinem Fedora Surface Tablet fest, daß trotz dessen, daß neue Kernels installiert wurden, diese nicht im Bootmenü angezeigt wurden bzw. der gewählte Bootkernel nicht benutzt wurde, dafür waren uralte Einträge da drin bzw. nahm er immer den ersten Kernel.

Weil es eine recht neue Installation und das Gerät ein UEFI Bios hatte, wurde eine EFI Partition angelegt und eingebunden, ganz so, wie das sein muß. Auf dieser EFI Partition wird vom OS, hier Fedora, ein passender Ordner angelegt und u.a. der BootShim hingelegt:

[root@surface fedora]# ls -la /boot/efi/EFI/fedora/
insgesamt 17654
drwx------. 3 root root 2048 20. Sep 18:03 .
drwx------. 4 root root 2048 19. Jul 2023 ..
-rwx------. 1 root root 112 19. Mär 2024 BOOTIA32.CSV
-rwx------. 1 root root 110 19. Mär 2024 BOOTX64.CSV
drwx------. 2 root root 2048 4. Apr 19:36 fonts
-rwx------. 1 root root 2960704 12. Apr 01:00 gcdia32.efi
-rwx------. 1 root root 3972416 12. Apr 01:00 gcdx64.efi
-rwx------. 1 root root 6523 3. Okt 2020 grub.cfg
-rwx------. 1 root root 6699 3. Okt 2020 grub.cfg.bak
-rwx------. 1 root root 7414 6. Nov 2022 grub.cfg.rpmsave
-rwx------. 1 root root 1024 3. Okt 2020 grubenv.bak
-rwx------. 1 root root 1024 4. Apr 19:08 grubenv.rpmsave
-rwx------. 1 root root 2960704 12. Apr 01:00 grubia32.efi
-rwx------. 1 root root 3972416 12. Apr 01:00 grubx64.efi
-rwx------. 1 root root 673992 19. Mär 2024 mmia32.efi
-rwx------. 1 root root 848080 19. Mär 2024 mmx64.efi
-rwx------. 1 root root 949424 19. Mär 2024 shim.efi
-rwx------. 1 root root 747681 19. Mär 2024 shimia32.efi
-rwx------. 1 root root 949424 19. Mär 2024 shimx64.efi

Wie man sehen kann, liegt hier eine grub.cfg und eine grubenv , diverse Backups durch RPM und mich rum. Die gleichen Dateien findet man unter /boot/grub2/ auch nochmal, dort gehören Sie aber eigentlich auch hin.

Damals passierte folgendes

GRUBBY schrieb die Änderungen der Bootreihenfolge nach /boot/grub2/grubenv , aber GRUB lud die grubenv von /boot/efi/EFI/fedora/grubenv. Das ist die Quintessenz einer langen Investigation.

Die ganze Geschichte war etwas komplizierter, wie man in Bug #1625124 sehen kann.

Die Lösung war damals einfach: eine der Dateien mußt zur Anderen verlinkt werden.

ln -s /boot/efi/EFI/fedora/grubenv /boot/grub2/grubenv 

Damit waren beide immer in Sync und das von GRUB selbst geschaffene Problem, zwei verschiedene Orte zu benutzen, behoben. Jahrelang blieb der Fix bestehen und das mittlerweile auf Fedora 39 aktualisierte Tablet bootete immer korrekt.. bis diesen Montag 🙁 Da bootete es nicht mehr.

Stattdessen kam nur die GRUB-Shell. Alles reinstallieren vom GRUB-Bootloader, Konfig neu bauen half nichts.Ergo war das ein Fall für Linux am Dienstag, bei dem wir ganz praktisch das Problem besprochen, analysiert, gescheitert und dann final erfolgreich waren \o/

Was war passiert?

Am Wochenende waren Updates eingespielt worden, auch von Kernels und Grub. Was keiner dem Benutzer und damit dem Patch erzählt hat war der Umstand, daß das GRUB Team den 6 Jahre alten Problemfall behoben hat:

[root@surface fedora]# ls -la /boot/efi/EFI/fedora/
insgesamt 17654
drwx------. 3 root root 2048 20. Sep 18:03 .
drwx------. 4 root root 2048 19. Jul 2023 ..
-rwx------. 1 root root 112 19. Mär 2024 BOOTIA32.CSV
-rwx------. 1 root root 110 19. Mär 2024 BOOTX64.CSV
drwx------. 2 root root 2048 4. Apr 19:36 fonts
-rwx------. 1 root root 2960704 12. Apr 01:00 gcdia32.efi
-rwx------. 1 root root 3972416 12. Apr 01:00 gcdx64.efi
-rwx------. 1 root root 159 20. Sep 18:03 grub.cfg
-rwx------. 1 root root 6699 3. Okt 2020 grub.cfg.bak
-rwx------. 1 root root 7414 6. Nov 2022 grub.cfg.rpmsave
-rwx------. 1 root root 1024 3. Okt 2020 grubenv.bak
-rwx------. 1 root root 1024 4. Apr 19:08 grubenv.rpmsave
-rwx------. 1 root root 2960704 12. Apr 01:00 grubia32.efi
-rwx------. 1 root root 3972416 12. Apr 01:00 grubx64.efi
-rwx------. 1 root root 673992 19. Mär 2024 mmia32.efi
-rwx------. 1 root root 848080 19. Mär 2024 mmx64.efi
-rwx------. 1 root root 949424 19. Mär 2024 shim.efi
-rwx------. 1 root root 747681 19. Mär 2024 shimia32.efi
-rwx------. 1 root root 949424 19. Mär 2024 shimx64.efi

Achtet mal auf die Größe der grub.cfg : 159 Bytes

Das steht drin:

# cat /boot/efi/EFI/fedora/grub.cfg
search –no-floppy –root-dev-only –fs-uuid –set=dev 0669a2db-8ba9-4054-a629-cd7cf2eb12c8
set prefix=($dev)/grub2
export $prefix
configfile $prefix/grub.cfg

Man hat also endlich nur noch einen Ort für die Grub.cfg nämlich /boot/grub2/grub.cfg . Die im EFI Ordner ist jetzt nur noch ein Wrapper, der die eigentliche grub.cfg einbindet, so muß man nur noch eine erzeugen und bleibt rückwärtskompatibel, außer, man hatte das Problem selbst bereits gelöst, dann landete man in der GRUB-Shell, weil …

Wenn die GRUB-Config gebaut wird, wird zuerst der kurze Wrapper /boot/efi/EFI/fedora/grub.cfg erzeugt, DANN erst die /boot/grub2/grub.cfg geschrieben.

Wenn aber /boot/grub2/grub.cfg ein LINK auf /boot/efi/EFI/fedora/grub.cfg ist, dann wird die kurze Fassung durch die Hauptkonfig ersetzt und nagelt dabei den Prefix für das Bootdevice weg. Als Folge kann Grub die Bootpartition nicht mehr finden und bootet nicht mehr.

Lösung:

rm -f /boot/grub2/grub.cfg /boot/grub2/grubenv
grub2-mkconfig > /boot/grub2/grub.cfg
grub2-install –force –target=x86_64-efi /dev/nvme0n1 ( in meinem Fall)

Danach war /boot/efi/EFI/fedora/grub.cfg wieder normal und das System hat endlich wieder gebootet.

Dank nochmal an alle die gestern Abend bei Linux am Dienstag geholfen haben, das war knifflig, aber genau dafür machen wir diese Videokonferenz: Linux basteln 😀