Wine 5.7-1.1 lässt u.a. WOW crashen

Liebe Linux-Gamer und WOW Fans,

schlechte Nachrichten wenn Ihr auf WINE-STAGING 5.7-1.1 aktualisiert habt, das kann/wird schnell derbe abstürzen.

Wine 5.7-1.1 lässt u.a. WOW crashen

Wie ich am eigenen PC erfahren mußte, ist das Update WIne-Staging 5.7 leider defekt. WOW startet man damit genau für 0.5 Sekunden nach dem ersten Bildschirm 😉

Wer Fedora benutzt und sein Staging direkt aus dem Wine-Repo bezieht, der kann sich ganz leicht selber helfen:

sudo dnf downgrade wine-staging-common wine-staging64 -y
sudo echo „exclude=wine-staging*“ >> /etc/dnf/dnf.conf

Damit wird zu einen die 5.6er Version von Wine-Staging wieder eingespielt und zum Anderen verhindert, daß Wine mit dem nächsten Update wieder in 5.7. mitkommt. Natürlich müsst Ihr das aus der Conf wieder austragen, wenn der Bug gefixt wurde. Damit Ihr wisst, wann das der Fall ist, tragt Euch auf dem Wine-Bugracker als Follower ein:

https://bugs.winehq.org/show_bug.cgi?id=49011

Sobald das Problem behoben wurde, gibt es dazu eine Email vom Team.

Beitragsbild:

World of Warcraft®: Warlords of Draenor™©2014 Blizzard Entertainment, Inc. Alle Rechte vorbehalten. Warlords of Draenor ist eine Marke und World of Warcraft, Warcraft und Blizzard Entertainment sind Marken oder eingetragene Marken von Blizzard Entertainment, Inc. in den USA und/oder anderen Ländern.

Update: Bugnummer angepaßt.

Fedora: GlibC Update zerdängelt „Deutsch“

Das neueste Glibc Update zerlegt leider bei Fedora die Umlaute in allen neu gestarteten Programmen.

glibc-2.29.29 – Update mit Problemen

Das neueste ( 25.3. ) glibc Update, daß nach 14 Tagen ohne Karma gestern ins Stable gepusht wurde, weil es mal wieder keiner getestet hat, hätte mal lieber von Leuten getestet werden sollen : Es ist leider defekt  🙁

Im Thunderbird zeigt sich das Problem mit Ordnernamen, die deutsche Umlaute enthalten:

Außerdem kann Thunderbird keine Nachrichten mehr speichern, wofür ich noch keine Erklärung habe, da dort gar keine Umlaute im Spiel sein sollten.

Lösung:

Ihr laded Euch für FC30 folgende Pakete im Koji runter:

glibc-2.29-28.fc30.i686
glibc-2.29-28.fc30.x86_64
glibc-common-2.29-28.fc30.x86_64
glibc-devel-2.29-28.fc30.x86_64
glibc-headers-2.29-28.fc30.x86_64
glibc-langpack-de-2.29-28.fc30.x86_64  (siehe Unten)
glibc-langpack-en-2.29-28.fc30.x86_64
libnsl-2.29-28.fc30.x86_64
nscd-2.29-28.fc30.x86_64

Den Link dazu gibt es hier:

https://koji.fedoraproject.org/koji/buildinfo?buildID=1431046

Aber Vorsicht, nicht die falschen Pakete runterziehen, sonst geht nichts mehr. I686 und X86_64 sollten es schon sein.

Als Root führt Ihr dann das Downgrade aus im Downloadverzeichnis aus:

dnf downgrade ./nscd-2.29-28.fc30.x86_64.rpm ./libnsl-2.29-28.fc30.x86_64.rpm ./glibc-*rpm

Idealerweise beendet Ihr Thunderbird und alle anderen betroffenen Programme vorher und started es danach wieder.

Hinweis: Ihr habt ggf. nicht die langpack’s „de“ und „en“ installiert, sondern denn „glibc-all-langpacks“. Also braucht Ihr dann folglich auch „glibc-all-langpacks-2.29-28.fc30.x86_64.rpm“.

dann noch verhindern, daß es Updates gibt, bis das Problem gelöst wurde:

