Pinephone: Die Sache mit der Hardwarebeschleunigung

Liebe Linuxphone Fans,

wir können Eurer Telefon schneller und energieeffizienter machen \o/

Pinephone: Die Sache mit der Hardwarebeschleunigung

Wie wir wissen, ist die MALI400 GPU in dem Pinephone, um es Milde auszudrücken, nicht die beste GPU. Aber sie reicht um MPV so schnell zu machen, daß FullHD Videos komplett ruckfrei laufen.

Wir brauchen als erstes die libva-v4l2-request Library:

sudo dnf -y install libva-v4l2-request

dann müssen wir das Desktopfile von MPV ändern:

Exec=env LIBVA_DRIVER_NAME=v4l2_request LIBVA_V4L2_REQUEST_VIDEO_PATH=/dev/video0 LIBVA_V4L2_REQUEST_MEDIA_PATH=/dev/media0 mpv –osd-duration=3000 –fs –hwdec=vaapi-copy –vo=gpu,drm –player-operation-mode=pseudo-gui — %U

Wenn man jetzt MPV startet, dann hat man praktisch kein Frame-Drops. Bei einem 5 Minuten Video kam ich auf 17 Drops. Leider kommt das stark drauf an, welcher Codec in dem Film oder Stream, ja richtig gelesen, drin ist. Es gibt offensichtlich gut zu dekodierende Dateien und weniger gute, obwohl die alle vom gleichen Programm gebaut wurden. Aber selbst die schlechten waren ohne Verluste zu sehen.

Im Zuge des LPD 2021.1 probiere derzeit One-2-Many Streaming aus und hab dem Pine dann mal den 15 Mb/s Feed vorgesetzt. Das hat den Chip komplett überlastet 😀 Da hing nach ein paar Minuten der Videofeed 30 Sekunden hinterher, aber der Ton war nur 1-3 Sekunden hinterher. Das war überraschend. Offensichtlich lädt und Dekodiert MPV das in zwei getrennten Threads.

Firefox & Chromium

Weniger erfolgreich war ich bei Firefox und Chromium. Chromium hat zwar bessere Ergebnisse abgeliefert als Firefox, der komplett gefailed hat. Beides war aber noch keine Bestätigung, daß es überhaupt funktioniert hat. Beim Firefox fehlen neuerdings Configoptionen, die vor 6 Monaten noch gebraucht wurden. Ich habe mal den Herrn Stransky von Redhat zurate gezogen, der das bei Firefox eingebaut hat. Mal sehen was dabei rauskommt.

Pinephone: Taschenlampen App – die Zweite

Hallo Linuxphone-Fans,

ich habe da mal die Taschenlampen App etwas vereinfacht und von Eurem Phosh aufrufbar gemacht.

Pinephone: Taschenlampen App – die Zweite

Auf Github habe ich Euch die Sourcen dafür heute bereitgestellt. Ok, ok.. es ging nicht eher, ich hab es erst heute geschrieben 😉

https://github.com/Cyborgscode/pinephone/tree/main/flashlight

Der Unterschied von dieser Version zu der Bash Version mit Sudo ist, es kommt ohne Sudo aus … und ist nicht mehr Bash, sondern C . Alles was Ihr zum Kompilieren braucht, ist das gcc Packet und das eine oder andere Develpaket. In einem Develpaket sind Strukturen, Definition und Macros gespeichert, die für die Benutzung einer Library benötigt werden. Man kann da auch andere Sachen reinschreiben, aber das führt jetzt zu weit.

Wie bauen wir die neue Taschenlampe jetzt?

Wenn wir uns das Makefile ansehen, welches hier wirklich ein Makefile ist und nicht ein File für den „make“ Befehl, ist die Sache ganz einfach:

gcc flashlight.c -o flashlight

Damit bauen wir das Binary, also die ausführbare Datei. Wenn Ihr das direkt auf Eurem Pinephone macht, wird da automatisch ein für die laufende Architektur gedachtes File erzeugt. Hier ist das „aarch64“. Wenn Ihr das spaßeshalber auf Eurem großen PC macht, und dann die Datei auf das Pine kopiert, werdet Ihr feststellen, daß es nicht funktioniert. Auf Eurem großen PC wurde es für x86_64 gebaut.

Ist das Binary fertig, setzen wir die nötigen Rechte: Hier „Jeder darf es ausführen und bei Ausführung darf es das als Root tun“. Wir erinnern uns: Rootrechte sind nötig, um die LED Helligkeit setzen zu dürfen.

chmod 755 flashlight
chmod u+s flashlight

Nun kopieren wir das Binary „flashlight“ an seinen Ausführungsort: /usr/local/bin

