Fedora erobert das Pinephone

Na…? Ward Ihr schon auf der Pine64 Shopseite und habt Eurer neues Projekthandy geordert? Ach Ihr habt den Artikel am Samstag gelesen und seid der Ansicht, daß es noch nicht so weit wäre. Also, das können wir ändern 😀

Fedora erobert das Pinephone

Selbst wenn Ihr es am Samstag noch geordert hättet, es wäre noch nicht da, aber das bedeutet nicht, daß Ihr nicht schon vorarbeiten könnt. Schritt 1 wäre eine schnelle MicroSD Karte mit 16 GB+ zu kaufen und sich einen passenden SD-Kartenleser zu organisieren. Mein Laptop war nämlich nicht in der Lage die schnelle Karte anzusprechen 😉 Mein Tablet allerdings schon und weil ich eh eine 256er Karte gekauft hatte ( kosten so um die 34 € ), habe ich die 128er aus dem Tablet ins Handy gesteckt.

Fangfrage: Wozu brauchen wir die SD-Karte, wenn doch schon ein Speichermedium mit 32 GB im Handy drin ist?

Nun, auf der internen Karte ist Manjaro drauf. Das könnte man überschreiben, aber dann wäre es weg. Und wir möchten doch unser neues Telefon nicht gleich am ersten Tag bricken, oder? 😀

Folgender Hinweis

Alles was Sie hier sehen, lesen oder hören, ist ohne Gewähr. Wenn Sie Ihr neues Telefon oder Ihren PC schrotten, ist das nicht mein Problem.

Das gesagt, geht es gleich los. Um ein Image schreiben zu können, muß man aber überhaupt erst einmal eines haben: Auf der Webseite PP Fedora Sdsetup findet man einen passenden Link dazu:

zur Zeit : https://github.com/nikhiljha/pp-fedora-sdsetup/releases/download/v0.2.0/fedora.tar.xz

Der Link kann sich jederzeit ändern, da die Basis Images alle paar Wochen neu gebaut werden. Hat man es erst einmal auf dem Handy, gibt es ganz normale Updates per dnf. Jetzt kann man zu recht sagen, „ja, aber was ist das für eine Quelle, wo kommen die Pakete her?“ Ihr werdet lachen, direkt von Fedora. Das ist lediglich ein bereits um die nötige Pinesoftware erweitertes Image mit einem zusätzlichen Fedora COPR-Repository von nikhiljha für die Spezialsoftware wie Megapixels, Chatty, Calls etc. .

Das Image muß nur noch im Dateimanager ausgepackt werden:

Image auspacken

Die Anleitungen zum Brennen von Images auf SD-Karten fürs Pine haben eins gemeinsam, die wollen das Image in der Konsole auf die Karte schreiben. Dabei ist das gar nicht nötig. Gnome-Disks aka. Laufwerke ist Eurer Freund. Wie man damit ein Image auf einen Datenträger schreibt, findet Ihr hier:

Fedora: Wie man ein ISO auf USB brennt

Ihr wählt also die SD-Karte als Ziel aus und als Image die .img Datei aus dem .tar.xz Archiv. (xz ist nur ein anderes Kompressionsprogramm als GZIP ).

Während das Image auf Eure Karte geschrieben wird, ein paar Hintergrundinfos über Fedora auf dem Pinephone.

Bleeding Edge und noch einen Schritt weiter

Das Pinephone benötigt zum Funktionieren Software, die hoch experimentell ist, dies nennt man Bleeding Edge. Daher kommen die Pakete direkt aus dem RawHide Repository von Fedora. RawHide ist die Alphaversion von Fedora. Natürlich ist da nicht alles experimentell. Die meiste Software wird bloß gegen neue Teile des Betriebssystem wie LibC usw. frisch kompiliert, ist aber ansonsten stabil. Es fliegt einem also nicht gleich immer alles um die Ohren, auch wenn Ihr hier natürlich anderes lesen werdet ;D Keine Panik, es war alles ohne Magie und Reinstall zu beheben. Es kann aber immer mal passieren, daß neue Libs für Ärger sorgen. Das war z.b. beim Mesa- und dem Bind-Libs-Update der Fall. Danach starten die Internet-Apps nicht mehr. Was man dagegen tun kann, wird man in Zukunft hier lesen können.

Ich werde im Blog entsprechende Warnungen posten, wenn etwas bekannt wird. Eine andere Quelle ist die Issue-Übersicht im Github. Da Ihr da aber nicht alle Fälle lesen werdet, genauso wenig wie bei mir, wäre es ratsam beide Seiten im Auge zu behalten.

Partionierung der SD-Karte

Das Image dürfte jetzt drauf sein. Da es nur 4.x GB hat, und Ihr eine 16 GB+ Karte verbaut habt, müssen wir doch in die Konsole. Also Terminal aufmachen und Root werden „sudo su“.

Ich hoffe Ihr habt Eurer Laufwerketool im Blick, Ihr braucht jetzt eine wichtige Info:

Bei Euch wird stehen, das es jede Menge ungenutzten Platz gibt. Das ist klar, weil das Image ja nur 4 GB groß ist. Wer Parted nicht installiert hat, möge das jetzt bitte nachholen: „sudo dnf install parted“

  • 1. sudo parted /dev/<SD-Device>

Wichtig: Das was oben bei Kartenleser steht, hier im Beispiel /dev/mmcblk0, ist Eurer <SD-Device> .

  • 2. Im parted gebt Ihr jetzt diese zwei Befehle ein:
    • (parted) resizepart 2 100%
    • (parted) quit

Damit wurde die Größe der Partition auf den zur Verfügung stehenden Platz vergrößert. Wie man oben sieht ist das dann alles 😉 Wer Lust hat, könnte sich alternativ eine Home-Partition anlegen. Jetzt braucht es nur noch eine Anpassung des eigentlichen Filesystems und wir sind fertig:

  • 3. sudo resize.f2fs /dev/<SD-Device_PARTITION2>
  • <SD-Device_PARTITION2> ist im Beispiel oben /dev/mmcblk0p2.

Der Moment der Entscheidung ist da

  • Jetzt zieht die Karte ab und steckt sie ins Pinephone, genau wie auf jedem anderen Handy auch. Deckel zu machen, und Pinephone starten. Die Zugangsdaten sind Username „pine“ / Passwort „123456“, was auch gleichzeitig der Entsperrcode ist.

Eine Frage bleibt, wollt Ihr Phosh nutzen, oder Gnome?

Im Screenunlocker müßt Ihr Euch jetzt für einen Desktop entscheiden. Leider merkt der sich das nicht, was bei Phosh bedeutet, daß man das ganze Handy neu booten muß.

Ich persönlich favorisiere Gnome, denn Phosh ist noch so unausgegoren, daß ich Euch nicht mal ein Bildschirmfoto davon zeigen kann, weil es nicht ausgenommen werden kann. Deswegen hier ein verwackeltes Archivfoto mit einem anderen Handy 😉 Zur Gegenüberstellung, das was Euch mit Gnome-Shell am Ende der ersten Artikelserie zum Pinephone erwartet:


Phosh

Gnome-Shell nativ

Die Initialisierung der Gnome-Shell dauert etwas, keine Panik 😉 Aber so macht ein Handy Spaß, oder? 😀

Ich favorisiere es übrigens quer, das gibt am wenigsten Probleme. Es sind natürlich noch einige Arbeiten an dem Handy zu machen. Was das alles ist, kommt im nächsten Teil der Serie in 3 Tagen!

Was Ihr Euch bis dahin verkneifen solltet: einfach ein komplettes Update zu machen, weil im Repo letzte Woche zwei Killerupdates gelandet sind, die die Funktionalität des Handy beeinflussen. Wer es sich doch nicht verkneifen kann, weil er auch die Cam und GPS austesten muß, der findet hier eine DNF Config, die das schlimmste verhindert:

# cat /etc/dnf/dnf.conf
[main]
keepcache=True
gpgcheck=1
installonly_limit=3
clean_requirements_on_remove=True
best=False
skip_if_unavailable=True
exclude=mesa* bind* gnome-shell* mutter*

Letzter Artikel der Serie:

Pinephone: Endlich! Linux auf dem Handy

nächster Artikel:

Das nackte Pinephone aufmotzen

 

 

Pinephone: Endlich! Linux auf dem Handy

Ja, ich gebs zu, ich habe es getan! Ich habe mir ein PinePhone 1.2 zugelegt.

Pinephone: Endlich! Linux auf dem Handy

Donnerstag vor einer Woche war es soweit, mein nur eine Woche vorher geordertes Pinephone erreichte mich eher überraschend. Statusinformationen zum Versand gibt es so gut wie keine, wenn man bei Pine etwas bestellt. Die Bestellung an sich war kurz und schmerzlos: Modell auswählen „2 oder 3 GB RAM“, Lieferadresse eingegeben und mit Paypal bezahlt.

Link zu PinephoneDas neue Telefon erreichte mich dann an einem Tag, an dem ich glücklicherweise frei hatte, also wurde das Telefon in Betrieb genommen und kurz geladen. Und damit kommen wir schon zum ersten Tip: Nehmt ein passendes Werkzeug, weil an Tag 1 bekommt Ihr den Deckel der Rückseite niemals mit dem Fingernagel auf 😀 Wenn das erstmal ein paar mal gemacht wurde, dann geht es ohne Probleme auch mit dem Fingernagel. Vor dem Laden muß man nämlich zunächst die Transportsicherung des Akkus entfernen und die MircoSIM-Karte einlegen. Hat man das geschafft kommt Level Zwei der Inbetriebnahme: Das Telefon entsperren 😉 Anders als Android und iOS Geräte, kommt das Pinephone im abgesicherten Modus aus der Box.

Apropos Box: Das übliche Unboxingvideo verkneife ich mir, so etwas machen nur Clickhuren auf Youtube 😉

Ab jetzt wird es spannend 😀

Abhängig von der vorinstallierten Distribution ist das Entsperrpasswort anders. Für meine Manjaro Community Edition lautetet es „123456“ und das sollte Euch irgendwie bekannt vorkommen 😀

Für später merken: Aufgabe Nummer Eins lautet Passwörter ändern!

Nach dem erfolgreichen entsperren bekommt man das hier zu sehen ( mangels Screenshotfunktion in Handyqualität 🙁 ) :

Sieht aus wie AndroidWas Ihr hier seht, ist die Phosh Oberfläche. Das ist eine Gnome-Shell mit stark an das Handy angepasster Funktion und im reinen Handybetrieb ist das auch gar nicht so falsch. Die Probleme kommen mit den Details. Damit es eine funktionsfähige Version der Oberfläche gab, mußte z.b. die automatische Bildschirmrotation abgeschaltet und durch einen Wahlschalter ersetzt werden. Was ihr dem Foto nicht entnehmen könnt, ist der Umstand, daß es ein 2:1 Format hat, es also berechtigter Weise als Handyknochen bezeichnet werden darf 😉 2:1 meint, es ist doppelt so hoch wie breit. Damit sind Probleme aller Art vorprogrammiert, die man mit Phosh aber nicht lösen kann.

Da es aber nur Phosh für Manjaro gibt, habe ich mich nach einem kurzen Check der Funktionen auf Fedora als OS verlegt. Dazu später mehr und das ist auch der Grund, wieso es keine Screenshots gibt 😉

Manjaro Community Edition

Die Manjaro Community Edition bietet ein vollständig funktionierendes Handy, auch wenn die Hardware (HW) eher substandard Ergebnisse liefert. Telefonieren kann man mit dem Gerät nur im Winter und auch nur draußen 🙂 Das liegt daran, daß das Handy eine Fehlkonstruktion ist. Möchte man telefonieren klappt das zwar, aber das Handy wird warm und jetzt ratet mal wo! Genau: direkt am Ohr … und es wird sehr warm. Stundenlang mit der Freundin quatschen ist aus zwei Gründen nicht drin: Das haltet Ihr nie aus ohne Headset und der Akku wird schnell geleert. Das Headset von jedem normalen Handy mit Klinke geht und auch per Bluetooth sollte das kein Problem sein. BT habe ich nicht ausprobiert.

Für alle die Wert auf aktuelle Kernel legen, ausgeliefert wird von Manjaro Kernel 5.6 . Das neueste Androidhandy kam auf 3.x :DDD aber Fedora stiehlt allen die Show: Kernel 5.10.rc6. Der Kernel läuft auch noch stabil, solange er bislang lief.

Phosh

Das Ziel von Phosh ist, alles möglichst groß darzustellen. Nativ hat das Display 1440×720 Pixel und bei der physischen Größe des Displays, ist das klein. Phosh hat dazu das DPI Scaling der Gnome-Shell aktiviert. Ich vermute 200-300% werden es sein. Damit werden zwar „kleine“ Appfenster gut dargestellt und auch die Icons der Apps sind super gut erreichbar, aber Apps ohne Vorbereitung fallen durch überbreite Fenster auf, wo man zum Teil keine Buttons erreichen kann um die Fenster wieder zu schließen oder die gewünschte Funktion zu aktivieren. Hier ist noch viel Arbeit von allen Seiten nötig.

Schön, weil fast wie auf Android, ist die Liste offener Anwendungsfenster, welche sich mit einem Wischen schließen lassen, was aus Gründen die offensichtlich sind (siehe oben), für einige Fenster gar nicht anders geht. Wer jetzt denkt, daß wäre idiotensicher, der muß das Handy nur mal auf Landscape Modus umstellen. Wie Ihr dann feststellen könnt, kommt Ihr an diese Liste nicht mehr ran! Die Umsetzung ist knallhart Portray-Mode-only. Der Wechsel von Portray zu Landscape und zurück ist allerdings schnell erledigt. Es fällt in den Bereich von „bedingt lästig“.

OpenSSH Server aktiviert

Bevor wir zur Sektion kommen, was alles geht und was nicht, brechen wir uns erstmal die Finger und Updaten das Phone per SSH, denn per App „Gnome-Software“ geht das nicht 😉

Dazu müßt Ihr es natürlich erstmal im WLAN haben, aber der Schritt ist harmlos ( einfach aufs WLAN Icon klicken und Frage beantworten ). Jetzt wird schwieriger.. die Wifisoftware hat nämlich einen „Bug“, das „Feature“ „zufällige MAC-Adresse erzeugen“ ist permanent aktiviert. Jedes mal, wenn das Pine startet, hat es eine andere Mac-Adresse. Weil es eine neue MAC hat, bekommt es eine neue IP „Hallo neues Gerät!“. Keine Ahnung wer das witzig fand, ich bin nicht begeistert!

Um die IP des Gerätes zu bekommen gibt es zwei Wege: entweder Ihr macht die Terminal App auf dem Handy auf und gebt „ip a“ ein oder Ihr fragt Eure Fritzbox nach der aktuellen IP des Handies, was aber schnell eher unübersichtlich werden wird.

Per SSH könnt Ihr dann direkt mit „ssh manjaro@IP“ einloggen, wenn Ihr als Passwort das „123456“ eingebt. Ein „sudo su“ später seid Ihr dann Root. Ja, ROOT... AUF DEM HANDY! So muß das sein!

ACHTUNG: Alles was Ihr jetzt gemacht habt, betrifft nur Manjaro und ist ohne Gewähr.

Jetzt sichert Ihr erstmal den SSHD gegen Wörterbuchattacken ab:

$ vi /etc/ssh/ssh_config

Den Punkt „PermitRootLogin without-password“ aktivieren und abspeichern.

$ systemctl reload sshd

Dann hinterlegt Ihr einen SSH Schlüssel unter /root/.ssh/authorized_keys.  Auf dem PC dazu „ssh-keygen -b 4096 -t rsa“ oder auch was besseres eingeben und die Ausgabe vom .pub-Teil des erzeugten Schlüssels in die authorized_keys Datei des Handies schreiben. Das sieht dann am Ende ungefähr so aus:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC4/CkjqfdfBZFbuR2eADHlUeMbVyWKpoi0y9ZiXNsO5sEbEC3GMQSGzh+inNhktsCpBBy85FjxpsEuSd3vkHOBu8SAD8MhPVsTjt12+Me9un16fHOOUPopSIYnYFEJKExPYAIy9bXkqG9QKwiT610OQ9VfHMqyM3NLLOpoYc2GLnapymmgvXNgSouZ387CxDZAG5RQx3QAPEy4Cafmr8enLUKRrDrgLYVtxb91J9lzuvySQz+pHalfhWvQanW6GzH1t7MlumBjNzpqXIfK+R4+GjJlD+3W1DvuRPluWE3YX8yi2LQzuu6pTEQtb2RYJLCDebw0D4cNAem+49z6UYun user@pc