echo „exclude=glibc* nscd* libnsl*“ >> /etc/dnf/dnf.conf

Danach die Datei prüfen, ob da jetzt nicht zwei Zeilen Exclude drin sind und ggf. anpassen.

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.

 

FIXED: Apache 2.4.41-4

Für Euch frisch aus der Werkstatt: Apache httpd 2.4.41-4 löst das Problem „Apache httpd 2.4.41 mit defektem PIPE support

Fedora User können schon updaten

und zwar mit folgendem Befehl für FC29:

dnf -y update https://kojipkgs.fedoraproject.org//packages/httpd/2.4.41/4.fc29/x86_64/httpd-2.4.41-4.fc29.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/httpd/2.4.41/4.fc29/noarch/httpd-filesystem-2.4.41-4.fc29.noarch.rpm https://kojipkgs.fedoraproject.org//packages/httpd/2.4.41/4.fc29/x86_64/mod_ssl-2.4.41-4.fc29.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/httpd/2.4.41/4.fc29/x86_64/httpd-tools-2.4.41-4.fc29.x86_64.rpm

Die Version ist jetzt erst einige Minuten alt und wurde extra für uns gebaut \o/

Die FC30 Version gibt dann hier: https://koji.fedoraproject.org/koji/buildinfo?buildID=1393459

Alle Tests sind positiv, also könnt Ihr die erst einmal bedenkenlos installieren, solange die noch nicht im Fedora Updates Repo ist. Das sollte zwar heute noch der Fall sein, aber wem das CGI-Problem jetzt schon wie ein Furunkel am Hintern klebt, der kann sich jetzt vorzeitig entlasten 😉

GEdit und wieder grüßt der Murmelbug

Wir haben das Jahr 2019 und GEdit 3.30 und trotzdem grüßte mich heute der gleiche Bug wie in 2016: ß wird stillschweigend in ss umgewandelt, wenn man was sucht oder ersetzt!

Das ist wie der Murmeltiertag aus dem gleichnamigen Film. Und dieser Bug kann Eurer Frustrationslevel echt hochtreiben, wenn Ihr HTML Dokumente  anpassen müßt, die sehr sehr sehr sehr viele „class=X“ Anweisungen enthalten und die jetzt alle so aussehen „cla&szlig;=X“ , denn wenn man jetzt &szlig; wieder in „ß“ umwandeln lässt bekommt man .. na.. wer rät es .. „claß=X“ … \o/ Da freut sich der Browser mal so richtig drüber! 🙁

Fazit: anderen Editor verwenden! urgs!

Warnung: Libreswan kann Ihren Bootprozess stören – F29

Argss! Ja Argss! Da upgraded man 7800 Schritte lang seinen Desktop-PC auf ein Fedora 29, das auf den Servern ohne Probleme eingespielt werden konnte, auf dem Tablet und Laptop läuft, wo es exakt so per DNF eingespielt wurde, nur um dann festzustellen, daß das System nicht mehr bootet! Warum? Weil das Libreswan Paket wohl „defekt“ ist. ARGS!

Da tust Du alles um sicher zu sein und dann das!

Von dem Gedanken, das mein Desktop schnell mal eben auf ein neues Fedora hochgezogen werden kann, habe ich mich ja schon vor Jahren verabschiedet. Seit 0AD da drauf ist, dauert allein das  Herunterladen der Paket 25 Minuten und mehr, und 7800 Updateschritte brauchen auch mit SSD Support so um die 2 Stunden. Also schnappt man sich das Tablet, während der Desktop sein Upgrade fährt und macht was sinnvolles.. Kernel Updates einspielen z.B. 😉

Irgendwann war auch der Desktop durch und das obligatorische „reboot“ war fällig. Getan, gewartet, Festplattenpasswort eingetippt und …. tod.

Weil sich das schwer beschreiben läßt, hier der Bootlogauszug dazu:

Jun 14 19:13:06 meinpc systemd[1]: Started Restorecon maintaining path file context.
Jun 14 19:13:06 meinpc systemd[1]: Started LSB: Init script for live image..
Jun 14 19:13:06 meinpc systemd[1]: avahi-daemon.service: Start operation timed out. Terminating.
Jun 14 19:13:06 meinpc systemd[1]: systemd-logind.service: Start operation timed out. Terminating.
Jun 14 19:13:06 meinpc systemd[1]: ModemManager.service: Start operation timed out. Terminating.
Jun 14 19:13:06 meinpc ModemManager[1625]: <info> Caught signal, shutting down...
Jun 14 19:13:06 meinpc ModemManager[1625]: <info> ModemManager is shut down
Jun 14 19:13:06 meinpc systemd[1]: rtkit-daemon.service: Start operation timed out. Terminating.
Jun 14 19:13:06 meinpc systemd[1]: accounts-daemon.service: Start operation timed out. Terminating.
Jun 14 19:13:06 meinpc systemd[1]: systemd-machined.service: Start operation timed out. Terminating.
Jun 14 19:13:06 meinpc systemd[1]: NetworkManager.service: Start operation timed out. Terminating.
Jun 14 19:13:06 meinpc systemd[1]: rtkit-daemon.service: Failed with result 'timeout'.
Jun 14 19:13:06 meinpc systemd[1]: Failed to start RealtimeKit Scheduling Policy Service.
Jun 14 19:13:06 meinpc systemd[1]: accounts-daemon.service: Failed with result 'timeout'.
Jun 14 19:13:06 meinpc systemd[1]: Failed to start Accounts Service.
Jun 14 19:13:06 meinpc systemd[1]: ModemManager.service: Failed with result 'timeout'.
Jun 14 19:13:06 meinpc systemd[1]: Failed to start Modem Manager.
Jun 14 19:13:06 meinpc systemd[1]: Started NTP client/server.
Jun 14 19:13:06 meinpc systemd[1]: Started Hardware Monitoring Sensors.
Jun 14 19:13:06 meinpc systemd[1]: Starting SYSV: Late init script for live image....
Jun 14 19:13:06 meinpc systemd[1]: Starting ABRT Automated Bug Reporting Tool...
Jun 14 19:14:37 meinpc systemd[1]: Failed to get initial list of names: Connection timed out
Jun 14 19:14:37 meinpc systemd[1]: systemd-logind.service: Failed with result 'timeout'.
Jun 14 19:14:37 meinpc systemd[1]: Failed to start Login Service.
Jun 14 19:14:37 meinpc systemd[1]: systemd-machined.service: Failed with result 'timeout'.
Jun 14 19:14:37 meinpc systemd-coredump[1749]: Due to PID 1 having crashed coredump collection will now be turned off.
Jun 14 19:14:37 meinpc systemd[1]: Caught <ABRT>, dumped core as pid 1748.
Jun 14 19:14:37 meinpc systemd[1]: Freezing execution.
Jun 14 19:14:37 meinpc kernel: printk: systemd: 61 output lines suppressed due to ratelimiting
Jun 14 19:14:37 meinpc systemd-coredump[1749]: Process 1748 (systemd) of user 0 dumped core.

Stack trace of thread 1748:
#0 0x00007fa4b3f9087b kill (libc.so.6)
#1 0x00005583475eeeda n/a (systemd)
#2 0x00007fa4b4133070 __restore_rt (libpthread.so.0)
#3 0x00007fa4b3f9057f raise (libc.so.6)
#4 0x00007fa4b3f7a895 abort (libc.so.6)
#5 0x00007fa4b3fd39c7 __libc_message (libc.so.6)
#6 0x00007fa4b3fda2cc malloc_printerr (libc.so.6)
#7 0x00007fa4b3fdbafc _int_free (libc.so.6)
#8 0x00007fa4b4066ac7 __vasprintf_chk (libc.so.6)
#9 0x00007fa4b43d0630 log_format_iovec (libsystemd-shared-239.so)
#10 0x00007fa4b43d0b09 log_struct_internal (libsystemd-shared-239.so)
#11 0x0000558347610a0f n/a (systemd)
#12 0x00005583476132cb n/a (systemd)
#13 0x000055834766368e n/a (systemd)
#14 0x000055834763fb3b n/a (systemd)
#15 0x00005583476436aa n/a (systemd)
#16 0x0000558347626eed n/a (systemd)
#17 0x00007fa4b4455f02 n/a (libsystemd-shared-239.so)
#18 0x00007fa4b4457da5 sd_event_dispatch (libsystemd-shared-239.so)
#19 0x00007fa4b4457f30 sd_event_run (libsystemd-shared-239.so)
#20 0x00005583476300f6 n/a (systemd)
#21 0x00005583475ea78b n/a (systemd)
#22 0x00007fa4b3f7c413 __libc_start_main (libc.so.6)
#23 0x00005583475ec41e n/a (systemd)