rm -f /usr/local/bin/flashlight
mv flashlight /usr/local/bin/

Jetzt noch die Desktopdatei ins passende Applicationsverzeichnis verschieben:

rm -f /usr/share/applications/flashlight.desktop
cp flashlight.desktop /usr/share/applications/

Wieso ist hier „cp“ im Spiel und nicht „mv“ wie beim Binary?

Vielleicht wollt Ihr ja mal ein Update machen und dann wär es doch Schade, wenn das Desktopfile weg wäre. Das Binary baut Ihr ja jedes mal neu, ob das für einen zweiten Durchlauf noch vorhanden ist, spielt keine Rolle. Das Desktopfile wäre dann weg 😉

Wieso ist das dem Sudo-Bash Konstrukt überlegen?

Für das korrekte Sudofile muß man wissen, wie der Username des ausführenden Benutzers lautet. Seine UID würde vielleicht auch noch gehen. Außerdem mußten wir erstmal die sudoers-Datei ändern, damit die Anweisung ausgeführt wurde. Das fällt alles komplett weg.

Damit das Programm so auf jeder Distribution einsetzbar, völlig egal von den Umständen.

Gibt es Sicherheitsbedenken?

Die gibt es immer, es ist ein SUID Programm. Nun ist in dem Programm nichts drin, was gefährlich ist, solange die echten Betriebssystem Libs benutzt werden. Schafft es ein Angreifer, dem Befehl eine eigene Kopie einer benutzten System-Lib unterzujubeln, und dafür gibt es Möglichkeiten, könnte er die Funktionsaufrüfe nutzen und einfach irgendwas anderes machen.

Ich denke aber nicht, daß das mit diesem Build möglich ist. Falls Ihr Verbesserungen habt, schickt einen Pull-Request in Github-Repo oder lasst einen Kommentar da. C ist nicht gerade mein Steckenpferd und die GCC Options schon gar nicht 😉

Wann kommt das endlich in den Fedora Build rein?

Überraschung !… Torbuntu baut schon dran 😀

Flatpaks als Platzfresser

Falls sich jemand gefragt hat, warum ich so ungern Flatpaks einsetze:

org.gnome.Fractal permissions:
    ipc      network              fallback-x11      pulseaudio      wayland      x11
    dri      dbus access [1]

    [1] org.freedesktop.Notifications, org.freedesktop.secrets


        ID                                                Zweig          Op        Remote         Download
 1. [✓] org.freedesktop.Platform.GL.default               20.08          i         flathub         95,3 MB / 95,9 MB
 2. [✓] org.freedesktop.Platform.GL.nvidia-460-39         1.4            i         flathub        133,2 MB / 133,3 MB
 3. [✓] org.freedesktop.Platform.ffmpeg-full              20.08          i         flathub          3,9 MB / 4,1 MB
 4. [✓] org.freedesktop.Platform.openh264                 2.0            i         flathub          1,5 MB / 1,5 MB
 5. [✓] org.gnome.Fractal.Locale                          stable         i         flathub         13,4 kB / 233,8 kB
 6. [✓] org.gnome.Platform.Locale                         3.38           i         flathub         23,8 MB / 326,1 MB
 7. [✓] org.gnome.Platform                                3.38           i         flathub        292,9 MB / 344,0 MB
 8. [✓] org.gnome.Fractal                                 stable         i         flathub          3,5 MB / 3,6 MB

Installation complete.

Das sind 3,5 MB für die Anwendung, und 570 MB für die Abhängigkeiten. Also wenn man jetzt nicht GBweise Flatpaks einsetzt ist das Verhältnis so richtig fürn Arsch. Aufm Pine waren das ungelogen sogar 1GB an Abhängigkeiten.

Und das ist nur ein Grund wieso 😉

Fedora: wie man mit RPM sein System auf Integrität prüft.

Heute geht es um Dateiintegrität und wie man das mit RPM prüft und ggf. behebt. Grund ist das Pinephone.

Fedora: wie man mit RPM sein System auf Integrität prüft.

Wenn man sein Pinephone zum ersten mal bootet, startet es mit dem Image auf der internen Storage mmcblk2. Will man etwas anderes Booten, so steckt man eine SD Karte rein, auf dem das Bootimage drauf ist. Das ist gerade am Anfang, wenn man viel Testet eine normale Sache, weil man die MicroSD Karte leicht wieder mit einem SD-Kartenreader am PC neu bespielen kann.

