Tag Archives: nicht

Lutris 0.5.14: Kein Spiel startet mehr

Posted on by

Da denkt man sich: „Hey ,es ist Sonntagmorgen, laß und ein paar Rote abschießen“ und da startet EVE einfach mal nicht mehr. Schuld ist ein Fehler von Lutris, der sich jetzt rächt.

Lutris 0.5.14: Kein Spiel startet mehr

Heute hat es Lutris 0.5.14 ins Stable geschafft und wurde prompt aktualisiert. Was für ein mieser Start ins Gamerleben an diesem Sonntag 😀 Keins der Spiele hat mehr funktioniert und das nur, weil eine alte Versionen meinte: „och nehmen wir doch den ~/ Shortcut, statt den absoluten Pfad, wie bei allen anderen Pfadangaben“ 🙂

Kurz um, der Fehler ist leicht zu fixen:

cd ./.lutris/games/

dort findet Ihr für jedes Spiel eine Datei mit Endung .yml :

$ cat eve-online-1650280372.yml
game:
arch: win64
exe: /home/<XXXXXXXX>/Games/eve-online/drive_c/EVE/Launcher/evelauncher.exe
prefix: ~/Games/eve-online
system: {}
wine:
version: lutris-fshack-7.2-x86_64

Das <XXXXXXXX> steht für den Benutzernamen von Euch, bei Prefix steht nun nur „~/“ statt „/home/<XXXXXXXX>/“ . Das ändert Ihr mit einem Texteditor Eurer Wahl und schon starten die Spiele wieder.

$ cat eve-online-1650280372.yml
game:
arch: win64
exe: /home/<XXXXXXXX>/Games/eve-online/drive_c/EVE/Launcher/evelauncher.exe
prefix: /home/<XXXXXXXX>/Games/eve-online
system: {}
wine:
version: lutris-fshack-7.2-x86_64

Ihr müßt nur aufpassen, daß ihr Euren Homepfad irgendwann nicht mal ändert, weil sonst all die Config nicht mehr stimmen 😉

 

Pinephone: Fedora Minimal Image z.Z. nicht updaten

Posted on by

Seit einigen Tagen gibt es ein Problem mit dem Pinephone Fedora Minimalimage. Wenn es auf den letzten Stand aktualisiert wird, bootet das Pinephone nicht mehr.

UPDATE: Wer ab 7.4. ca. 20:00 Uhr MESZ updated, der kann wieder ohne Hemmungen updaten. Ich hab das Problem für Euch untersucht und gelöst bekommen 😉 Es war so ein !*ARGS*! Moment 😉 hat jeder mal 😀

Pinephone: Fedora Minimal Image z.Z. nicht updaten

Wenn Ihr noch nicht aktualisiert habt, dann tragt das hier in die /etc/dnf/dnf.conf ein:

exclude=megi-kernel pp-uboot

Danach kann man erst einmal wieder updaten. Falls es für Euch schon zu spät ist, habt Ihr drei Möglichkeiten:

    1. Solange das Pine noch keinen Reboot gemacht hat, könnt Ihr einfach die Pakete downgraden:dnf downgrade megi-kernel-5.12.0-3und dann nehmt Ihr die Pakete oben von weiteren Updates einfach aus.
    2. Das Minimal Image einfach neu installieren, updaten, dann Schritt 1 oben machen und dann megi-kernel von den Updates ausnehmen.
    3. Fedora Workstation Image auf die SDCard schreiben, das booten.
      Ein Terminal aufmachen.
      mount /dev/mmcblk2p2 /mnt/
      chroot /mnt/
      dnf downgrade megi-kernel-5.12.0-3
      exit
      umount /mnt
      reboot

Wobei man natürlich auf dem Workstation Image erstmal das WLAN aktivieren muß, sonst kann man die Pakete nicht laden 😉 Je nach dem wieviel Zeit vergangen ist seit ich den Artikel für Euch geschrieben haben und Ihre das Problem lösen wollte, könnte ein Downgrade nicht mehr nötig sein, sondern ein Update stattdessen die bessere Idee sein.

Da das Problem derzeit im Team besprochen wird, sollte bald ein megi-kernel Paket existieren, daß das Problem löst und die neue gewünschte Funktion hat, die das Ungemach überhaupt erst ausgelöst habt 😉