Ich habe übrigens keine Ahnung wem dieser Pub Key gehört, ehrlich nicht 😀

Jetzt ändert Ihr noch das Passwort für den Benutzer „manjaro“ auf etwas kreativeres um. Denkt dran, das ist dann auch das Passwort zum Entsperren des Handies 😉

$ passwd manjaro

jetzt zweimal neues Passwort benutzen und das war es. Jetzt noch die Software updaten:

$ pacman -Syu

Damit wird alles aktualisiert. Alternativ „pamac update *“ benutzen.

Die Apps

Wir gehen nicht alle durch, keine Sorge.

Unter Phosh ist Gnome Maps vorinstalliert, liefert aber nur einen Überblick wo man gerade ist. Der Fensterinhalt lässt sich mit Zwei-Finger-Zoom Gesten vergrößern und verkleinern, an die Buttons zur Routenplanung und den Einstellungen kommt man aber nicht ran. GTK ist vermutlich nicht die Wahl für responsive Layouts.

Gnome Maps funktioniert ungefragt auch gleich mit dem eingebauten GPS! In den Datenschutzeinstellungen kann man das Abschalten, allerdings bleibt der Chip an und frisst Strom. Kennt man von anderen Handies auch. Aber das Pinephone hat ja anders als andere Handies eine Reihe von mysteriösen Datenschutzschalten auf der Rückseite ( unter dem Deckel ) verbaut, mit denen man alle Module wie Mic, Lautsprecher, GPS, usw. abschalten kann. Den Strom müßte man auch softwaretechnisch kappen können, finde ich. Jedes mal den Deckel aufmachen wäre irgendwie blöd.

Die Telefonieapp namens Calls ist noch in der Steinzeitphase seiner Entwicklung: sie geht aufrecht, aber schick ist anders. Auch öffnen sich die Apps nicht alle im Fullscreenmodus. Dies hängt davon ab, ob die Apps auf das Pinephone vorbereitet wurden oder nicht. Chatty finde ich cool und als ich dann endlich rausgefunden hatte, wo denn die geschickte SMS ist, kam der nächste Facepalm! Statt eine SMS App zu schreiben, tauchen die SMS als Chatkontakte auf! Deswegen ist die App auch vorinstalliert. Zum Glück kann die XMMP, besser bekannt als Jabber, und so ist die App auf dem Handy ein gewollter Begleiter. Leider kann man darüber nicht per Jabber oder SIP telefonieren. Das wäre auch wegen des Energiemanagements von Linux nicht möglich. Dafür braucht man Gajim, aber eigentlich Jitsi, wenns denn funktioniert 😉

Geary als Mailprogramm ist eine handytaugliche Wahl. Ich habe das auf meinem Tablet auch drauf. Hier stößt es aber an Grenzen, die man mit GTK und aktiviertem DPI-Scaling nicht mehr in den Griff bekommt. Megapixels heißt die einzig funktionierende Fotoapp. Diese wird aber noch von nur einem einzigen Entwickler geschrieben, der sich durch undokumentierte Funktionen eines noname Chips schlagen muß. Wenn Ihr Geld, Bier oder Pizza spenden wollt, hier ist seine Webseite: https://brixit.nl/ . Megapixels könnte sogar QR Codes auslesen, wenn der Patch schon in der Mainstreamversion enthalten wäre.

Ein Telegram Chat ist auch gleich mit drauf. Den habe ich aber nicht ausprobiert.

Was nicht geht mit Manjaro

Die Firefoxversion ist ein Kuriosum, es scheint die Android Mobile Version zu sein. Verbindet man sich nämlich mit diesem Firefox auf eine Meet Jitsi Instanz, so sagt einem die Webseite, man solle doch die App nehmen 🙂 Youtube „geht“, aber es ruckt.

Kalender sind auch so ein Ding: hier kommt Evolution zum Einsatz … oder mangels Nutzbarkeit auch nicht 😉 Evolution ist aber eigentlich ein Mailprogramm, fragt erst gar nicht.

Cheese kann man gleich löschen, das kann die Cams gar nicht ansprechen.

Mit dem Handy kam ein Dock. An dem Dock war ein HDMI Anschluss. Wohl dem, bei dem dieser Dock so funktioniert wie er sollte. Meiner scheint defekt zu sein. Ich bekomme zwar beim Booten kurzzeitig ein HDMI Bild vom Bootscreen, aber das war es dann auch schon. Als Netzwerkadapter kommt es auch nur auf 100 Mb/s, was aber deutlich mehr ist, als das Wifi. Das Wifi ist 2.4 Ghz only, schafft aber, und das ist mir unklar, 4,4 MB/s. Das kann eigentlich gar nicht sein, weil 2.4 GHz Wlan nur 1,8 MB schaffen sollte. Die Fritz!box und das Handy müssen mehr als nur einen Kanal benutzen.

Man kann Videos mit MPV abspielen, aber dafür wird die unterdimensionierte CPU benutzt. D.b. der Film ruckelt und ist nicht synchron zum Ton. Dabei hat das Handy eine Mali400 GPU, die das locker schafft. Woher weiß ich das? Das sehr Ihr in drei Tagen in „Fedora erobert das Pinephone“ 😉

Fazit Tag 1

Mit den leichten Abstrichen ist das jetzt schon ein Handy, das man benutzen könnte, aber für „Normalos ohne fundierte Linux Kenntnisse“ ist das natürlich noch nichts.

Was Ihr jetzt aber schon einmal machen könnt, ist Euch eine schnelle Mircro-SD Karte ab 16 GB, besser 32+ GB, zu besorgen und einen Cardreader zu organisieren, der die Karte auch sauber ansprechen kann. Achja, Handy bestellen nicht vergessen 😉

Wir lesen uns Montag wieder, wenn wir das Telefon Stück für Stück in einen brauchbaren Zustand überführen, am Ende rockt es richtig, versprochen 😀

 

Fedora erobert das Pinephone

 

 

Fedora: Kernelupdates für BleedingTooth verfügbar

Moin, wie ich gerade gesehen habe, sind die Patche für die 5.8er Kernels bereits in Fedora eingepflegt und die Kernel bereitgestellt worden.

Fedora: Kernelupdates für BleedingTooth verfügbar

This update contains patches for the BleedingTooth CVEs.
The 5.8.15 stable kernel update contains a number of important fixes across the tree.
The 5.8.14 stable kernel update contains a number of important fixes across the tree.

IN YOUR FACE, ANDROID. <24h, so geht das mit Kernelupdates bei Sicherheitslücken!

Danke Justin.

FunFact: Einige Mirrors habe die Updates noch nicht im Programm. Das resultiert in einer langen Fehlermeldungskette beim DNF, wird aber am Ende niemanden stören 🙂

[MIRROR] kernel-5.8.15-101.fc31.x86_64.rpm: Status code: 404 for https://mirror.dogado.de/fedora/linux/updates/31/Everything/x86_64/Packages/k/kernel-5.8.15-101.fc31.x86_64.rpm (IP: 185.3.234.216)
[MIRROR] kernel-core-5.8.15-101.fc31.x86_64.rpm: Status code: 404 for https://mirror.dogado.de/fedora/linux/updates/31/Everything/x86_64/Packages/k/kernel-core-5.8.15-101.fc31.x86_64.rpm (IP: 185.3.234.216)
[MIRROR] kernel-5.8.15-101.fc31.x86_64.rpm: Status code: 404 for http://mirror.dogado.de/fedora/linux/updates/31/Everything/x86_64/Packages/k/kernel-5.8.15-101.fc31.x86_64.rpm (IP: 185.3.234.216)