So, jetzt sitzt der User da und hat kein System mit dem er was machen könnte, weiß nicht, was da nicht ging und hat natürlich auch kein Backup gemacht, von dem der User jetzt eh nicht wüßte, wie er es in dem Zustand zurückspielen sollte 🙂

Was also machen ?

  1.  Resetknopf drücken, wenn alle Festplattenindikatoren aufgehört haben zu blinken.
  2.  Kernelbootmenü abwarten
  3.  „e“ drücken, und die Zeile „linux ……“ um “ 1 init=/bin/bash“ am Ende erweitern, ggf. noch „splash quite rghb“ entfernen,  damit man bei nächsten boot was sieht.
  4.  STRG+x drücken
  5.  Jede Menge Kernel Meldungen laufen über den Bildschirm, wenn die aufhören, RETURN drücken.
  6.  /etc/init.d/network start
  7.  mount / -o remount,rw
  8.  dnf update

Jetzt wird uns dnf erzählen, daß crypto-policies wegen libreswan-libs nicht installiert werden kann. Das löst man so auf:

dnf erase libreswan*

es fliegen runter :

NetworkManager-libreswan-gnome-1.2.10-1.fc29.x86_64
NetworkManager-libreswan-1.2.10-1.fc29.x86_64
libreswan-3.27-1.fc29.x86_64

und jetzt kann man mit dnf update auch das letzte Paket für einen aktuelles Fedora installieren und oh Wunder, der Rechner booted wieder. Bugreport filed!

Hinweis: Dieses Problem wird natürlich nur ausgelöst, wenn man libreswan auch mal irgendwann installiert hatte 😉

Bitte lesen Sie auch das Update dazu : Update: Fedora 29 bootet nicht nach Upgrade

Firefox Addon Bug geht in Runde 2

Oh ja, Ihr dachtet es wäre vorbei? Der Zertifikatbug bei Mozilla wäre behoben? Weit gefehlt! Muahahar

Gegen 23:10 Uhr MESZ: Rückspiel

kam der Gegenschlag. Mozilla hat seit einigen Stunden signalisiert, daß das Problem behoben wäre. Mozillas Automatismus sollte das Problem genauso leicht beheben, wie es verursacht wurde.

Leider flogen gerade (23:10 Uhr) alle Plugins wieder in den Legacy Modus und liessen sich nur durch das Aktivieren und erneute Deaktivieren des KeySignings wieder zum Laufen bringen!

Also erneuerte Anleitung:

In der about:config einfach die Signaturenprüfung wieder anschalten:
xpinstall.signatures.required = true

und wieder abschalten:
xpinstall.signatures.required = false

Der FireFox braucht nicht neugestartet zu werden, aber die einzelnen Tabs müssen ggf. neu geladen werden.

1.Update: 5.5.2019

FireFox für Android schaltet alle Addons in den Legacy-Modus um, auch hier hilft wieder der Workaround von oben. Spannend daran ist, daß FireFox das erst beim Zweiten Start heute morgen gemacht hat. Aus Entwicklersicht ist das etwas merkwürdig.

2.Update: 6.5.2019

Seit gestern kursiert die FireFox Version 66.0.4 durch die Medien, diese soll das Problem jetzt endgültig lösen.

3.Update: 6.5.2019 15:00 Uhr

Ganz frisch aus dem Build Ofen von Fedora, FireFox 66.0.4-1 FC28 … geht!

Download:

Fedora 28: https://koji.fedoraproject.org/koji/taskinfo?taskID=34672367
Fedora 29: https://koji.fedoraproject.org/koji/taskinfo?taskID=34672363
Fedora 30: https://koji.fedoraproject.org/koji/taskinfo?taskID=34672350

Firefox Bug schaltet Plugins ab