Wenn man aber zu an einen Punkt gekommen ist, wo das System gut genug funktioniert, möchte man es auf die interne Speicherkarte kopieren. Das könnt Ihr via rsync machen, oder Ihr kopiert die SD-Karte mit dem Tool dd rüber. Das hat aber einen Haken: Von dem System habt Ihr gerade gebootet und das läuft noch. Da man die Karte im laufenden Betrieb nicht wechseln sollte, steht Ihr vor einem Problem. Rsync umgeht das, aber Systemfiles lassen nicht so einfach syncen. Würde man so z.b. ein Fedora 33 auf ein anderes Fedora 33 syncen, würde es vermutlich laufen, aber (wie hier) ein Fedora auf Manjaro Syncen geht sehr wahrscheinlich voll in die Hose.

Wenn wir also dd steigt zwar die Erfolgschance, aber ein Datenverlust steht im RAM, weil die Programme auf der Partition rumwerkeln und die sich beim Kopieren ändern. Also am besten ALLES was geht beenden: Desktop, Services, alles bis auf SSHd und das Netzwerk.

Schritt 1 – Ermitteln was drauf ist

Dazu führt Ihr „rpm -qa > rpms“ aus. Nicht vergessen das File nachher wieder zu löschen.

Schritt 2 – jedes Paket prüfen

Dazu brauchen wir awk und ein klein wenig Bashmagie:

awk < rpms ‚{print „rpm -V –nolinkto –nomtime –nomode –nouser –nogroup –nordev –nodeps „$1;}‘ | bash > log

Das liest die Liste der RPMs Zeile-für-Zeile ein und prüft das Paket, ob die Checksummen mit den Dateien übereinstimmen. Einige Tests sind absichtlich abgeschaltet worden, weil für den Test, ob eine Datei beschädigt ist oder nicht, nicht nötig. Ob ich da mal dran war und die absichtlich verändert habe, war nicht die Aufgabe, kann man so aber auch machen, wenn man die –no Flags weglässt. „–nodeps“ sollte man aber drin lassen, weil sonst jedes Paket immer mit allen Abhängigkeiten geprüft wird und wir prüfen eh alle einzeln 😉

Schritt 3 – Defekte Dateien finden

Da wir in Schritt 2 eine Log-Datei angelegt haben, werten wir die aus und lassen uns gleich die Paketnamen der defekten Dateien geben. Das „sort -u“ wirft doppelte raus:

grep „\.5\.\.“ log | grep -v “ c “ | grep -v “ d „| grep -v ^S | awk ‚{print „rpm -qf „$2;}‘ | bash | sort -u

.5… ist die Ausgabe, wenn die Datei beschädigt ist und z.b. keine Configdatei ist. Configs können sich natürlich jederzeit ändern, deswegen sind die nicht gleich defekt.

Ein paar Beispiele was die Ausgaben so meinen:

S.5…… c /etc/ssh/sshd_config  Datei hat andere Checksumme, ist aber eine Configdatei
fehlend d /usr/share/man/fr/man1/manconv.1.gz Datei ist eine Dokumentation, nicht tragisch, wenn die nicht da ist.
fehlend /boot/efi/overlays/adau1977-adc.dtbo Datei fehlt und sollte aber da sein.
..5…… /usr/bin/mokutil Datei ist defekt und sollte ersetzt werden.

Schritt 4 – Reparieren

Nun haben wir eine Liste mit Paketnamen und müssen die nur noch reparieren. In meinem Fall waren es vier defekte Pakete:

dnf reinstall dcraw efibootmgr f2fs-tools mokutil -y

Das muß natürlich bei Euch so nicht passen, es könnte auch gut gehen oder andere Dateien betreffen!

Vom efibootmgr wissen wir jetzt, daß er gar nicht nötig ist auf einem Pinephone, weil das U-Boot benutzt und so gesehen kein EFI Bios vorhanden ist.

Ein Wort noch zum Pinephone:

Kopiert das System ruhig auf die interne Karte, weil das dann ca. 5x schneller ist: beim Booten, beim Runterfahren, Apps starten und updaten. Es lohnt sich wirklich.

Fedora: Gnome-Shell 40.0 Alpha auf dem Pinephone

Liebe Linuxphone-Fans,

ich habe für Euch Gnome 40.0 Alpha ausprobiert, und ja, das wird das spannend als Mobildesktop.

Fedora: Gnome-Shell 40.0 Alpha auf dem Pinephone

Kleiner Nachtrag zur Phoshumstellung:

Wenn man in Gnome-Tweaks die Text-Skalierung auf „1“ stellt, dann paßt der Unlocker auf den physikalischen Bildschirm.