[MIRROR] kernel-modules-5.8.15-101.fc31.x86_64.rpm: Status code: 404 for http://ftp.icm.edu.pl/pub/Linux/fedora/linux/updates/31/Everything/x86_64/Packages/k/kernel-modules-5.8.15-101.fc31.x86_64.rpm (IP: 2001:6a0:0:31::2)
[MIRROR] kernel-core-5.8.15-101.fc31.x86_64.rpm: Status code: 404 for https://ftp.icm.edu.pl/pub/Linux/fedora/linux/updates/31/Everything/x86_64/Packages/k/kernel-core-5.8.15-101.fc31.x86_64.rpm (IP: 2001:6a0:0:31::2)
[MIRROR] kernel-modules-5.8.15-101.fc31.x86_64.rpm: Status code: 404 for https://ftp.icm.edu.pl/pub/Linux/fedora/linux/updates/31/Everything/x86_64/Packages/k/kernel-modules-5.8.15-101.fc31.x86_64.rpm (IP: 2001:6a0:0:31::2)

Ein anderer Mirror hatte das Paket dann doch schon, er ist nur nicht der schnellste.

Linux: Multitouchsupport im Surface Pro 4

Heute geht es mal wieder um Linux auf dem Surface Pro 4 Tablet. Da hatten wir lange keinen Beitrag mehr dazu 🙂

Linux: Multitouchsupport im Surface Pro 4

Mit Kernel 5.8 kam „leider“ eine Änderung ins System: Touch ging nicht mehr. Auf einem Tablet ist das natürlich der Super-GAU und natürlich kamen sofort Erinnerungen auf zur Erstinbetriebnahme vor 18 Monaten.

Der letzte Kernel der noch ohne weiteres funktionierte war 5.7.17-2, ergo war erstmal ein Bugreport an die Entwickler nötig. Zum Glück konnten die das Problem erfolgreich beheben, wobei man sagen muß, ein bisschen mehr PR täte denen ganz gut 😉

Ihr braucht eine neue Zusatzsoftware für den Kernel 5.8: iptsd

Die Installation ist ganz einfach, sofern Ihr, und ich bin sicher, daß Ihr das habt, das Kernel Repo eingerichtet habt: surfacelinux.com .

dnf install iptsd -y

systemctl start iptsd
systemctl enable iptsd
reboot

Eigentlich ist der iptsd ein User-Space-Daemon, er braucht keinen Neustart, aber das hatte bei mir leider nicht funktioniert. Erst nach dem das System 2h geladen und dann neu gestartet wurde, funktionierte der Daemon wie er sollte.

Jetzt war wieder alles möglich, was der JakeDay-Kernel, keine Ahnung wieso der abgetaucht ist, auch konnte: nämlich Multi-Touch-Gesten ( und die Maschine wirklich abschalten, aber das ist ne andere Geschichte )

Multi-Touch-Gesten meint z.b., daß man unter der Gnome-Shell in die Aktivitätenübersicht mit Hilfe von 3-Fingern die sich aufeinander zubewegen wechseln kann. Auch funktioniert das Zoomen im Firefox und anderen dafür vorbereitete Apps wieder, was die Bedienung deutlich einfacher macht im Tabletmodus \o/

Jetzt braucht es nur zwei Fixe an der Kamera und dem Mouseeventmanagment und das Tablet ist, bis auf den hohen Stromverbrauch durch den Kernel selbst, endlich vollständig benutzbar.

„Jungs, gut gemacht!“ 🙂

Kernel 5.7.8+ Problem entdeckt

Es ist mal wieder soweit, ein fieses Kernelproblem wurde entdeckt. Ja ok, passiert dauernd, aber meisten sind nicht alle davon betroffen, hier schon, da es ein Speicherzugriffsfehler ist.

Kernel 5.7.8+ Problem entdeckt

In den letzten zwei Tagen sind zwei verschiedene Computer mit dem gleichen Fehlerbild stehen geblieben:

Aug 2 18:01:17 shortname kernel: BUG: unable to handle page fault for address: ffff8881e2e48630
Aug 2 18:01:17 shortname kernel: #PF: supervisor write access in kernel mode
Aug 2 18:01:18 shortname kernel: #PF: error_code(0x0003) – permissions violation

Der PC bleibt dabei nicht gleich stehen, sondern der Zugriff auf Strukturen im /proc Filesystem ( procfs ) friert einfach ein. Als Resultat bleiben Programme wie „top“ oder „pidof“ stecken. Das ist besonders blöd, weil „pidof“ beim Startprozess eines Terminals für die Bash mitmischt und man so keins mehr starten kann.

Ich hatte erst gedacht, daß wäre ein VM Problem, weil es zunächst im Servercluster aufgetreten ist, aber da es jetzt auch bare-metal auf einem Desktop-PC passiert ist, was es Zeit Alarm zu schlagen.

Wer Kernel 5.7.8 einsetzt kann sich derzeit nicht sicher sein, daß der PC durchläuft. Bei mit lag der Ausfallzeitpunkt bei knappen 15 Stunden Betriebszeit für bare-metal und ~2 Wochen für eine VM in der heute das gleiche passiert ist. Da das Problem frisch entdeckt wurde, gibt es noch keine Reaktion vom Kernel Team. Ich kann aber nur dazu raten einen anderen Kernel lauf zu lassen.

Wenn Ihr das Problem rechtzeitig bemerkt, könnt Ihr noch über die Desktop-Systemüberwachung in die Prozessliste und die „pidof“ Prozesse abbrechen, die das Starten eines Terminals verhindern. Danach kommt die Bash i.d.r. sauber hoch und Ihr könnt Reboot eingeben. Ein „systemctl reboot -i“ wird nötig sein, da der normale Reboot, zumindest bei mir, verweigert wurde.

Hier für Euch die ganze Kernelmeldung für Vergleichszwecke:

Aug 2 18:01:17 shortname kernel: BUG: unable to handle page fault for address: ffff8881e2e48630
Aug 2 18:01:17 shortname kernel: #PF: supervisor write access in kernel mode
Aug 2 18:01:18 shortname kernel: #PF: error_code(0x0003) – permissions violation
Aug 2 18:01:18 shortname kernel: PGD 2a0c067 P4D 2a0c067 PUD 3800067 PMD 1ffff2067 PTE 100001e2e48065
Aug 2 18:01:19 shortname kernel: Oops: 0003 [#3] SMP NOPTI
Aug 2 18:01:19 shortname kernel: CPU: 0 PID: 96 Comm: kswapd0 Tainted: G D W 5.7.8-100.fc31.x86_64 #1
Aug 2 18:01:19 shortname kernel: RIP: e030:ptep_clear_flush_young+0x1d/0x30
Aug 2 18:01:19 shortname kernel: Code: 48 0f ba 32 05 0f 92 c0 0f b6 c0 c3 90 0f 1f 44 00 00 48 8b 05 ec 74 40 01 48 25 00 f0 ff ff 48 f7 d0 48 23 02 83 e0 20 74 0c <f0> 48 0f ba 32 05 0f 92 c0 0f b6 c0 c3 66 0f 1f 44 00 00 0f 1f 44
Aug 2 18:01:19 shortname kernel: RSP: e02b:ffffc90001127a48 EFLAGS: 00010202
Aug 2 18:01:19 shortname kernel: RAX: 0000000000000020 RBX: ffff888101c64ed8 RCX: 0000000000000000
Aug 2 18:01:19 shortname kernel: RDX: ffff8881e2e48630 RSI: 00007fe123ac6000 RDI: ffff888101c64ed8
Aug 2 18:01:19 shortname kernel: RBP: ffffea00049c2e80 R08: 0000000000000101 R09: 0000000000000125
Aug 2 18:01:19 shortname kernel: R10: ffff8881f483e8d0 R11: ffffea0005ddc2a0 R12: ffffc90001127b08
Aug 2 18:01:19 shortname kernel: R13: 0000000000000000 R14: 00007fe123ac6000 R15: 0000000000000186
Aug 2 18:01:19 shortname kernel: FS: 00007f37db3a7700(0000) GS:ffff8881f5c00000(0000) knlGS:0000000000000000
Aug 2 18:01:19 shortname kernel: CS: e030 DS: 0000 ES: 0000 CR0: 0000000080050033
Aug 2 18:01:19 shortname kernel: CR2: ffff8881e2e48630 CR3: 0000000002a0a000 CR4: 0000000000040660
Aug 2 18:01:19 shortname kernel: Call Trace:
Aug 2 18:01:19 shortname kernel: page_referenced_one+0x59/0x150
Aug 2 18:01:19 shortname kernel: rmap_walk_file+0x157/0x2f0
Aug 2 18:01:19 shortname kernel: page_referenced+0xdb/0x150
Aug 2 18:01:19 shortname kernel: ? rmap_walk_file+0x2f0/0x2f0
Aug 2 18:01:19 shortname kernel: ? page_get_anon_vma+0x80/0x80
Aug 2 18:01:19 shortname kernel: shrink_active_list+0x2e5/0x560
Aug 2 18:01:19 shortname kernel: shrink_lruvec+0x3b9/0x6b0
Aug 2 18:01:19 shortname kernel: ? do_shrink_slab+0x52/0x2c0
Aug 2 18:01:19 shortname kernel: shrink_node+0x169/0x680
Aug 2 18:01:19 shortname kernel: balance_pgdat+0x2d9/0x5c0
Aug 2 18:01:19 shortname kernel: kswapd+0x1ed/0x3a0
Aug 2 18:01:19 shortname kernel: ? __schedule+0x2c2/0x730
Aug 2 18:01:19 shortname kernel: ? finish_wait+0x80/0x80
Aug 2 18:01:19 shortname kernel: kthread+0xf9/0x130
Aug 2 18:01:19 shortname kernel: ? balance_pgdat+0x5c0/0x5c0
Aug 2 18:01:19 shortname kernel: ? kthread_park+0x90/0x90
Aug 2 18:01:19 shortname kernel: ret_from_fork+0x35/0x40
Aug 2 18:01:19 shortname kernel: Modules linked in: fuse btrfs blake2b_generic xor raid6_pq hfsplus hfs minix vfat msdos fat jfs xfs nfsv3 nfs_acl nfs lockd grace fscache xt_owner ipt_REJECT nf_reject_ipv4 xt_connlimit nf_conncount nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c xt_multiport ip6table_filter ip6_tables cls_u32 sch_htb iptable_filter intel_rapl_msr intel_rapl_common cfg80211 sb_edac x86_pkg_temp_thermal coretemp crct10dif_pclmul rfkill crc32_pclmul ghash_clmulni_intel intel_rapl_perf sunrpc ip_tables xen_netfront xen_blkfront crc32c_intel
Aug 2 18:01:19 shortname kernel: CR2: ffff8881e2e48630
Aug 2 18:01:19 shortname kernel: —[ end trace 7fb962ee698fa150 ]—
Aug 2 18:01:19 shortname kernel: RIP: e030:unmap_page_range+0x631/0xec0
Aug 2 18:01:19 shortname kernel: Code: fe e8 03 f8 ff ff 48 83 7c 24 18 00 48 89 c3 74 09 48 85 c0 0f 85 c0 05 00 00 41 f6 44 24 20 01 0f 84 25 03 00 00 4c 8b 6d 00 <48> c7 45 00 00 00 00 00 4d 39 7c 24 10 4c 89 f8 49 0f 46 44 24 10
Aug 2 18:01:19 shortname kernel: RSP: e02b:ffffc90002a2bb38 EFLAGS: 00010202
Aug 2 18:01:19 shortname kernel: RAX: ffffea0001b72500 RBX: ffffea0001b72500 RCX: 0000000000000125
Aug 2 18:01:19 shortname kernel: RDX: 0000000000000000 RSI: 00005589f49e7000 RDI: 000000083aa94125
Aug 2 18:01:19 shortname kernel: RBP: ffff8881e3d90f38 R08: ffff88810011e320 R09: 0000000000000000
Aug 2 18:01:19 shortname kernel: R10: 0000000000007ff0 R11: 0000000000000000 R12: ffffc90002a2bc80
Aug 2 18:01:19 shortname kernel: R13: 000000083aa94125 R14: 00005589f49e8000 R15: 00005589f49e7000
Aug 2 18:01:19 shortname kernel: FS: 00007f37db3a7700(0000) GS:ffff8881f5c00000(0000) knlGS:0000000000000000
Aug 2 18:01:19 shortname kernel: CS: e030 DS: 0000 ES: 0000 CR0: 0000000080050033
Aug 2 18:01:19 shortname kernel: CR2: ffff8881e2e48630 CR3: 0000000002a0a000 CR4: 0000000000040660

 

Fedora: Installationsprozess korrumpiert den Speicher

Guten Morgen,

ich hätte nicht gedacht, daß so etwas heutzutage noch möglich ist angesichts der ganzen Speicherschutzmechanismen, aber soeben hat ein Update den Speicher meines PCs durchgerüttelt:

Neu Hinzugekommen:

2020-07-06T08:01:56Z SUBDEBUG Installed: kernel-core-5.7.7-100.fc31.x86_64
2020-07-06T08:01:59Z SUBDEBUG Installed: kernel-modules-5.7.7-100.fc31.x86_64
2020-07-06T08:02:11Z SUBDEBUG Installed: kernel-5.7.7-100.fc31.x86_64
2020-07-06T08:02:11Z SUBDEBUG Installed: kernel-modules-extra-5.7.7-100.fc31.x86_64
2020-07-06T08:02:18Z SUBDEBUG Installed: kernel-devel-5.7.7-100.fc31.x86_64
2020-07-06T08:04:18Z SUBDEBUG Installed: kmod-nvidia-5.7.7-100.fc31.x86_64-3:440.100-1.fc31.x86_64
2020-07-06T08:04:42Z SUBDEBUG Installed: kmod-VirtualBox-5.7.7-100.fc31.x86_64-6.1.10-1.fc31.x86_64

Pakete aktualisiert:

2020-07-06T08:01:52Z SUBDEBUG Upgrade: linux-firmware-whence-20200619-109.fc31.noarch
2020-07-06T08:01:52Z SUBDEBUG Upgrade: linux-firmware-20200619-109.fc31.noarch
2020-07-06T08:02:06Z SUBDEBUG Upgrade: blender-fonts-1:2.83.1-1.fc31.noarch
2020-07-06T08:02:07Z SUBDEBUG Upgrade: blender-1:2.83.1-1.fc31.x86_64
2020-07-06T08:02:16Z SUBDEBUG Upgrade: iwl100-firmware-39.31.5.1-109.fc31.noarch
2020-07-06T08:02:16Z SUBDEBUG Upgrade: iwl1000-firmware-1:39.31.5.1-109.fc31.noarch
2020-07-06T08:02:16Z SUBDEBUG Upgrade: iwl105-firmware-18.168.6.1-109.fc31.noarch
2020-07-06T08:02:16Z SUBDEBUG Upgrade: iwl135-firmware-18.168.6.1-109.fc31.noarch
2020-07-06T08:02:16Z SUBDEBUG Upgrade: iwl2000-firmware-18.168.6.1-109.fc31.noarch
2020-07-06T08:02:16Z SUBDEBUG Upgrade: iwl2030-firmware-18.168.6.1-109.fc31.noarch
2020-07-06T08:02:16Z SUBDEBUG Upgrade: iwl3160-firmware-1:25.30.13.0-109.fc31.noarch
2020-07-06T08:02:16Z SUBDEBUG Upgrade: iwl3945-firmware-15.32.2.9-109.fc31.noarch
2020-07-06T08:02:16Z SUBDEBUG Upgrade: iwl4965-firmware-228.61.2.24-109.fc31.noarch
2020-07-06T08:02:16Z SUBDEBUG Upgrade: iwl5000-firmware-8.83.5.1_1-109.fc31.noarch
2020-07-06T08:02:16Z SUBDEBUG Upgrade: iwl5150-firmware-8.24.2.2-109.fc31.noarch
2020-07-06T08:02:16Z SUBDEBUG Upgrade: iwl6000-firmware-9.221.4.1-109.fc31.noarch
2020-07-06T08:02:16Z SUBDEBUG Upgrade: iwl6000g2a-firmware-18.168.6.1-109.fc31.noarch
2020-07-06T08:02:16Z SUBDEBUG Upgrade: iwl6000g2b-firmware-18.168.6.1-109.fc31.noarch
2020-07-06T08:02:16Z SUBDEBUG Upgrade: iwl6050-firmware-41.28.5.1-109.fc31.noarch
2020-07-06T08:02:16Z SUBDEBUG Upgrade: iwl7260-firmware-1:25.30.13.0-109.fc31.noarch
2020-07-06T08:02:18Z SUBDEBUG Upgrade: libertas-usb8388-firmware-2:20200619-109.fc31.noarch
2020-07-06T08:02:18Z SUBDEBUG Upgrade: kernel-headers-5.7.7-100.fc31.x86_64

Bei einem dieser Prozesse hat es dann die Schrift in Cinnamon irgendwie zerrissen. Möglich wäre, daß das Update von Blender-Fonts dafür verantwortlich ist. Allerdings kommt der Font laut Schriftenvoreinsteller gar nicht zum Einsatz. Es könnte also alles gewesen sein.

Also passt ein bisschen auf, wenn Ihr heute Updates einspielt, ein direkter Reboot danach wäre sinnvoll!

Nvidia, Fedora, RPMFusion und der Bug, der nicht sein soll.

Diese Geschichte fängt an mit: „Es war einmal eine Grafikkarte“.

„Nvidia, Fedora, RPMFusion und der Bug, der nicht sein soll“

Wie Ihr wisst, gibt es von Nvidiatreibern verschiedene Versionsnummern, z.b. 340,390,440. 440 ist der aktuelle Treiber für GTX1050 Karten.

Jetzt wirft dieser Treiber beim Systemboot eine Fehlermeldung wie folgt:

[ 222.363327] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 222.363328] [drm] No driver support for vblank timestamp query.
[ 222.397236] [drm] Initialized nvidia-drm 0.0.0 20160202 for 0000:05:00.0 on minor 0
[ 222.406533] ————[ cut here ]————
[ 222.406534] refcount_t: underflow; use-after-free.
[ 222.406550] WARNING: CPU: 1 PID: 513 at lib/refcount.c:28 refcount_warn_saturate+0xa6/0xf0
[ 222.406551] Modules linked in: nvidia_drm(POE) nvidia_modeset(POE) nvidia_uvm(OE) snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_intel nvidia(POE) snd_intel_dspcfg snd_hda_codec snd_hda_core snd_hwdep joydev snd_seq snd_seq_device edac_mce_amd drm_kms_helper snd_pcm kvm_amd snd_timer drm snd kvm ipmi_devintf sp5100_tco irqbypass wmi_bmof ipmi_msghandler k10temp i2c_piix4 soundcore pcspkr gpio_amdpt gpio_generic acpi_cpufreq nfsd binfmt_misc auth_rpcgss nfs_acl lockd grace sunrpc ip_tables dm_crypt hid_logitech_hidpp crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel ccp r8169 aacraid hid_logitech_dj wmi pinctrl_amd fuse
[ 222.406576] CPU: 1 PID: 513 Comm: plymouthd Tainted: P OE 5.5.10-200.fc31.x86_64 #1
[ 222.406577] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./B450M Pro4, BIOS P3.90 12/09/2019
[ 222.406579] RIP: 0010:refcount_warn_saturate+0xa6/0xf0
[ 222.406581] Code: 05 2e 03 2e 01 01 e8 7b 8e bc ff 0f 0b c3 80 3d 1c 03 2e 01 00 75 95 48 c7 c7 18 99 3c 9d c6 05 0c 03 2e 01 01 e8 5c 8e bc ff <0f> 0b c3 80 3d fb 02 2e 01 00 0f 85 72 ff ff ff 48 c7 c7 70 99 3c
[ 222.406582] RSP: 0018:ffffb573c103fcb8 EFLAGS: 00010286
[ 222.406583] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000007
[ 222.406584] RDX: 0000000000000007 RSI: 0000000000000086 RDI: ffff9416ce859cc0
[ 222.406585] RBP: ffff9416bacbfce8 R08: 0000000000000413 R09: 0000000000000003
[ 222.406585] R10: 0000000000000000 R11: 0000000000000001 R12: ffff9416c70502e8
[ 222.406586] R13: ffff9416c7050000 R14: 0000000000000008 R15: 0000000000000000
[ 222.406588] FS: 00007f07558f3f00(0000) GS:ffff9416ce840000(0000) knlGS:0000000000000000
[ 222.406588] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 222.406589] CR2: 00007f0755072052 CR3: 00000004035c6000 CR4: 0000000000340ee0
[ 222.406590] Call Trace:
[ 222.406597] nv_drm_atomic_helper_disable_all+0xec/0x290 [nvidia_drm]
[ 222.406603] nv_drm_master_drop+0x22/0x60 [nvidia_drm]
[ 222.406616] drm_drop_master+0x1e/0x30 [drm]
[ 222.406628] drm_dropmaster_ioctl+0x4c/0x90 [drm]
[ 222.406639] ? drm_setmaster_ioctl+0xb0/0xb0 [drm]
[ 222.406651] drm_ioctl_kernel+0xaa/0xf0 [drm]
[ 222.406663] drm_ioctl+0x208/0x390 [drm]
[ 222.406675] ? drm_setmaster_ioctl+0xb0/0xb0 [drm]
[ 222.406678] ? do_filp_open+0xa5/0x100
[ 222.406681] ? selinux_file_ioctl+0x174/0x220
[ 222.406683] do_vfs_ioctl+0x461/0x6d0
[ 222.406685] ksys_ioctl+0x5e/0x90
[ 222.406686] __x64_sys_ioctl+0x16/0x20
[ 222.406690] do_syscall_64+0x5b/0x1c0
[ 222.406693] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 222.406695] RIP: 0033:0x7f0755bb138b
[ 222.406697] Code: 0f 1e fa 48 8b 05 fd 9a 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d cd 9a 0c 00 f7 d8 64 89 01 48
[ 222.406697] RSP: 002b:00007ffced5fe798 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 222.406699] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0755bb138b
[ 222.406699] RDX: 0000000000000000 RSI: 000000000000641f RDI: 0000000000000009
[ 222.406700] RBP: 000000000000641f R08: 000055b6a6ff1df0 R09: 000055b6a6fa5010
[ 222.406701] R10: 0000000000000000 R11: 0000000000000246 R12: 000055b6a6ff2970
[ 222.406701] R13: 0000000000000009 R14: 0000000000000000 R15: 0000000000000000
[ 222.406703] —[ end trace fa45bb73ed0780f4 ]—
[ 222.411358] kauditd_printk_skb: 45 callbacks suppressed

