Fedora + Intel: Firefox startet nicht mehr

Fehlerbild: Firefox startet nicht mehr, es kommt nur noch die Meldung „eine andere Instanz von FF würde schon laufen“
Ein „killall -9 firefox“ mit anschließendem Start von Firefox führt nur wieder zum Fehler.

Fedora + Intel: Firefox startet nicht mehr

Das Problem war heute morgen, daß Firefox nicht mehr gestartet ist. kill -9 brachte nichts, und in der Konsole ausgeführt kam dann an einigem Warten die Meldung, daß die VAAP Tests gefailt sind.

Wer eine Intel GPU hat und heute ein Kernel-Update bekommen hat, sollte daher mal checken ob VAAPI noch geht : vainfo

Das muß in etwa so aussehen:

$ vainfo
Trying display: wayland
Trying display: x11
Trying display: drm
libva info: VA-API version 1.16.0
libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so
libva info: va_openDriver() returns -1
libva info: Trying to open /usr/lib64/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_15
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.16 (libva 2.16.0)
vainfo: Driver version: Intel i965 driver for Intel(R) Kaby Lake – 2.4.1
vainfo: Supported profile and entrypoints

Wenn das nicht der Fall ist, dann fehlen Euch vermutlich die GPU-Treiber für Intel. Das ist leicht zu überprüfen, in demIhr mal „/usr/lib64/dri/“ auflistet. Falls die oben zu sehenden Treiber nicht da sind, die gibt es bei RPMFusion als RPM: libva-intel-driver

Mit dem Paket geht dann auch Firefox wieder … aber erst nachdem der Firefox einmal im SAFE-MODE ( firefox –safe-mode) gestartet wurde.Es kann sich also auch gut um ein simples Verschlucken von Firefox gehandelt haben. Im schlimmsten Fall habt Ihr jetzt am Ende für Intel hardwarebeschleunigtes Video im Firefox 😉

 

Fedora & Kernel 6.3.4 und die nichtendenwollende Geschichte mit Nvidia

Ich bin ja gestern Abend schon gewarnt worden, daß das Kernel 6.3.4 Update Probleme bringen würde, aber hey, ich hatte doch damals im Januar, als Kernel 6.1.5 plötzlich mit schwarzem Bildschirm bootete, schon alles in Grub so geändert, daß es bereits funktioniert hat! Trotzdem hatte ich heute morgen einen schwarzen Bildschirm vor mir. Tja.

„Ups, we did it again“ ?

Ich erspare Euch mal viel Geschreibsel zur Suche, aber Ihr solltet vorher das hier gelesen haben:

Fedora: „Nein, es ist keine Verschwörung die User zum HW Wechsel zu bekommen.“

Heute morgen hatte ich also genau das gleiche Fehlerbild: schwarzer Bildschirm beim Booten. Passworteingabe blind.