Bei den Ganzen Toolkits ist mit dem DPI Scaling echt was faul, anstatt erst den Text zu vergrößern und dann zuberechnen wo der hin muß, wird erst berechnet wo das hin müßte und dann der größere Schriftsatz verwendet.

Das Lego-Film Motto kann man hier leider noch nicht anwenden, aber das wird schon 😀

Um Gnome ausprobieren zu können, muß man phosh erstmal stoppen. Das bedeutet, erst Phosh benutzen, damit man ins WLan kommt, dann per SSH als root einloggen und „systemctl stop phosh“ eingeben. Jetzt wärs es clever, die passenden Gnome Pakete zu installieren.

Die Pakete

Hier, was bei mir funktioniert hat:

chrome-gnome-shell-10.1-12
desktop-backgrounds-gnome-33.0.0-2
f33-backgrounds-gnome-33.0.8-2
gnome-autoar-0.2.4-5
gnome-backgrounds-3.38.0-2
gnome-backgrounds-extras-3.38.0-2
gnome-bluetooth-3.34.3-2
gnome-bluetooth-libs-3.34.3-2
gnome-calculator-3.38.2-2
gnome-classic-session-40.0~alpha.1-2
gnome-clocks-3.38.0-2
gnome-color-manager-3.36.0-4
gnome-contacts-3.38.1-2
gnome-control-center-3.38.3-2
gnome-control-center-filesystem-3.38.3-2
gnome-desktop-2.32.0-30
gnome-desktop3-3.38.3-2
gnome-disk-utility-3.38.1-2
gnome-icon-theme-3.12.0-15
gnome-initial-setup-3.38.3-2
gnome-js-common-0.1.2-22
gnome-keyring-3.36.0-5
gnome-keyring-pam-3.36.0-5
gnome-keyring-sharp-1.0.1-0.35.133722svn
gnome-maps-3.38.3-2
gnome-menus-3.36.0-4
gnome-online-accounts-3.38.0-2
gnome-phone-manager-telepathy-0.69-34
gnome-power-manager-3.32.0-6
gnome-remote-desktop-0.1.9-3
gnome-screenshot-3.38.0-2
gnome-session-3.38.0-3
gnome-session-wayland-session-3.38.0-3
gnome-session-xsession-3.38.0-3
gnome-settings-daemon-3.38.1-2
gnome-shell-40.0~alpha.1.1-4.20210202git9ce666ac1
gnome-shell-extension-apps-menu-40.0~alpha.1-2
gnome-shell-extension-common-40.0~alpha.1-2
gnome-shell-extension-horizontal-workspaces-40.0~alpha.1-2
gnome-shell-extension-launch-new-instance-40.0~alpha.1-2
gnome-shell-extension-places-menu-40.0~alpha.1-2
gnome-shell-extension-user-theme-40.0~alpha.1-2
gnome-shell-extension-window-list-40.0~alpha.1-2
gnome-system-monitor-3.38.0-2
gnome-terminal-3.38.1-3
gnome-themes-extra-3.28-10
gnome-tour-3.38.0-3
gnome-tweaks-3.34.1-2
gnome-usage-3.38.0-2
gnome-weather-3.36.1-3
libgnomekbd-3.26.1-5
libgnome-keyring-3.12.0-21

Auf die TOUR kann man getrost verzichten, aber ansonsten ist das so das „normale“ Minimalpaket.

Euer Pinephone zeigt jetzt einen schwarzen Bildschirm. Jetzt brauchen wir GDM : „systemctl start gdm“ .

Ein paar Sekunden später erscheint die neue Loginmaske von Gnome 40. Jetzt als „pine“ User einloggen und etwas Geduld, startet die Gnome-Shell sehr langsam vor sich hin. Leider gibt es vom Greeter keinen Screenshot, mangels Möglichkeit.

Was Ihr jetzt nicht seht, Euch aber leider eine Weile begleitet, der GDM Prozess läuft im Kreis mit 100% auf einem CPU-Core. Ihr habt also nur 3 Kerne und das Telefon wird jetzt sehr schnell, sehr warm. Zum Ausprobieren reicht das, aber ein als Dauerzustand kann man das vergessen.

Links seht Ihr, was Euch dann erwartet. Irgendwas passend skalieren scheint keiner richtig sauber hinzubekommen 🙁

Das ist der App-Starter, den man aber nicht anklicken kann, sondern ausschließlich per Swipe von Links->Rechts reinbekommt. Das Gnome-Dock von früher wurde nach unten verlegt und auch hier patzt die Gnome-Shell mit dem Scaling wieder. Zieht sich durch wie ein roter Faden 😉 Es ist eine Alpha, da ändert sich noch sehr viel.