Von Euch sieht natürlich jeder sofort, daß hier NVIDIA und PLYMOUTH im Spiel sind und das der Nvidiatreiber einen Fehler bei der DRM Initialisierung verursacht. Der Server bootet danach weiter, also erstmal nicht so wichtig. Es folgen die üblichen Dinge: Bugreport bei Fedora ( wegen Plymouth ) und bei RPMFusion ( wegen Nvidia ) erstellen, und komplett entäuscht werden… !

„Da ist kein Bug, gehen Sie weiter!“

Nun kann Fedora da nicht viel machen, wenn der Nvidiatreiber da Mist baut, außer natürlich, es übergibt dem Treiber schon was falsches, da könnte der Treiber dann nicht mehr soviel für den Bug. Das werden wir aber nie erfahren, denn der Bug wurde sofort beerdigt. Nagut, wir haben ja noch den RPMFusionreport.

Sagte ich, wir haben noch einen anderen offenen Bugreport? So kann man sich irren: „Your Bugreport has been closed with „WONT FIX“.Und dann stehen wir mit einem Fehler da, von dem alle Parteien sagen „Nicht mein Problem“. Doch, Eurer Problem! Wessen denn sonst?

Der Bug wurde in der Devliste von Nvidia zwar besprochen, aber es gibt leider keinen finalen Fix dafür:

Devliste: https://forums.developer.nvidia.com/t/bug-nvidia-440-64-kernel-5-5-6-stable-boot-trace-was-nvidia-440-59-kernel-5-5-1-stable-boot-trace/111643

Der derzeitige Stand ist: Geht halt nicht; und DRM geht dann halt auch nicht. Wobei letzteres sollte man eh abschaffen, falls damit das DigitalRightsManagement gemeint ist.

Was mich aber am meisten stört: „ist nicht unser Problem“. Von RPMFusion hätte ich erwartet, daß das offen bleibt, bis das von den Nvidiadevs gefixt wurde, schon um das Problem zu tracken, aber von Scott kann man halt oft nichts anderes erwarten.