Die Ursache war eine falsch zusammengebaute BLS Config, die sich aus den Grubdefaults ( /etc(/default/grub ) eine Kommentarzeile reingezogen hat, die aber seit dem Januarvorfall auskommentiert ist:

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=“$(sed ’s, release .*$,,g‘ /etc/system-release)“
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
#GRUB_TERMINAL_OUTPUT=“console“
#GRUB_CMDLINE_LINUX=“vconsole.font=latarcyrheb-sun16 rd.luks.uuid=luks-ed009ed3-118c-465d-9b89-9b2a4f5cc3f3 rd.luks.uuid=luks-9d2595b2-a35c-48c1-a839-bb54c1a96597 rhgb quiet splash audit=0 nouveau.modeset=0 rd.driver.blacklist=nouveau modprobe.blacklist=nouveau nvidia-drm.modeset=1 initcall_blacklist=simpledrm_platform_driver_init“
GRUB_CMDLINE_LINUX=“vconsole.font=latarcyrheb-sun16 rd.luks.uuid=luks-ed009ed3-118c-465d-9b89-9b2a4f5cc3f3 rd.luks.uuid=luks-9d2595b2-a35c-48c1-a839-bb54c1a96597 rhgb quiet splash audit=0 nouveau.modeset=0 rd.driver.blacklist=nouveau modprobe.blacklist=nouveau“
GRUB_DISABLE_RECOVERY=“true“
GRUB_VIDEO_BACKEND=vbe
GRUB_FONT_PATH=/boot/grub2/fonts/unicode.pf2
GRUB_GFXMODE=0x11b
GRUB_GFXPAYLOAD_LINUX=“keep“
GRUB_TERMINAL_OUTPUT=“gfxterm“
#GRUB_GFXMODE=“1440x900x32″
GRUB_ENABLE_BLSCFG=true

Nachdem das aus der BLS Configdatei für Kernel 6.3.4 raus war, funktionierte es auch wieder. Entscheidend war das hier „initcall_blacklist=simpledrm_platform_driver_init„, welches den Init vom SimpleDRM System verhindert hat. Scheinbar wurde endgültig der Support der alten Treiber, die durch die falsche gebaute Config immer noch benutzt wurden, endgültig aus dem Kernel entfernt. Damit die BLS Config dann wieder richtig geschrieben wird, muß die Kommentarzeile raus und grub2-mkconfig ausgeführt werden. Da in der /boot/grub2/grub.cfg aber die richtige Zeile drinstand, ist das schon ein sehr kurioser Fehler vom grub2-mkconfig.

Für Euch: Immer genau hinsehen, ob etwas wirklich so ist, wie es sein sollte.

Piper TTS braucht Eure technische Expertise

Beim letzten Linux am Dienstag wurde uns Piper TTS vorgestellt, daß in seiner initialen Version schon gute Resultate liefert, aber leider min. einen gravierenden Sprachfehler in den deutschen Modulen hat. Carola konnte natürlich nicht anders und hat die Sprachausgabe schon für sich gekappert 😉

Piper TTS braucht Eure technische Expertise

Laut dem GitHub Issue #52 ist dafür aber ESpeak-NG verantwortlich, weil es min. die Silbe „ch“ nicht richtig ausspricht. So klingen die deutschen Stimmen wie unsere holländischen Nachbarn. Eine provisorische Korrektur später, hatten wir allerdings Turkdeutsch in der Ausgabe, was auf seine Art auch irritierend ist, aber immer noch verständlicher, als wenn CH als ICK ausgesprochen wird 😉

Jetzt kommen die ESPEAK-NG Fachleute unter Euch ins Spiel: Wie bekommt man den Sprachfehler da jetzt raus?

Wenn jemand hilfreiche Tips hat, dann bitte direkt in dem GitHub Issue #52 zum Besten geben, um so schneller kann Piper die Standartsprachausgabe von Linux werden, auch wenn die noch einen weiten Weg hat.

Der Vorteil von Piper ist die komplett lokale Verarbeitung. Es ist zudem auch super schnell, variabel und kann in mehreren Sprachen benutzt werden. Leider fehlt dem TTS System noch jede Form von Betonung durch Satzzeichen, etwas, daß andere TTS wie das von Google oder Mary schon lange beherrschen.

Carola Integration

Das neueste Carola Paket v1.19 hat bereits die nötigen Konfigurationen und den Sprachbefehl mitbekommen. Außerdem könnt Ihr die Piper-RPMs auch im PVA Repo finden. Wer das selbst von Hand nutzen will, kann sich die Files von Github ziehen.

Wenn man eine „nicht-repo“ Version von Carola pimpen will, müßte man die Github-Dateien nach /usr/local/share so installieren:

piper
├── espeak-ng-data
├── libespeak-ng.so -> libespeak-ng.so.1.1.51
├── libespeak-ng.so.1 -> libespeak-ng.so.1.1.51
├── libespeak-ng.so.1.1.51
├── libonnxruntime.so.1.14.1
└── piper
piper-voices
├── voice-de-eva_k-x-low
├── voice-de-karlsson-low
├── voice-de-kerstin-low
├── voice-de-pavoque-low
├── voice-de-ramona-low
└── voice-de-thorsten-low

und dann das piper-say Script (im PVA Github Repo) benutzten: /usr/local/sbin/piper 

#!/bin/bash

NAME=$(mktemp)
TEMPO=0.95

if [ "$VOICE" == "" -o "$VOICE" == "de" ]; then
#VOICE="de-thorsten-low"
#VOICE="de-eva_k-x-low"
#VOICE="de-karlsson-low"
VOICE="de-kerstin-low"
#VOICE="de-pavoque-low"
#VOICE="de-ramona-low"
fi

TEXT="$1"

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

   TEXT=$(echo "$TEXT" | sed -e "s/ch/sch/g" -e "s/ssch/sch/g" | tr -d "\n" )
   echo "$TEXT" | /usr/local/share/piper/piper -m /usr/local/share/piper-voices/voice-$VOICE/$VOICE.onnx -f $NAME 2>/dev/null
   play $NAME tempo $TEMPO 2>/dev/null
   rm -f $NAME
fi

Die kleine Kompensation:

TEXT=$(echo „$TEXT“ | sed -e „s/ch/sch/g“ -e „s/ssch/sch/g“ | tr -d „\n“ )

ist leider nötig, weil wir ja nicht dauernd ICK hören wollen und weil Piper ein entscheidenden Bug hat:

Wenn es auf ein LF im Text trifft, fängt es hinter dem letzten LF erst an zu arbeiten. Ihr könnt Euch vorstellen, was passiert, wenn man Ende vom Text ein „LF“ steht? Genau ..“kritsch“ und das wars 😀

Quelle: https://github.com/rhasspy/piper

Wie komme ich ans Repo dran?

PVA: Carola hat Ihr eigenes Repo bekommen