Die Aktivitätenübersicht

Die App-Übersicht aka. Aktivitäten kann man links oben in der Ecke anklicken oder per Drei-Finger-zusammenzieh-Swipe aktivieren. Der Swipe ist allerdings eher hinderlich, weil die laufenden App allergisch auf die ersten Klicks der Finger reagieren könnten 😀 Das war bei 3.38 auch nicht anders.

Oben im Bild seht Ihr diese Minivierecke, das ist die Aktivitätenvorschau, auch hier hat das Skalieren komplett versagt. Das wird unmöglich so bleiben, weil viel zu winzig. Jetzt dürft Ihr mal raten, wie man App von einer Aktivität in die andere bekommen… ja, der dicke Finger hat, schafft das niemals gewollt das richtige Minivierreck zutreffen 🙂

Die Extensions

Wer alte Extensions im Home hatte, der darf die Updaten. Da das eine Alpha ist, gibt es da nur sehr wenig zum Updaten, ergo funktionieren die meisten Extensions nicht mehr, so auch meine Internet Radio App und da hatte ich mich schon so gefreut.

… Was cooles …!!!

Bei all den kleinen Problemen gibt es auch was positives zu berichten: Automatische Bildschirmrotation und GPS gehen mit Gnome auf dem Pinephone \o/ Die Bildschirmrotation arbeitet sauber und schnell. Sie läßt sich wie auch auf Laptops und Tablets mit einem Klick blockieren, wenn einem das auf den Keks geht.

Erstes Fazit

Wenn man mal von der Langsamkeit des belegten CPU Kerns absieht, dem allgemein langsameren Start von Gnome an sich und den Skalierungsproblemen, fühlt sich das ganz gut an, wenn man es benutzt. Deswegen kann es neben Phosh wieder spannend werden, welcher Desktop am Ende das Rennen machen wird.

Was leider nicht klappt ist, daß man in GDM beim der Anmeldung auf Phosh oder Cinnamon zu wechseln. Das wäre genial gewesen. Die Anmeldung wird bei GDM übrigens per OSK erledigt und daher auch ein echtes Passwort sein kann, statt nur Zahlen wie bei Phosh.

Hat also alles seine Vor- und Nachteile.

Fedora: Pinephone Audiobug gefunden

Liebe Linuxphone-Fans,

vor einigen Tagen viel auf, daß das Pinephone nichts mehr aufnahm. Dem kann nun abgeholfen werden.

Fedora: Pinephone Audiobug gefunden

In einer Aufgabenstellung, die Hercules, Asterix und Obelix alt aussehen lässt, habe ich in rund 5 Stunden alle 130 Updates, die als Auslöser in Frage gekommen sind, von Hand eingespielt und geprüft. Wie oft das Handy rebootet wurde könnte ich nicht aufzählen. Die Mühe hat sich gelohnt, wir haben jetzt einen Matrixserver.. Wait what? Ähm ja, also äh anderes Thema.

Es war Pipewire 0.3.21-2. Besorgt Euch von Koji einfach diese Pakete:

pipewire0.2-libs-0.2.7-4.fc33.aarch64.rpm
pipewire-0.3.20-1.fc34.aarch64.rpm
pipewire-alsa-0.3.20-1.fc34.aarch64.rpm
pipewire-gstreamer-0.3.20-1.fc34.aarch64.rpm
pipewire-libs-0.3.20-1.fc34.aarch64.rpm
pipewire-pulseaudio-0.3.20-1.fc34.aarch64.rpm

und installiert die mit „dnf -y downgrade pipew*0.3.20*rpm„. Danach noch ein Reboot und der Ton ist wieder aufzeichenbar, sprich man wird wieder gehört am anderen Ende. Wenn Ihr schon dabei seid, und das noch nicht gemacht habt, dann downgraded auch glib2 auf 2.67.1, machts leben leichter 😉

Soviel also zum „pipewire wäre schon fertig“ Gerücht 😀

Noch ein Tip:

Überlegt Euch genau ob Ihr Flatpaks nutzen wollt: Schon die erste App, die Gnome braucht, verballert schon 1 GB auf der Platte an Abhängigkeiten! Das System ist echt krank.

presenting the Rawhide Downgrade to past date script

The this script gets the latest updates via dnf log files and reversed the system back to a given date in time, that is still in the logfile.

Presenting the Rawhide Downgrade to past date script

It’s far from perfect, but tries it’s best.  You need to install koji package first:  „dnf install koji