Wenn sich Grub und Grubby uneins sind

Ihr erinnert Euch noch an den Artikel Fedora 30&31 Bootumstellung führt zu Startproblem? Davon habe ich eine neue Version für Euch 🙂

Wenn sich Grub und Grubby uneins sind

Allen Anfängern rate ich jetzt mal zunächst ein bisschen zu Lesen: Grubby: wie man wieder einen Default Kernel setzen kann damit dürfte klar sein, was Grubby macht. Grub ist der verbreiteste Bootloader für Linux und der liest normalerweise das ein, was Grubby so von sich geschrieben hat. Wenn ich das schon so flapsig schreibe, dann kann das ja eigentlich schon nicht stimmen, tut es auch nicht immer 🙂

Fangen wir mit der Geschichte von vorn an …ää ähm .. ä ..hm… es war mal im Jahr 2019 ein Fedora Releasewechsel von Fedora 29 auf 30, und ein Linux Tablet. Ok,ok, mein Tablet war zwar an der Geschichte beteiligt, aber das hätte jedem PC passieren können, ehrlich 😉 Mit Fedora 30 wurde ja BLS eingeführt und dabei muß jemand an Grub geschraubt und was falsch gemacht haben, denn bis zu dem Upgrade lief das mit dem Setzen des Default Kernels über Grubby noch.

„Ihr wagt es mir zu trotzen, wer seid Ihr Ritter Rosthülle!“

Seit dem Update konnte ich machen was ich wollte, es wurde immer der erste Kernel in Menü als Bootkernel ausgewählt, egal was ich mit Grubby angestellt habe. Zu beachten ist hier, daß immer alle aktuell installierten Kernels im Menü aufgetaucht sind. Nun habe ich ja für den Beitrag zum neuen Surfacekernel Repo einen, wer würde es erraten, neuen Kernel installiert \o/ und prompt bootete der nicht automatisch. Da ich aber sicher gehen wollte, daß der immer startet, habe ich da nochmal alles überprüft.

Die Dateien in /boot/grub2/ waren alle OK. Wenn Grubby gehustet hat, änderten sich die grubenv und die grub.cfg untertänigst und trotzdem blieb es beim ersten Kernel im Menü. Unglaublich. Jetzt kann man glücklicherweise im Grubmenü auf „c“ drücken und kommt in die GrubShell. Wenn man da „set“ aufruft, zeigt er einem die Grubvariablen an, das sind die, die man mit dem Eintrag in der grubenv überschreiben kann. Wenn man sich die grub.cfg ansieht:

if [ -f ${config_directory}/grubenv ]; then
    load_env -f ${config_directory}/grubenv
elif [ -s $prefix/grubenv ]; then
    load_env
fi

erkennt man auch als Uneingeweihter, daß hier die grubenv geladen werden soll. d.b. Schritt Eins vom Bootloader, bevor das Menü überhaupt zusammenbaut wird, ist also die grubenv laden und die passenden Variablen setzen oder überschreiben.

Die GrubShell

Wie bereits erwähnt kann man sich das Ergebnis in der GrubShell ansehen, wenn man „set“ eingibt. Solltet Ihr beim nächsten Boot einfach mal machen und reinsehen. „boot“ oder „reboot“ bringen Euch da wieder raus. Als ich heute (für Euch vor 2 Wochen) in die Variablenliste von „set“ sah, wäre ich fast vom Stuhl gefallen. Da stand allen ernstes ein Kernel 5.2.7 (Fedora 29) als Defaultkernel drin! Den gab es unter /boot/ aber gar nicht mehr und das System hat nur eine Bootplatte. Ich habe ja erwähnt, daß alle Kernel, die hätten im Menü sein sollen, auch im Menü drin waren. Ein Kernel 5.2.7 wäre da aufgefallen.

Jetzt sucht mal auf der Platte nach einem Kernel, den es seit 5 Monaten nicht mehr gibt, viel Spaß dabei! Das muß ja irgendwo drin stehen, also /etc/ durchsucht, /boot/grub2 durchsucht, /usr/ durchsucht, nichts! Kein Kernel, kein Eintrag.. wo zum Geier kommt das her? Grubby schreibt doch jede Änderung des Kernels direkt in die Files, da KANN DOCH GAR KEIN ALTER KERNEL DRINSTEHEN!

Wenn A und B nicht das Gleiche sind!

Stands auch nicht. Die Lösung für das Problem war dann weniger spannend als die Suche danach 🙂 Grubby änderte die Dateien in /boot/grub2, aber Grub lud nicht /boot/grub2 sondern /boot/EFI/efi/fedora/ und da standen uralte Fedora 29 Sachen in den Dateien. Das ist so eine „Links weiß nicht was Rechts tun“ Geschichte. Die Lösung für das Problem ist dann ganz einfach, man nimmt einfach zwei Symbolische Links und verknüpft die beiden Orte, so daß es nur noch eine Datei mit dem Inhalt gibt, und nicht mehr zwei verschiedene.

Da Grubby alle aktuellen Anpassungen nach /boot/grub2/ schreibt, aber Grub aus /boot/EFI/efi/fedora/ liest und zu allem Überfluß /boot/ zu „/“ wird, wenn man der Bootloader ist, muß man ein klein bisschen kreativ werden, um den korrekt Pfad für den Link abzuleiten. Folgende Anweisungen können das für Euch direkt lösen:

mv /boot/grub2/grubenv /boot/EFI/efi/fedora/grubenv
mv /boot/grub2/grub.cfg /boot/EFI/efi/fedora/grub.cfg
cd /boot/grub2
ln -s ../EFI/efi/fedora/grubenv
ln -s ../EFI/efi/fedora/grub.cfg

Kurz erklärt

„mv“ steht für „move“ und verschiebt Dateien von A nach B. Wenn B vorhanden, wird es überschrieben, man muß B also nicht vorher löschen.
„ln -s {Pfad/Dateiname}“  legt den symbolischen (-s) Link von {Pfad/Dateiname} als „Dateiname“ im Filesystem an. Sollen Ziel und Quelle des Links gleich heißen muß man da nichts weiter angeben. Üblich wäre aber z.B. „ln -s pfad1/datei1 pfad2/datei2“ . In den Anweisungen oben haben wir einen relativen Pfad ../EFI/efi/fedora benutzt, weil /boot/EFI/efi/fedora nicht geht, da es /boot/ in der Bootparition nicht gibt, denn die wird während des Bootens erst später unter /boot/ eingehängt. Der Bootloader hantiert also direkt im /boot/ rum, weswegen in seinem Kontext „/boot/“ = „/“ ist. Das Root = / ist hätte man riskieren können, aber da Grub nicht von /boot/grub2 lädt, könnte da ja noch viel mehr anders sein, als mir jetzt bekannt ist. Daher war der relative Link hier sicherer als „ln -s /EFI/efi/fedora/grubenv“ zu benutzen.

Für Anfänger: Ein symbolischer Link ist eigentlich nur eine kleine Textdatei, wo das Ziel ( hier ../EFI/efi/fedora/grubenv ) drinsteht. Das Filesystem merkt das, und folgt dann dem Pfad zum eigentlichen Ziel. Symbolische Links kann man quer über alle eingehängten Partitionen benutzen. „Hardlinks“, die sich hier auch angeboten hätten, kann man nur innerhalb einer Partition benutzen, dafür haben die andere Vorteile.

Bugreport ist raus, mal sehen wann die Beule am Kopf der GrubDevs vom gegen die Wand schlagen wieder abgeschwollen ist 🙂

Linux: Surface Tablets und Laptops mit eigenem Kernel-Repo

„Du saga mal, Du hascht doch des Suuhrfaze, gibtsch da scho wos njeues pführ?“ hallte es aus dem mitfünfziger Herrn am Tisch gegenüber. Freundlich, aber bestimmt, machte Ihm mein Sitznachbar darauf aufmerksam, daß er kurz hinter Kiel wäre und folglich kaum zu verstehen sei. Dies schien den Herrn genauso wenig zu stören, wie der Umstand, daß mein Sitznachbar eher andigital veranlagt ist und es sich bei dem Gerät vielmehr um eine kurz Präsentationsleihgabe meinerseits handelte.