In jedem Fall ist ein Workstation Image ( ftp://pine.warpspeed.dk/nightly/pinephone/minimal-2021-04-05-test.img.xz ) auf einer SDCard im Pinephone keine so schlechte Idee, weil man dann schnell solche Fehler beheben kann und trotzdem von der EMMC bootet kann, weil es das hier gibt:

Ein ständiges Wechseln der SDCard ist so nämlich nicht mehr nötig. Der Dank geht auch hier an Megi, es war seine ( hoffentlich richtiges Pronomen ) Idee.

TAR und die Symlinks

Posted on by

Von Problemen mit TAR-Backups hört man zum Glück recht selten, heute schauen wir uns mal eines dieser Probleme an: Symlinks.

Wann man Symlinks nicht erhält

Schauen wir uns erstmal an um was es geht. So sieht etc/alternatives aus:

[root@s160 tmp]# ls -la /etc/alternatives/
insgesamt 68
drwxr-xr-x 2 root root 4096 2. Aug 06:22 .
drwxr-xr-x 125 root root 12288 2. Aug 06:25 ..
lrwxrwxrwx 1 root root 39 2. Aug 06:22 cifs-idmap-plugin -> /usr/lib64/cifs-utils/cifs_idmap_sss.so
lrwxrwxrwx 1 root root 25 2. Aug 06:22 ebtables -> /usr/sbin/ebtables-legacy
lrwxrwxrwx 1 root root 37 2. Aug 06:22 ifdown -> /etc/sysconfig/network-scripts/ifdown
lrwxrwxrwx 1 root root 35 2. Aug 06:22 ifup -> /etc/sysconfig/network-scripts/ifup
lrwxrwxrwx 1 root root 26 2. Aug 06:22 ip6tables -> /usr/sbin/ip6tables-legacy
lrwxrwxrwx 1 root root 34 2. Aug 06:22 ip6tables-restore -> /usr/sbin/ip6tables-legacy-restore
lrwxrwxrwx 1 root root 31 2. Aug 06:22 ip6tables-save -> /usr/sbin/ip6tables-legacy-save
lrwxrwxrwx 1 root root 25 2. Aug 06:22 iptables -> /usr/sbin/iptables-legacy
lrwxrwxrwx 1 root root 33 2. Aug 06:22 iptables-restore -> /usr/sbin/iptables-legacy-restore
lrwxrwxrwx 1 root root 30 2. Aug 06:22 iptables-save -> /usr/sbin/iptables-legacy-save
lrwxrwxrwx 1 root root 60 2. Aug 06:22 java -> /usr/lib/jvm/java-11-openjdk-11.0.3.7-1.fc29.x86_64/bin/java
lrwxrwxrwx 1 root root 68 2. Aug 06:22 java.1.gz -> /usr/share/man/man1/java-java-11-openjdk-11.0.3.7-1.fc29.x86_64.1.gz
lrwxrwxrwx 1 root root 59 2. Aug 06:22 jjs -> /usr/lib/jvm/java-11-openjdk-11.0.3.7-1.fc29.x86_64/bin/jjs
lrwxrwxrwx 1 root root 67 2. Aug 06:22 jjs.1.gz -> /usr/share/man/man1/jjs-java-11-openjdk-11.0.3.7-1.fc29.x86_64.1.gz
lrwxrwxrwx 1 root root 51 2. Aug 06:22 jre -> /usr/lib/jvm/java-11-openjdk-11.0.3.7-1.fc29.x86_64
lrwxrwxrwx 1 root root 51 2. Aug 06:22 jre_11 -> /usr/lib/jvm/java-11-openjdk-11.0.3.7-1.fc29.x86_64
lrwxrwxrwx 1 root root 50 2. Aug 06:22 jre_11_openjdk -> /usr/lib/jvm/jre-11-openjdk-11.0.3.7-1.fc29.x86_64
lrwxrwxrwx 1 root root 51 2. Aug 06:22 jre_openjdk -> /usr/lib/jvm/java-11-openjdk-11.0.3.7-1.fc29.x86_64
lrwxrwxrwx 1 root root 63 2. Aug 06:22 keytool -> /usr/lib/jvm/java-11-openjdk-11.0.3.7-1.fc29.x86_64/bin/keytool
lrwxrwxrwx 1 root root 71 2. Aug 06:22 keytool.1.gz -> /usr/share/man/man1/keytool-java-11-openjdk-11.0.3.7-1.fc29.x86_64.1.gz
lrwxrwxrwx 1 root root 34 2. Aug 06:22 libnssckbi.so.x86_64 -> /usr/lib64/pkcs11/p11-kit-trust.so
lrwxrwxrwx 1 root root 45 2. Aug 06:22 libwbclient.so.0.14-64 -> /usr/lib64/samba/wbclient/libwbclient.so.0.14
lrwxrwxrwx 1 root root 23 2. Aug 06:22 mta -> /usr/sbin/sendmail.exim
lrwxrwxrwx 1 root root 19 2. Aug 06:22 mta-mailq -> /usr/bin/mailq.exim
lrwxrwxrwx 1 root root 29 2. Aug 06:22 mta-mailqman -> /usr/share/man/man8/exim.8.gz
lrwxrwxrwx 1 root root 24 2. Aug 06:22 mta-newaliases -> /usr/bin/newaliases.exim
lrwxrwxrwx 1 root root 15 2. Aug 06:22 mta-pam -> /etc/pam.d/exim
lrwxrwxrwx 1 root root 19 2. Aug 06:22 mta-rmail -> /usr/bin/rmail.exim
lrwxrwxrwx 1 root root 19 2. Aug 06:22 mta-rsmtp -> /usr/bin/rsmtp.exim
lrwxrwxrwx 1 root root 18 2. Aug 06:22 mta-runq -> /usr/bin/runq.exim
lrwxrwxrwx 1 root root 22 2. Aug 06:22 mta-sendmail -> /usr/lib/sendmail.exim
lrwxrwxrwx 1 root root 63 2. Aug 06:22 pack200 -> /usr/lib/jvm/java-11-openjdk-11.0.3.7-1.fc29.x86_64/bin/pack200
lrwxrwxrwx 1 root root 71 2. Aug 06:22 pack200.1.gz -> /usr/share/man/man1/pack200-java-11-openjdk-11.0.3.7-1.fc29.x86_64.1.gz
lrwxrwxrwx 1 root root 60 2. Aug 06:22 rmid -> /usr/lib/jvm/java-11-openjdk-11.0.3.7-1.fc29.x86_64/bin/rmid
lrwxrwxrwx 1 root root 68 2. Aug 06:22 rmid.1.gz -> /usr/share/man/man1/rmid-java-11-openjdk-11.0.3.7-1.fc29.x86_64.1.gz
lrwxrwxrwx 1 root root 67 2. Aug 06:22 rmiregistry -> /usr/lib/jvm/java-11-openjdk-11.0.3.7-1.fc29.x86_64/bin/rmiregistry
lrwxrwxrwx 1 root root 75 2. Aug 06:22 rmiregistry.1.gz -> /usr/share/man/man1/rmiregistry-java-11-openjdk-11.0.3.7-1.fc29.x86_64.1.gz
lrwxrwxrwx 1 root root 31 2. Aug 06:22 spf -> /usr/bin/spfquery.perl-Mail-SPF
lrwxrwxrwx 1 root root 27 2. Aug 06:22 spf-daemon -> /usr/bin/spfd.perl-Mail-SPF
lrwxrwxrwx 1 root root 47 2. Aug 06:22 spfquery-man-page -> /usr/share/man/man1/spfquery-perl-Mail-SPF.1.gz
lrwxrwxrwx 1 root root 65 2. Aug 06:22 unpack200 -> /usr/lib/jvm/java-11-openjdk-11.0.3.7-1.fc29.x86_64/bin/unpack200
lrwxrwxrwx 1 root root 73 2. Aug 06:22 unpack200.1.gz -> /usr/share/man/man1/unpack200-java-11-openjdk-11.0.3.7-1.fc29.x86_64.1.gz
lrwxrwxrwx 1 root root 15 2. Aug 06:22 whois -> /usr/bin/jwhois
lrwxrwxrwx 1 root root 37 2. Aug 06:22 whois-man -> /usr/share/man/man1/whois.jwhois.1.gz

In dem Verzeichnis schreiben Pakete Symlinks zu Programmen rein, die es im System doppelt gibt. Z.B.: OpenJDK mit Java 8 und Java 11 . Das Paket, welches zuletzt installiert oder aktualisiert wird, nagelt dort die Symlinks über. (Anm. so bin ich überhaupt erst zum Thema gekommen 😉 ).

Wenn man jetzt die Symlinks vor der „Katastrophe“ wieder haben will, entpackt man sein Systembackup. Weil /etc weit vorne im Archiv steht und so ein Backup auch schon mal 80-100 GB haben kann, bricht man i.d.R. ab, wenn tar -xvzf archiv.tgz etc/alternatives keine Ausgaben mehr macht, weil der Verzeichnispfad dann „durch“ ist. So spart man sich viiiieeel Zeit, oder auch nicht 🙂

Weil, wenn man dann in das Verzeichnis schaut sieht man das hier:

[root@s160 tmp]# ls -ls etc/alternatives/
insgesamt 0
0 ---------- 1 root root 0  2. Aug 09:30 cifs-idmap-plugin
0 ---------- 1 root root 0  2. Aug 09:30 ebtables
0 ---------- 1 root root 0  2. Aug 09:30 ifdown
0 ---------- 1 root root 0  2. Aug 09:30 ifup
0 ---------- 1 root root 0  2. Aug 09:30 ip6tables
0 ---------- 1 root root 0  2. Aug 09:30 ip6tables-restore
0 ---------- 1 root root 0  2. Aug 09:30 ip6tables-save
0 ---------- 1 root root 0  2. Aug 09:30 iptables
0 ---------- 1 root root 0  2. Aug 09:30 iptables-restore
0 ---------- 1 root root 0  2. Aug 09:30 iptables-save
0 ---------- 1 root root 0  2. Aug 09:30 java
0 ---------- 1 root root 0  2. Aug 09:30 ld
0 ---------- 1 root root 0  2. Aug 09:30 libnssckbi.so.x86_64
0 ---------- 1 root root 0  2. Aug 09:30 libwbclient.so.0.14-64
0 ---------- 1 root root 0  2. Aug 09:30 mta
0 ---------- 1 root root 0  2. Aug 09:30 mta-mailq
0 ---------- 1 root root 0  2. Aug 09:30 mta-mailqman
0 ---------- 1 root root 0  2. Aug 09:30 mta-newaliases
0 ---------- 1 root root 0  2. Aug 09:30 mta-pam
0 ---------- 1 root root 0  2. Aug 09:30 mta-rmail
0 ---------- 1 root root 0  2. Aug 09:30 mta-rsmtp
0 ---------- 1 root root 0  2. Aug 09:30 mta-runq
0 ---------- 1 root root 0  2. Aug 09:30 mta-sendmail
0 ---------- 1 root root 0  2. Aug 09:30 spf
0 ---------- 1 root root 0  2. Aug 09:30 spf-daemon
0 ---------- 1 root root 0  2. Aug 09:30 spfquery-man-page
0 ---------- 1 root root 0  2. Aug 09:30 whois
0 ---------- 1 root root 0  2. Aug 09:30 whois-man

Das schockt, oder? Keine Symlinks mehr, nur noch leere Files mit 0 Byte Größe.

Was tun????

Vielleicht Man-Page lesen? Viel Spaß beim Suchen, keine Chance 🙂 Da findet sich nur dies:

-h, –dereference
Follow symlinks; archive and dump the files they point to.

Das macht TAR eh von alleine, … sagt man.  Probierts aus, ob Ihr -h im Extract drin habt oder nicht, spielt keine Rolle. Die Ursache liegt in einem kleinen Erwartungsproblem: Man erwartet, daß sobald eine Datei aus dem Archiv extrahiert wurde, diese im Filesystem auch mit allen Infos wie UID/GID, Filerechten vorhanden ist.

Da tickt tar aber leider etwas merkwürdig. Es macht das erst, wenn das Backup komplett durchlaufen wurde.

Lösung

Die Lösung lautet: Durchlaufen lassen!

Danach stimmt alles wieder, so wie man das erwarten würde. Machmal sind Lösung auch trivial. Das es im Einzelfall dann 100GB per Netzwerk sind, ist dann halt so, wenn man alles in ein Backupfile schreibt.