Weder Digikam, als auch Showphoto bringen beim Starten keine Fehlermeldung, starten aber auch nicht
Hier startet digikam.
Allerdings die Version aus KDE-Extra.
zypper se -si digikam
zypper lr -d
Außerdem würd ich digikam bzw. showfoto mal in Konsole oder xterm aufrufen.
Eventuell gibts dort eine hilfreiche Fehlermeldung… 
Es kommt die Fehlermeldung:
digikam: error while loading shared libraries: libgomp.so.1: cannot open shared object file: Permission denied
Allerdings existiert diese Datei systemweit nicht und der Versuch, libgomp1 zu installieren schlägt leider fehl :’(
Und inwiefern schägt es fehl? Wir sind hier auch keine Hellseher.
Installieren sollte aber sowieso nicht notwendig sein, denn sie sollte automatisch installiert worden sein.
Außerdem existiert sie scheinbar schon, sonst wäre die Fehlermeldung “Datei nicht gefunden”…
“Permission denied” heißt aber dass du keine Rechte hast darauf zuzugreifen.
Was sagt denn:
ls -l /usr/lib64/libgomp*
Das fehlt auch noch.
Zuerst mal SORRY an die Community für meine langen Reaktionszeiten und SORRY an Sauerland, daß ich diese Lösung nicht weiter verfolgt habe (das Problem hätte sich dadurch nicht gelöst). Ich bin leider fast ständig im Ausland (teils ohne Internet) und habe momentan auch wenig Zeit.
ls -l /usr/lib64/libgomp*
bringt folgende Liste (und das ist auch das eigentliche Problem):
pc22:/usr/lib64 # ll libgomp*
lrwxrwxrwx 1 root root 27 18. Mär 19:07 libgomp-plugin-hsa.so.1 → libgomp-plugin-hsa.so.1.0.0
-rwxr-xr-x 1 root root 30944 9. Mär 22:57 libgomp-plugin-hsa.so.1.0.0
lrwxrwxrwx 1 root root 29 18. Mär 19:07 libgomp-plugin-nvptx.so.1 → libgomp-plugin-nvptx.so.1.0.0
-rwxr-xr-x 1 root root 30880 9. Mär 22:57 libgomp-plugin-nvptx.so.1.0.0
lrwxrwxrwx 1 root root 25 19. Mär 09:57 libgomp.so.1 → libgomp.so.1.0.0;5aaeaaf1
-rwxr-xr-x 1 root root 65630 -4130033806880825322 libgomp.so.1.0.0
---------- 1 root root 195880 18. Mär 19:06 libgomp.so.1.0.0;5aaeaac1
---------- 1 root root 195880 18. Mär 19:07 libgomp.so.1.0.0;5aaeaadd
---------- 1 root root 195880 18. Mär 19:07 libgomp.so.1.0.0;5aaeaaf1
pc22:/usr/lib64 #
Bei dieser Ausgabe ist zu beachten, daß meine momentane “Problemlösung” darin enthalten ist.
Bei der automatischen Installation von libgomp1 ist offensichtlich etwas schief gelaufen, das sich leider auch nicht durch Deinstallation und Installation beheben läßt:
Die 3 Dateien libgomp.so.1.0.0;5aae* sind ohne Rechte und lassen sich weder löschen noch umbenennen; mit Rechten versehen geht auch nicht.
Meine “Problemlösung” sieht so aus, daß ich einen symbolischen Link auf eine dieser Dateien gesetzt habe, da diese zwar keine Rechte und einen falschen Namen hat, aber inhaltlich korrekt ist.
(Die Mehrfachausgabe der Schrottdatei stammt aus den Installationsversuchen).
So habe ich jetzt zwar Digikam korrekt am Laufen, aber ein unsauberes Betriebssystem, das sich bestimmt bei Updates rächt.
Diese Dateien gibt es in der Tat nur wenn beim Installieren/Updaten des Pakets was schief läuft.
Hintergrundinfo: rpm legt zuerst mal diese Dateien an, erst wenn alles erfolgreich erledigt ist werden sie zu den richtigen Dateien umbenannt.
Gibts irgendeine Fehlermeldung, wenn du eine Neuinstallation des Pakets forcierst?
sudo zypper in -f libgomp1
Kleine Ergänzung vorweg:
die unnötigen Schrottdateien konnte ich (natürlich :?) löschen durch ;
Was sich nicht löschen läßt, ist die (inhaltlich falsche) libgomp.so.1.0.0 wegen des falschen Zeitstempels.
Ja, hab ich gerade probiert:
Das folgende NEUE Paket wird installiert:
libgomp1
1 neues Paket zu installieren.
Gesamtgröße des Downloads: 0 B. Bereits im Cache gespeichert: 104,7 KiB. Nach der Operation werden
zusätzlich 251,7 KiB belegt.
Fortfahren? [j/n/…? zeigt alle Optionen] (j): j
Im Cache libgomp1-7.3.1+r258313-6.1.x86_64.rpm (1/1), 104,7 KiB (251,7 KiB entpackt)
Überprüfung auf Dateikonflikte läuft: …[fertig]
(1/1) Installieren: libgomp1-7.3.1+r258313-6.1.x86_64 …[Fehler]
Installation von libgomp1-7.3.1+r258313-6.1.x86_64 fehlgeschlagen:
Fehler: Subprocess failed. Error: RPM fehlgeschlagen: error: unpacking of archive failed on file /usr/lib64/libgomp.so.1.0.0: cpio: rename failed - Operation not permitted
error: libgomp1-7.3.1+r258313-6.1.x86_64: install failed
Abbrechen, wiederholen, ignorieren? [a/w/i] (a):
Was heißt das genau (“wegen des falschen Zeitstempels”)?
Installation von libgomp1-7.3.1+r258313-6.1.x86_64 fehlgeschlagen:
Fehler: Subprocess failed. Error: RPM fehlgeschlagen: error: unpacking of archive failed on file /usr/lib64/libgomp.so.1.0.0: cpio: rename failed - Operation not permitted
error: libgomp1-7.3.1+r258313-6.1.x86_64: install failed
Hm, möglicherweise ein Filesystem Fehler?
Die gepostete Ausgabe vom ls lässt eigentlich auch schon darauf schliessen:
-rwxr-xr-x 1 root root 65630 -4130033806880825322 libgomp.so.1.0.0
Was sagt denn “dmesg|tail” nach Aufruf dieses zypper Befehls?
Evtl. hilft ein fsck?
Bitte ignorieren, ist mittlerweile ohnehin klar…
Das ist genau der Zeitstempelfehler:
anstatt “-4130033806880825322” müßte da “9. Mär 22:57” stehen.
Ja.
Und wie geschrieben, das deutet meiner Meinung nach sehr stark auf ein beschädigtes Dateisystem hin…
Gibt es keine Möglichkeit, den Zeitstempel zu setzen? touch funktioniert jedenfalls auch unter root nicht. Bei fsck bräuchte ich auch Hilfe, weil es zu meiner Zeit als Systemverwalter für UNIX (vor 30 Jahren) diese ganzen Dateisystemarten noch nicht gab. (Außerdem bin ich eigentlich seit ca. 20Jahren nicht mehr im Thema).
Das Problem ist nicht der falsche Zeitstempel, das ist nur ein Symptom (für fehlerhafte Daten im Verzeichniseintrag).
Wie gesagt, der meiner Meinung nach wahrscheinlichste Grund ist ein fehlerhaftes Dateisystem (oder schadhafte Sektoren auf der Festplatte), wodurch auch ein Ändern der Datei-Metadaten (also z.B. ein Ändern des Zeitstempels) verhindert wird.
Bei fsck bräuchte ich auch Hilfe, weil es zu meiner Zeit als Systemverwalter für UNIX (vor 30 Jahren) diese ganzen Dateisystemarten noch nicht gab. (Außerdem bin ich eigentlich seit ca. 20Jahren nicht mehr im Thema).
fsck ist fsck, da ists eigentlich egal was für ein Dateisystem verwendet wird. (obwohls manchmal notwendig ist ein spezifisches Tool zu verwenden, also wärs evtl. schon hilfreich zu wissen was für die Rootpartition verwendet wurde… ).
fsck -fp /dev/sda1
(die Partition natürlich entsprechend anpassen!)
Allerdings wirst du die Systempartition nicht reparieren können solange sie in Verwendung ist. Am besten von einer LiveCD booten, bzw. die “rd.break” Bootoption sollte den Boot abbrechen bevor etwas gemountet wird.
Du könntest auch probieren die Datei (/usr/lib64/libgomp.so.1.0.0 ) manuell zu löschen oder umbenennen bevor du libgomp1 neu installierst, aber das wird vermutlich auch nicht gehen.
Evtl. könnte es Abhilfe schaffen den übergeordneten Ordner zu löschen, aber im Fall von /usr/lib64/ ist das nicht wirklich ratsam.
Das “libgomp1” Paket ist für gcc7 – ich habe hier (ich weiß noch nicht warum) “libgomp1-gcc6” installiert:
> cat /etc/os-release
NAME="openSUSE Leap"
VERSION="42.3"
ID=opensuse
ID_LIKE="suse"
VERSION_ID="42.3"
PRETTY_NAME="openSUSE Leap 42.3"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:leap:42.3"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"
>
> rpm --query --whatprovides libgomp1
libgomp1-gcc6-6.2.1+r239768-6.19.x86_64
> rpm --query --list libgomp1-gcc6
/usr/lib64/libgomp-plugin-hsa.so.1
/usr/lib64/libgomp-plugin-hsa.so.1.0.0
/usr/lib64/libgomp.so.1
/usr/lib64/libgomp.so.1.0.0
>
> ls -ld /usr/lib64/
drwxr-xr-x 166 root root 212992 8. Apr 18:24 /usr/lib64/
>
> ls -l /usr/lib64/libgomp*
lrwxrwxrwx 1 root root 27 22. Nov 16:47 /usr/lib64/libgomp-plugin-hsa.so.1 -> libgomp-plugin-hsa.so.1.0.0
-rwxr-xr-x 1 root root 26912 7. Jul 2017 /usr/lib64/libgomp-plugin-hsa.so.1.0.0
lrwxrwxrwx 1 root root 16 22. Nov 16:47 /usr/lib64/libgomp.so.1 -> libgomp.so.1.0.0
-rwxr-xr-x 1 root root 195920 7. Jul 2017 /usr/lib64/libgomp.so.1.0.0
>
“libgomp1-gcc48” ist auch nicht korrekt:
# zypper install libgomp1-gcc48
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...
Paketabhängigkeiten werden aufgelöst...
Problem: libgomp1-gcc6-6.2.1+r239768-6.19.x86_64 steht in Konflikt mit libgomp1, das von libgomp1-gcc48-4.8.5-24.18.x86_64 zur Verfügung gestellt wurde
Lösung 1: Folgende Aktionen werden ausgeführt:
Deinstallation von libgomp1-gcc6-6.2.1+r239768-6.19.x86_64
Downgrade von gcc48-4.8.5-32.1.x86_64 zu gcc48-4.8.5-24.18.x86_64
Downgrade von gcc48-c++-4.8.5-32.1.x86_64 zu gcc48-c++-4.8.5-24.18.x86_64
Downgrade von cpp48-4.8.5-32.1.x86_64 zu cpp48-4.8.5-24.18.x86_64
Downgrade von libstdc++48-devel-4.8.5-32.1.x86_64 zu libstdc++48-devel-4.8.5-24.18.x86_64
Lösung 2: libgomp1-gcc48-4.8.5-24.18.x86_64 nicht installieren
Wählen Sie aus den obigen Lösungen mittels Nummer oder brechen Sie (a)b [1/2/a] (a): 2
Abhängigkeiten werden aufgelöst...
Paketabhängigkeiten werden aufgelöst...
Keine auszuführenden Aktionen.
#
Irgend wie, habe ich der Eindruck dass, Leap 15 wird gcc7 verwenden …
Es geht hier aber nicht um das Paket libgomp1, sondern um die Datei /usr/lib64/libgomp.so.1 (die unter anderem im Paket libgomp1 enthalten ist, und von digikam benötigt wird).
libgomp1(-gcc*) hat aber absolut keine Abhängigkeit zu einer bestimmten gcc Version, sie ist halt eben nur bei gcc dabei.
Das -gcc48 bzw. -gcc6 ist deshalb im Paketnamen, damit sie von rpm/zypper unterschieden werden können.
– ich habe hier (ich weiß noch nicht warum) “libgomp1-gcc6” installiert:
Ich nicht.
Kann aber damit zusammenhängen welche anderen Pakete installiert sind und von wo oder sogar wann, bzw. welche Updates installiert wurden oder nicht.
libgomp1 ist jedenfalls die aktuellste Version die in Leap 42.3 verfügbar ist, und die einzige im Update repo (existiert dort aber erst seit November)
“libgomp1-gcc48” ist auch nicht korrekt:
Das wurde mit einem Update durch libgomp1-gcc6 bzw. libgomp1 ersetzt.
Irgend wie, habe ich der Eindruck dass, Leap 15 wird gcc7 verwenden …
Das ist in der Tat so, aber ebenfalls irrelevant hier.
Übrigens, auch in Leap 42.3 ist gcc7 enthalten, allerdings wird 4.8 als Default benutzt.
In 15.0 gibts aber nur mehr gcc7, genau wie in Tumbleweed.
So, jetzt hab ich eine Lösung gefunden, mit der ich bis auf Weiteres leben kann:
Ich habe ein neues Verzeichnis /usr/lib64NEU erstellt und den gesamten Inhalt von /usr/lib64, mit Ausnahme der Schrottdatei libgomp.so.1.0.0, reinkopiert. Dann /usr/lib64 in /usr/lib64.ALT umbenannt. Nun /usr/lib64NEU nach /usr/lib64 und neu gebootet. Jetzt nur noch den ganzen Inhalt von /usr/lib64.ALT löschen (mit Ausnahme der Schrottdatei).
Jetzt ist nur noch der beschädigte Platz mit 64kb belegt.
Bezüglich der Partition mit ‘/usr/lib64/’ drauf und das Thema “fehlerhafter Block”: was sagte ‘fsck’, bzw. ‘btrfs check’, bzw. ‘xfs_repair’ dazu?
Das kann ich z.Zt. leider nicht ausprobieren, weil mein Notebook (Acer Aspire) nicht auf ner DVD oder USB starten mag. Läßt sich leider auch nicht einstellen (???)