Nachdem die beiden Fischköpfe ( wir… vermutlich ) kurz getuschelt hatten, übersetzte eine junge Dame (Bezeichnung Anna-Luisa o7) für uns (daher auch die grobe Entschlüsselung oben) und es entstand eine schöne , wenn auch sehr kurze, Unterhaltung zum Thema: Linux auf einem Surface Pro 4.

Surface Tablets und Laptops mit eigenem Kernel-Repo

„Ja, da gibts was njeues.. ehm.. neues“ und für Euch schalte ich das Gespräch mal auf Allwissenden Erzähler um, sonst darf ich mich in Bayern gar nimmer sehen lassen. Also, Ja Leute, es gibt eine nicht mehr ganz taufrische Entwicklung, die teils sehr erfreulich, weil unheimlich praktisch ist, andererseits leider nicht so ganz funktioniert. Letzterer Teil wird derzeit noch untersucht.

Seit einige Monaten gibt es im Github einen eigenen Prebuild-Kernel für Arch, Debian und Fedora. Den richtet Ihr Euch so für Fedora ein:

  1. Das Repo hinzufügen:

sudo dnf config-manager --add-repo=https://pkg.surfacelinux.com/fedora/linux-surface.repo

2. Den Kernel  installieren:

sudo dnf install kernel-surface surface-firmware surface-secureboot
sudo dnf install --allowerasing libwacom-surface

3. Letztere Anweisung ist eher optional, falls man mit Wacom Probleme hat., was auch die Stifteingabe betrifft.

Surface rebooten, den neuen Kernel auswählen und jetzt kommt es drauf an, ob Ihr ein SP4/SB1 habt oder ein anderes Surfacegerät Euer eigen nennt, denn bei mir (SP4) bootet der Kernel zwar sauber, aber IPTS ist nicht da, was man allerdings für Touchbedienung braucht.  So bin ich kaum einen Schritt weiter als mit dem Kernel von Fedora selbst. Ein Problem an dem derzeit gearbeitet wird.

Und da ist auch schon die Lösung … ( sowas von genial den Artikel schon Tage im Voraus zu schreiben 😀 ) … dem mangelnden Touchsupport kann man so begegnen:

[root@surface]# rmmod ipts
[root@surface]# insmod /lib/modules/5.5.8-1.surface.fc30.x86_64/kernel/drivers/input/touchscreen/ipts/ipts.ko.xz singletouch=y

Was man dann so verewigt:

echo „options ipts singletouch=y“ > /etc/modprobe.d/ipts.conf

Man muß aber wissen, das dann der Stiftsupport abgeschaltet ist. Außerdem ist im 5.5er Kernel die Multitouch-Support komischerweise abgeschaltet, wer das braucht, muß den LTS Kernel 4.19 installieren. Ob das bei einem aktuellen Fedora 30/31/32 eine gute Idee ist, mag ich nicht entscheiden wollen. Allerdings hatte der 5.3er noch Multitouch dabei. Da frage ich mich jetzt, wieso das abgeschaltet wurde.

Weniger Energieverbrauch .. vielleicht

Eine andere Sache, die noch untersucht werden muß, ist der anscheinend geringere Stromverbrauch des 5.5.8 Kernels auf dem Surface Pro 4. zunächst sah es eher nach einem Batteryauslesebug aus, weil das Gerät lange auf 100% blieb, aber mittlerweile könnnte auch ein leichter Einspareffekt vorhanden sein. Ich hab das SP4 noch nicht lange genug im Referenzkernel laufen lassen, um da einen Vergleich zu haben. Ich schau nachher mal.

Kameras gehen immer noch nicht

Tja, schlechte Nachrichten für die NSA, die Kameras der Surface Pro 4+ funktionieren immer noch nicht unter Linux, was an sich jetzt schade für reguläre Kameranutzer ist. Dafür soll das Wifi jetzt im 5G Betrieb stabiler sein, was ja auch nicht ganz unpraktisch ist.

Die Sache mit dem Secure Boot

Nachdem ersten Boot, kommt im Bootprozess eine mördermäßig wichtige Einblendung, die einem bei der Installation auch mitgeteilt wird, allerdings steht im Installationshinweis, daß man, WENN MAN danach gefragt wird, ein Password eingeben soll um den signierten Kernel, bzw. dessen Signatur, ins Bios zu bekommen um dann Secure Boot nutzen können. Tja, was soll ich sagen, die Abfrage kam so nicht, denn dazu muß man während ein Timer runterzählt auf eine Taste drücken, sonst wird man auch nicht nach dem Passwort gefragt 🙂

Da ich da noch unsignierte Kernels zum Testen liegen habe, kann ich SecureBoot eh nicht einschalten, insofern ist mir das auch egal 😉 Wenn der neue Kernel natürlich dauerhaft funktioniert, dann kann man das später immer noch mit Hilfe des mokutil erledigen.

Der TypeCover Bug

Zwar prellt das TypeCover nicht mehr, aber dafür funktioniert es auch nicht mehr, wenn man es abzieht und wieder dran steckt. Was ein Problem darstellt, da man das Surface Pro 4 neu booten muß.

Ihr seht, da werden noch einige Fixe nötig werden, bis das stabil läuft.

Kernel <= 5.5.9 mit USB Bug

Besonders für alle Fans von  Surface Pro Linux-Tablets habe ich eine schlechte Nachricht im Bezug auf den Kernel 5.5.8: einige USB Geräte werden nur beim Booten erkannt, später aber nicht mehr.

Kernel <= 5.5.9 mit USB Bug

Die Liste der betroffenen Geräte dürfte bislang eher übersichtlich sein, da z.B. meine USB Maus oder mein USB Gigabit LAN Adapter  von dem Problem nicht betroffen sind. Über die Ursache ist bislang auch noch nichts bekannt, was aber nicht verwundert, da wir das erst heute Vormittag verifiziert bekommen haben.

Was ist denn überhaupt los?

Wenn man das Gerät mit Kernel 5.5.x bootet, wird das Microsoft eigene TypeCover, das ist die Tastatur und das Mauspad, welches auch als Deckel dient, korrekt als USB Device erkannt und funktioniert entsprechend. Allerdings nur so lange, bis jemand das TypeCover abzieht und wieder dransteckt. Dann funktioniert es nicht mehr.  Dabei ist es egal aus welcher Quelle man den Kernel hat, ob er direkt von Fedora oder selbst gebaut ist.

Wie wirkt sich das aus?

Die Ursache dafür, daß das TypeCover nach dem Einstecken an das Gerät nicht mehr funktioniert ist, daß es überhaupt nie vom USB BUS abgemeldet wurde. Das manifestiert sich darin, daß man mit „lsusb“ das Gerät noch sieht, auch wenn es bereits am anderen Ende der Wohnung liegt. Folglich wir es beim Einstecken nicht initialisiert und kann so seinen Job nicht tun.

Gegenmaßnahmen

Wie schnell so einn Satz wie „Derzeit hilft nur ein Reboot.“ obsolete wird. Der Einsatz von Kernel 5.5.9-200 (Upstreambuild) oder 5.4.19 bzw. jedes anderen 5.4er Kernel ohne Sicherheitslücke löst das Problem auch, weil es da nicht auftritt. Somit wurde auch indirekt bestätigt, daß es nur am Kernelcode liegt und nicht an der Installation oder irgendwelchen UDEV Tricks, die sind bei allen Kernels gleich, weswegen man die aus der Gleichung streichen kann.

Der Nachteil beim 5.4.x Kernel ist allerdings, daß er zu viel Strom verbraucht. Es wurden im Leerlauf 12 W gemessen, wo mit einem für Surface gebaute Kernel nur ~5 W verbraucht werden. Das sich das echt fies auf die Laufzeit auswirkt, dürfte jedem klar sein.

Die derzeit im Test befindliche 5.5.9-100 von Fedora löst das Problem noch NICHT.

Update ( 11:55 Uhr )

Wie das so mit Eilmeldungen ist, der Patch in 5.5.9-2 ist nicht stabil. Ein einem Boot funktioniert USB wieder, im anderen nicht. Ich halte Euch auf dem Laufenden, wenn ich was neues erfahre.