Most likely outcome: some packages will be missing, because koji can’t find them and some will be double present, with different versions and you end up in a collision. Remove the higher version files manually and do „dnf downgrade ./*rpm

Usage: scriptname {timestamp}

#!/bin/bash

grep "Upgraded:" /var/log/dnf.rpm.log | sort -r > /tmp/liste

mkdir rpmdownload
cd rpmdownload

if [ "" == "$1" ]; then

	echo "Keine Zeit angegeben.. benutze 4.2.2021"
	since=$(date --date="2021-02-04T00:00:00+0100" "+%s")

else 
	since=$(date --date="$1" "+%s")

fi

packs=""

declare -A old = ()

IFS=$'\n'
for line in $(cat /tmp/liste)
do 

	date=$(echo $line|sed -e "s/ .*//g")
	pkg=$(echo $line|sed -e "s/^.*: //g")
	
	time=$(date --date="$date" "+%s")

	if [ $time -gt $since ]; then 
	
		echo "$date => OK => $pkg"
		
		koji download-build --rpm $pkg
		basename=$(rpm -q --queryformat="%{Name}" ./$pgk)

		if [ "${old[$basename]}" != "" ]; then
			echo "found old entry ${old[$basename]}";
			rm -f ${old[$basename]}
		fi 

		$old[$basename]="$pkg"
		packs="$packs $pkg"
		
	else 
	
		echo "$date => IGNORE => $pkg"
	fi
	
done