3.UPDATE zum aktuellen Firefox-AddOn-Signing-Problem

\o/ Der Workaround aus Update 1 lässt auch Neuinstallationen wieder zu:

Armagadd-on-2.0 abgewendet 😀

2.UPDATE zum aktuellen Firefox-AddOn-Signing-Problem

Der Discourse Server von Mozilla mit den Infos zum aktuellen Firefoxproblem ist immer noch down bzw. überlastet, aber der Bugtracker ist erreichbar. Da könnt Ihr entnehmen, wenn es wieder „normal“ geht.

Und ich habe gestern, oder wars schon vorgestern, noch über den Umzug von AskFedora zum eigenen Discourseserver erzählt. Soooo belastbar scheinen die nicht zu sein, denn Mozilla kann sich bestimmt einen Cluster davon leisten 😉

1.UPDATE

Man kann doch was machen. In der about:config einfach mal die Signaturenprüfung abschalten:

xpinstall.signatures.required = false

und Firefox neustarten. Im Anschluß sind die Plugins wieder da. Voilà.

Hauptmeldung

Na, heute Morgen auch beim Start von Firefox die Meldung bekommen, daß einige oder alle Plugins nicht mehr zur Verfügung stehen ? Man könnte ihn den Quantum-Bug nennen 🙂

„One or more installed add-ons cannot be verified and have been disabled“

Was ist passiert? Ein Zertifikat für die Plugin und Extentionverwaltung ist abgelaufen und hat damit alle Plugins/Extentions effektiv als Legacy gekennzeichnet. Wer jetzt hofft, daß ein einfach Neuinstallieren der Addons hilft, weit gefehlt. Das führt nur zu weiteren Fehlern.

Wer auf dem Laufenden bleiben will bekommt … „429 Too Many Requests“. genau, die Mozilla Webseiten werden grade mit Anfragen geflutet! \o/ Das Internet im Partymodus!!! Verzweiflung macht sich breit! Die Familienadmins bekommen Anrufe von Leuten, die Sie nicht mal an Weihnachten zu Gesicht bekommen! Wenn Mozilla Mist macht, dann merkt man das richtig!

Mozilla arbeitet an einem Fix, aber bis der verteilt ist, kann es noch eine Weile dauern. Siehe unten.

Impakt

NoScript abgeschaltet! Hacker & Tracker freut Euch! NoScript UMatrix und alle anderen Schutzaddons sind tod!

Was könnt Ihr tun?

Nichts! Laßt es einfach. Das ist von Mozilla verursacht worden, ergo wird es auch dort gelöst.

Infos

Bugtracker: https://bugzilla.mozilla.org/show_bug.cgi?id=1548973
Mozilla Forum: https://discourse.mozilla.org/t/certificate-issue-causing-add-ons-to-be-disabled-or-fail-to-install/39047

merkwürdiger Bug: Fenster springen auf und ab

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

Die Beschreibung

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

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

Ursache

„Thermale Überhitzung durch 8 Stunden Dauerencoden.“

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

Neuer Kernel, neues Glück?

ein kleines Weihnachtswunder

Oh Binärbaum, Oh Binärbaum,
wie verzweigt sind Deine Äste.

Ein kleines Weihnachtswunder hat sich in der Gemeinde zugetragen: Scott Leigh, mein gelegentlicher Erzfeind im Bugzilla ;), hat einen meiner Bugreports ohne Kampf akzeptiert und ein Update bereit gestellt 😀 Danke, Scott 😉

Zieht Euch die Updates für Fedora 28, dem grade hier viel Gescholtenen, einfach auf Koji und ..

cinnamon-4.0.7-1.fc28
cinnamon-screensaver-4.0.3-1.fc28
cinnamon-translations-4.0.2-1.fc28
muffin-4.0.5-1.fc28

installiert Sie mit : dnf update ./muffin*rpm ./cinnamon*rpm

Natürlich funktioniert der Befehl nur dort, wo die RPMs vom Download liegen, aber das wußtet Ihr ja schon 🙂

Ich wünsche Euch noch ein schönes Restweihnachten und einen gemütlichen Jahreswechsel, jetzt ohne Fehlende-icons-im-Toolbar-Problem 😉