Category Archives: Fedora

g..g..gi…gi..git…gitolite!

Posted on by

Ok, sehr dramatischer Titel, ich gebs zu 🙂 Gitolite kennt der ein oder andere Entwickler sicher, weil man damit auf seinem eigenen Server Git Repos nutzen kann, was auch gern benutzt wird.

g..g..gi…gi..git…gitolite!

Nun ist gitolite keine neue Erfindung, sondern schon eine Weile alt. So alt, daß es schon seit 2017 gitolite3 gibt. Gitolite(2)  wurde dagegen eingestellt, weil es EOL hatte. Fedora stellt daher dafĂŒr keine Pakete mehr zur VerfĂŒgung und installiert ersatzweise gitolite3.

„Das ist blöd!“ stellten wir nach einem Serverupgrade fest, da das Paket gitolite(2) beim Löschen 6 GB Projektdaten mit ins Nirvana gezogen hatte, da diese im Homedir liegen.. dachten wir. Zum GlĂŒck hatten wir eine Anpassung fĂŒr Chroots gemacht, so daß nur der Link auf das Homedir gelöscht wurde, aber die Daten noch in der Chroot lagen. Wir hĂ€tten natĂŒrlich auch ein Backup gehabt, aber so war es noch einfacher.

„Bekomme es wieder zum Laufen…“

Etwas schwieriger gestaltete sich die Reinstallation unter Fedora 31, da sich zwischenzeitlich Perl von 5.28 auf 5.30 geÀndert hatte, und gitolite Paket aber unbedingt 5.28 haben wollte. Nun ja, Perl 5.30 zu entfernen kam nicht in Frage, also riskierten wir es und installierten gitolite ohne AbhÀngigkeiten:

rpm -i –nodeps https://kojipkgs.fedoraproject.org//vol/fedora_koji_archive04/packages/gitolite/2.3.1/18.fc29/noarch/gitolite-2.3.1-18.fc29.noarch.rpm

Zum GlĂŒck funktioniert gitolite 2.3.1 auch mit Perl 5.30 bislang ohne Fehler, so daß erstmal weiter gearbeitet werden kann. Es ist nĂ€mlich durchaus ein mĂ€chtiges StĂŒck Arbeit, von Gitolite2 auf Gitolite3 umzusteigen, wie die Migrationsanweisung zeigt. Daher hat der Betroffene nun gleich Gitlab ins Auge gefasst. Mal sehen wie das wird 😉

 

Fedora: Installationsprozess korrumpiert den Speicher

Posted on by

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!

Wine: Die SSD schonen

Posted on by

Ihr wollt mit Wine Spiele spielen, aber Eure SSD nicht unnötig belasten? Da könnte man was machen.

Wine: Die SSD schonen

Wer auf Linux Windows Spiele zocken möchte, der kommt um Wine nicht herum. Egal in welcher Form, es ist immer irgendwie beteiligt. Leider bedeutet das auch, daß Eure SSD alleine durchs Loggen von Debuginfos belastet wird. So eine Runde WOW kann da die Lebenszeit der SSD richtig dezimieren:

# grep fixme /var/log/messages |grep „Jun 28“ | grep -c fixme
711541

meint, am 28.Juni wurden ins Logfile 711.541 Zeilen von Wine geschrieben, fast alle mit dem gleichen, leeren Inhalt:

Jun 28 10:08:21 xxx /usr/libexec/gdm-x-session[2227]: 009e:fixme:rawinput:GetRawInputBuffer data (nil), data_size 0x22f7b0, header_size 24 stub!

Von den 711k Logzeilen macht die obige Zeile 708k aus, ohne Mehrwert fĂŒr den User. Rechnet Euch mal aus, wieviele das ĂŒbers Jahr sind!

Wie bekommt man das jetzt weg?

Zum GlĂŒck ist das einfach in der .desktop Datei vom jeweiligen Wine-Spiel zu lösen(hier WOW):

Ändert die Exec Zeile von so:

Exec=env WINEPREFIX=“/home/<username>/.wine“ /opt/wine-staging/bin/wine64 C:\\\\windows\\\\command\\\\start.exe /Unix /home/<username>/.wine/dosdevices/c:/Program\\ Files\\ (x86)/World\\ of\\ Warcraft/_retail_/Wow.exe

in so um:

Exec=env WINEPREFIX=“/home/<username>/.wine“ WINEDEBUG=-all /opt/wine-staging/bin/wine64 C:\\\\windows\\\\command\\\\start.exe /Unix /home/<username>/.wine/dosdevices/c:/Program\\ Files\\ (x86)/World\\ of\\ Warcraft/_retail_/Wow.exe

Danach ist Ruhe im Logfile und rsyslogd bzw. journald werden Euch danken, denn:

Jun 28 16:38:51 XXXXXXX rsyslogd[1506]: imjournal: 180769 messages lost due to rate-limiting (20000 allowed within 600 seconds)
Jun 28 16:48:52 XXXXXXX rsyslogd[1506]: imjournal: 180635 messages lost due to rate-limiting (20000 allowed within 600 seconds)
Jun 28 16:58:58 XXXXXXX rsyslogd[1506]: imjournal: 103949 messages lost due to rate-limiting (20000 allowed within 600 seconds)

das, was grep da gezĂ€hlt hat, ist nur das, was im Logfile auch angekommen ist. In Wirklichkeit sind da tonnenweise Logzeilen weg gefiltert worden und trotz dessen waren es am Ende noch 711k ! Das mĂŒssen mehrere Millionen Zeilen gewesen sein, an nur einem einzigen Tag!

„Warum ist das nicht die Defaulteinstellung?“ wĂŒrde man zurecht fragen, aber solange nur beim Start mal kurz was wichtiges geloggt wird, ok, aber 708.010x das eine 3D-Routine gefixt werde mĂŒĂŸte?? Also da könnte man auch mal ĂŒber sinnvolleres Loggen nachdenken, oder?