if [ "$packs" != "" ]; then

	dnf -y downgrade ./*rpm
	
fi 

When is it usefull?

If something, you don’t know of, broke the system by Updates and you need to undo tons of downgrades. Happend to pinephones on the 8th of February 2021.

Fedora: Pinephone kann nicht mehr telefonieren

Liebe Linuxphone-Fans,

seit rund einer Woche funktionierte das Telefonieren auf dem Pinephone, weil endlich alles mit Pipewire verdrahtet wurde. Ein Update später schweigt das Mikro.

Fedora: Pinephone kann nicht mehr telefonieren

Wer jetzt erst das Fedorainstallationsimage vom 31.1.  installiert, darf auf keinen Fall ein Update einspielen. Das ist heute schon die zweite Updatewarnung, aber die hier hat es in sich, denn wir haben keinen Schimmer wieso das nicht mehr geht. Ein Workaround ist daher erst einmal nicht in Sicht.

Dieser Beitrag hier, wurde nur möglich, weil ich genau das Problem mit dem Mikro untersucht habe:

Fedora: Phosh crasht wegen glib2 Patch

Problem ist, daß das voll gepatchte Pinephone zwar technisch telefonieren kann, aber kein Ton vom Angerufenen ankommt, weil das Mikro den Ton nicht mehr aufnimmt. Dies ist aber erst am 8.2. per Update zerschossen worden. Leider waren das hundert Updates, das zu tracken ist schwierig. Weil die Frage schon kam, nein, die Hardwareschalter hat keiner angefasst.

Randnotiz: Torbuntu wäre gestern Abend fast vom Stuhl gekippt, als ich ihm das geschrieben habe 🙂 Tor ist einer der sehr aktiven Entwickler und baut u.a. den Kernel fürs Pinephone.

Golem ist im Test vom Libre M5 letzte Woche der gleiche Bug untergekommen. Vermutlich weil es nicht an den von Puri.sm entwickelten Komponenten lag, sondern am pipewire/alsa/pulse Subsystem. Lassen wir uns überraschen.

Update vom 11.2.2021

Wer schon in die Falle getreten ist, der wird das hier jetzt sehr zu schätzen wissen:

./intelligrade.sh 2021-02-08T00:00:00+0100

und nach einer Weile lädt Koji alle nötigen Pakete nach, und ein paar Doublettenentfernungen später, kann man das System mit 269 Updateschritten auf den Stand vom 8.2. zurücksetzen. Dann einfach rebooten und Mikro geht wieder!

Mehr dazu hier:

presenting the Rawhide Downgrade to past date script

Fedora: Phosh crasht wegen glib2 Patch

Liebe Linuxphone-Fans,

Ihr dürft mal wieder das Pinephone nicht Updaten, sonst knallts 🙁

Fedora: Phosh crasht wegen glib2 Patch

Dieser Stacktrace vom System zeigt exemplarisch das Problem:

Feb 10 21:31:02 fedorapine systemd-coredump[3835]: [🡕] Process 3144 (phosh) of user 1000 dumped core.
                                                   
                                                   Stack trace of thread 3144:
                                                   #0  0x0000007fa728b908 g_type_check_instance (libgobject-2.0.so.0 + 0x39908)
                                                   #1  0x0000007fa728026c g_signal_handlers_disconnect_matched (libgobject-2.0.so.0 + 0x2e26c)
                                                   #2  0x0000005587058218 mixer_control_output_update_cb (phosh + 0x58218)
                                                   #3  0x0000007fa7265948 g_closure_invoke (libgobject-2.0.so.0 + 0x13948)
                                                   #4  0x0000007fa729399c signal_emit_unlocked_R.isra.0 (libgobject-2.0.so.0 + 0x4199c)
                                                   #5  0x0000007fa7285e30 g_signal_emit_valist (libgobject-2.0.so.0 + 0x33e30)
                                                   #6  0x0000007fa72860e0 g_signal_emit (libgobject-2.0.so.0 + 0x340e0)
                                                   #7  0x0000005587084290 _pa_context_get_server_info_cb (phosh + 0x84290)
                                                   #8  0x0000007fa703fe58 context_get_server_info_callback (libpulse.so.0 + 0x12e58)
                                                   #9  0x0000007fa5a91bd0 run_action (libpulsecommon-14.2.so + 0x42bd0)
                                                   #10 0x0000007fa5a92564 pa_pdispatch_run (libpulsecommon-14.2.so + 0x43564)
                                                   #11 0x0000007fa7040170 pstream_packet_callback (libpulse.so.0 + 0x13170)
                                                   #12 0x0000007fa5a971e4 do_read (libpulsecommon-14.2.so + 0x481e4)
                                                   #13 0x0000007fa5a98b78 do_pstream_read_write (libpulsecommon-14.2.so + 0x49b78)
                                                   #14 0x0000007fa700e618 dispatch_func (libpulse-mainloop-glib.so.0 + 0x2618)
                                                   #15 0x0000007fa7157430 g_main_context_dispatch (libglib-2.0.so.0 + 0x57430)
                                                   #16 0x0000007fa71ae570 g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xae570)
                                                   #17 0x0000007fa7156af0 g_main_loop_run (libglib-2.0.so.0 + 0x56af0)
                                                   #18 0x0000007fa7a2b604 gtk_main (libgtk-3.so.0 + 0x26d604)
                                                   #19 0x000000558701f7c4 main (phosh + 0x1f7c4)
                                                   #20 0x0000007fa6981a9c __libc_start_main (libc.so.6 + 0x24a9c)
                                                   #21 0x000000558701fa78 _start (phosh + 0x1fa78)
                                                   
                                                   Stack trace of thread 3145:
                                                   #0  0x0000007fa6a2dfb0 __poll (libc.so.6 + 0xd0fb0)
                                                   #1  0x0000007fa71ae50c g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xae50c)
                                                   #2  0x0000007fa71548ec g_main_context_iteration (libglib-2.0.so.0 + 0x548ec)
                                                   #3  0x0000007fa7154954 glib_worker_main (libglib-2.0.so.0 + 0x54954)
                                                   #4  0x0000007fa7187a78 g_thread_proxy (libglib-2.0.so.0 + 0x87a78)
                                                   #5  0x0000007fa68defd8 start_thread (libpthread.so.0 + 0x7fd8)
                                                   #6  0x0000007fa6a3835c thread_start (libc.so.6 + 0xdb35c)
                                                   
                                                   Stack trace of thread 3147:
                                                   #0  0x0000007fa6a2dfb0 __poll (libc.so.6 + 0xd0fb0)
                                                   #1  0x0000007fa71ae50c g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xae50c)
                                                   #2  0x0000007fa7156af0 g_main_loop_run (libglib-2.0.so.0 + 0x56af0)
                                                   #3  0x0000007fa73eb7b8 gdbus_shared_thread_func.lto_priv.0 (libgio-2.0.so.0 + 0x1277b8)
                                                   #4  0x0000007fa7187a78 g_thread_proxy (libglib-2.0.so.0 + 0x87a78)
                                                   #5  0x0000007fa68defd8 start_thread (libpthread.so.0 + 0x7fd8)
                                                   #6  0x0000007fa6a3835c thread_start (libc.so.6 + 0xdb35c)
                                                   
                                                   Stack trace of thread 3148:
                                                   #0  0x0000007fa6a2dfb0 __poll (libc.so.6 + 0xd0fb0)
                                                   #1  0x0000007fa71ae50c g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xae50c)
                                                   #2  0x0000007fa71548ec g_main_context_iteration (libglib-2.0.so.0 + 0x548ec)
                                                   #3  0x0000007fa40fdd4c dconf_gdbus_worker_thread (libdconfsettings.so + 0x5d4c)
                                                   #4  0x0000007fa7187a78 g_thread_proxy (libglib-2.0.so.0 + 0x87a78)
                                                   #5  0x0000007fa68defd8 start_thread (libpthread.so.0 + 0x7fd8)
                                                   #6  0x0000007fa6a3835c thread_start (libc.so.6 + 0xdb35c)

Phosh semmelt hier brutal weg, wenn man an den Audioeinstellungen rumspielt. Verursacht wird dies mutmaßlich durch einen Patch der Glib2:

* Tue Feb 09 2021 Benjamin Berg <bberg@redhat.com> – 2.67.3-2
  – Add patches to move applications into systemd scopes

Ich sage mutmaßlich, weil ein Downgrade des Glib2 Paketes auf 2.67.1-4 das Problem sofort behebt. Es kann aber natürlich auch sein, daß einfach alle anderen Anwendungen und Libs noch nichts von dem Patch gehört haben und noch Code verwenden, der dann nicht mehr geht.

Das blöde an der Situation ist, daß sich die Pulseaudio-Einstellungen beim Einstecken von Kopfhörern und Telefonieren ändern, weswegen Phosh während eines Anrufs crasht und das Gespräch weiterläuft. Kein Desktop bedeutet aber auch, keine Kontrolle mehr über den Anruf.

Wäre ich zynisch drauf, würde ich eine CVE beantragen, weil man durch Anrufen einen DOS auslösen kann 🙂

Workaround:

Für normale Endanwender:

dnf downgrade https://kojipkgs.fedoraproject.org//packages/glib2/2.67.1/4.fc34/aarch64/glib2-2.67.1-4.fc34.aarch64.rpm

Für normale Entwickler, die auch das Devel Paket installiert haben, weil sie Software auf dem System kompilieren:

dnf downgrade https://kojipkgs.fedoraproject.org//packages/glib2/2.67.1/4.fc34/aarch64/glib2-2.67.1-4.fc34.aarch64.rpm https://kojipkgs.fedoraproject.org//packages/glib2/2.67.1/4.fc34/aarch64/glib2-devel-2.67.1-4.fc34.aarch64.rpm

Danach „systemctl restart phosh“ durchführen und Ihr seid wieder crashsicher.

Update:

Der Bug wird untersucht. Jede Menge Debugging und 1.2GB Debugpakete später, steht nur eins fest: Der Bug ist mehr als bescheiden zu debuggen!

Fedora: Pinephone Taschenlampenapp

Liebe Linuxphone-Fans,

eine Taschenlampen App darf auf einem Smartphone mit Scheinwerfer-LED nicht fehlen.

Fedora: Pinephone Taschenlampenapp

Bauen wir und doch kurz eine selbst 🙂

Schritt 1:  Das Script

In das File /usr/local/sbin/flashlight schreiben wir:

#!/bin/bash

STATE=$(cat /sys/class/leds/white\:flash/brightness)

if [ „$STATE“ == „0“ ]; then

echo 1 > /sys/class/leds/white\:flash/brightness

else

echo 0 > /sys/class/leds/white\:flash/brightness

fi

Dann „chmod 755 /usr/local/sbin/flashlight“ ausführen.

Schritt 2 : sudoers anpassen

Wir schreiben nach /etc/sudoers.d/flashlight.conf :

pine ALL = (root) NOPASSWD: /usr/local/sbin/flashlight

und in /etc/sudoers fügen wir am Ende an:

@include /etc/sudoers.d/flashlight.conf

Damit braucht der User „pine“ kein Passwort mehr eingeben um das Flashlight Script als Root auszuführen. Das ist leider nötig, da der Kernel nur ROOT Zugriff auf die LEDs erlaubt. Vermutlich ist das der Grund, wieso es in der Fotoapp Megapixels kein Blitzlichticon gibt.

Schritt 3: Das Desktopfile

Wir schreiben nach /usr/share/applications/flashlight.desktop  :

[Desktop Entry]
Name=Flashlight
Exec=/usr/bin/sudo /usr/local/sbin/flashlight
Type=Application
StartupNotify=true
Icon=/usr/share/icons/breeze/actions/32/flashlight-on.svg
Name[de_DE]=Taschenlampe

Speichern das ab und bekommen auf der Oberfläche das Appicon „Taschenlampe“ zu sehen. Das passiert aber nur, wenn es die Icondatei „/usr/share/icons/breeze/actions/32/flashlight-on.svg“ gibt. Notfalls mit DNF „breeze-icon-theme“ nachinstallieren. Ist der einzige, der eine Taschenlampe hat und das Icon sieht nicht so gut aus.

Natürlich könnt Ihr auch eine eigene Bilddatei mit einer vernünftigen Taschenlampendarstellung benutzen, nur der Pfad muß stimmen 😉