Beiträge von Suelkun

Hallo,

ich habe eben die openSUSE Version vmlinuz-5.3.18-150300.59.60-default per automatischem update erhalten. Gleichzeitig habe ich die Aufforderung erhalten, das System neu zu starten, damit die Aktualisierungen wirksam werden können.

Nun gut, ich nicke die Aktualisierung ab und versuche nach dem Download, das System neu zu starten. Um es kurz zu machen: vmlinuz-5.3.18-150300.59.60-default kommt bei mir nicht hoch.

Ich kann mir natürlich helfen, starte eben wieder die Vorversion vmlinuz-5.3.18-150300.59.54-default, die einwandfrei hochkommt. Aber irgendwie ist bei openSUSE 15.3 und dessen Aktualisierungszyklen seit einiger Zeit für mich irgendwie der Wurm drin.

Ich benutze openSUSE seit (gefühlt) 10-20 Jahren, vielleicht sogar noch länger. Dabei habe ich natürlich haufenweise Aktualisierungen mitgemacht, auch des Kernels. Aber solche Umstände, wie unter 15.3 mußte ich noch nie mitmachen, das ist neu.

Praktisch jeden zweiten neuen Kernel muß ich überspringen, weil entweder meine Grafikkarte nicht tut (d.h. der Rechner startet zwar, aber ich sehe nichts) oder der Kernel beim Starten hängenbleibt oder (was auch schon vorgekommen ist): ein neuer Kernel gar nicht übernommen werden kann, weil er in Konflikt steht mit was anderem.

Zitat von matbhm

Du müsstest ja das Verzeichnis zu den Bildern über /user/home/ finden können. Den Pfad müsstest Du dann ja Digikam vermitteln können!

Ich genau das ist das Problem: Erst einmal sehe ich in digikam alle Vorschaubilder. D.h. digikam hat entweder die Vorschaubilder in einer eigenen Datenbank (unabhängig von den realen Bildern)) oder digikam erstellt diese Vorschaubilder jedesmal an Hand der realen Bilder (hat dann also doch Zugriff).

Es ist nicht so, daß die Bilder nicht mehr zugänglich wären. Mit Dolphin kann ich sie sehen und mit genview kann ich sie öffnen. Das ist nicht das Problem. Nur die Verwaltung der Bilder mit digikam funktioniert nicht mehr richtig

Die Bilder sind auch nicht in meinem home-Verzeichnis abgelegt, sondern im Unterverzeichnis eines anderen Wurzelverzeichnisses als home/user/. An dieser Ablagestruktur hat sich rein gar nichts geändert.

Also meine Frage: Wie bringe ich digikam bei, wo die Bilder stehen? Ich sehe sogar die SQLLite -Datenbank von digikam.

Die Bilder liegen lokal auf dem Rechner.

Das Verzeichnis ist möglicherweise auch schon mal umgezogen, weil ich immer mal wieder andere Laufwerke einbinde wg. schnellerer Technologie und so. Ader die Bilder ziehen in einem solchen Fall aber immer gemeinsam mit dem ganzen drumherum um. D.h. der Ordner X im Stammverzeichnis zieht gemeinsam mit allen darin enthaltenen Daten um, d.h. wird dann über /etc/fstab auf einem anderen Laufwerk gemounted. Davon sollten die Applikationen selbst nach meinem Verständnis aber nichts mitbekommen.

Ich weiß nicht, wo sonst die Vorschaubilder herkommen. Die sind nämlich alle da.

Das mit dem Löschen des Caches probiere ich gerne aus. Wo steht diese? Bei den Bildern kann sie nicht finden, in meinem home-Verzeichnis auch nicht.

Hallo,

ich verwende openSUSE 15.3 (regelmäßig aktualisiert) und digikam 7.1.0.

Ich muß zugeben, daß ich mir meine Photosammlung (ca. 20k Bilder, meist jpeg) schon länger nicht mehr angeschaut habe. Heute war es wieder mal so so weit, daß ich in die Sammlung reinschauen wollte.

Ich habe also digikam gestartet. Dabei sehe ich zwar alle Sammlungen und auch die Vorschau der zugehörigen Bilder. Wenn ich aber auf ein bestimmtes Photo klicke, um es größer darzustellen, erhalte ich die Meldung "Der Speicherort dieses Bildes ist zur Zeit nicht verfügbar".

Starte ich digikam über die Konsole, dann erhalte ich folgende Meldungen:

>digikam
kf.i18n: KCatalog being used without a Q*Application instance. Some translations won't work
QtAV 1.13.0(Apr 02 2020, 16:55)
Multimedia framework base on Qt and FFmpeg.
Distributed under the terms of LGPLv2.1 or later.
Shanghai, China Copyright (C) 2012-2019 Wang Bin (aka. Lucas Wang) wbsecg1@gmail.com
Donate: http://qtav.org/donate.html
Source: https://github.com/wang-bin/QtAV
Home page: http://qtav.org
capi::version: 0.6.0
Cannot connect to server socket err = Datei oder Verzeichnis nicht gefunden
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
kf.xmlgui: Unhandled container to remove : Digikam::DigikamApp

An welcher Schraube muß ich da drehen?

Mit dem heutigen update auf den Kernel 5.3.18-150300.59.54-default wurde meine Grafikkarte Radeon HD6450 wieder in den Kreis der Grafikkarten aufgenommen, die das aktuelle openSUSE ausführen dürfen.

Sprich: Durch das update hat sich meine Meldung erledigt.

Zitat von Alero

Hast du es mal mit einem Kernel aus dem kernel Stable Repo versucht?

Nein, meine bisherige Strategie war "Aushalten".

Viele Optionen habe ich leider nicht. Ich benutze zusätzlich noch ein Dokumentenmanagement-System, welches nur unter Windows läuft, d.h. ich betreibe nebenbei VMware und dieses hat auch ein paar Randbedingungen, d.h. läuft nicht auf allen Distributionen, bzw. deren Seitenentwicklungszweigen.

Ich habe vor einigen Monaten versucht, eine neue lüfterlose Grafikkarte zu erwerben, um die alte Grafikkarte abzulösen. Vielleicht ist diese ja inzwischen doch zu alt und zu selten, um wirklich wichtig zu sein. Leider konnte mir da der Computerladen nichts bieten und im Internet habe ich auch nichts gefunden.

Zitat von Alero

Dann setze den Rechner zurück auf einen Kernel, der funktioniert und sperre den dann in den Repos. Punkt. Abwarten, bis sich die Sache beruhigt hat und ein funktionierender Kernel vorliegt. Ganz einfach. Man muss nicht immer neuesten Kram haben wollen.

Das werde ich wohl jetzt tun. Ich werde abwarten, bis wieder ein funktionierender Kernel kommt und den dann sperren.

Längerfristig werde ich wohl auf einen Prozessor mit integrierter Grafik setzen. Auf einem Testsystem habe ich OpenSUSE 15.4 Alpha mit einem Ryzen 5 5600G am Laufen und das sieht ganz gut aus. Bis allerdings dann auch VMware unter 15.4 läuft, wird es wahrscheinlich noch eine Zeitlang dauern.

Hallo, tut mir leid, daß ich mich mit dem og. Thema wieder melden muß.

Nachdem ich - über die automatische Aktualisierung- das Kernel Upgrade von 5.3.18--59-40-default auf 5.3.18-150300.59.43-default erhalten und den Rechner neu gestartet habe, lief nichts mehr. Ich hatte den Fehler in einem früheren Post gemeldet.

Vor ein paar Tagen kam dann 5.3.18-150300.59.46 default, der wieder lief. Ich habe mich natürlich gefreut und benutze diesen Kernel für die paar Tage zwischendurch ohne Störungen.

Heute kam, ebenfalls über die automatische Aktualisierung, die Kernel Version 5.3.18-150300.59.49 default. Nach dem erforderlichen Neustart läuft mein System wieder nicht mehr.

Also ich weiß nicht: Irgendwie traute ich mich nicht mehr richtig, ein Update einzuspielen. Gut, ich komme im Moment schon klar, aber ich habe besseres zu tun, als die Startsequenz immer wieder anzupassen. Irgendwie bekomme ich so langsam auch ein mulmiges Gefühl dabei, weil ich den Rechner wirklich brauche.

Frage: Wieviele Kernelversionen sollte ich denn aufbewahren, damit mindestens eine dabei ist, die läuft?

Mein Problem ist gelöst.

Ich hatte es zunächst so gemacht, daß ich die Wartezeit von Grub von 3 sec auf 8 sec hochgesetzt habe. Zu einem Eingriff in den Boot-Vorgang waren die eingestellten 3 sec doch ein wenig kurz.

Als nächstes habe ich Grub so konfiguriert, daß Grub standardmäßig den 40-er-Kernel anstartet (der funkionierte ja mit meiner Grafikkarte).

Und dann habe ich gewartet.

Zwischendurch kam eine Aktualisierung, die bei mir schon beim Versuch der Übernahme auf einen Fehler lief: "SLE-15.3-2022-340-1 noarch conflicts with kernel-default base x86_64"

Gerade eben kam jetzt der Kernel "5.3.18-150300.59.46-default" über die automatische Aktualisierung rein. Nach Neustart und Anwahl dieses Kernels in Grub kommt openSUSE einwandfrei hoch und unterstützt meine Grafikkarte auch.

Ich schließe dieses Thema deshalb

Zitat von Alero

Hab jetzt nur Quer gelesen, aber ... wie Updatest du?

Na ja, halt die automatische Aktualisierung eingeschaltet.

Die meldet sich dann halbwegs regelmäßig damit, daß (eine oder gleich mehrere) Aktualisierung(en) anstehen. Wenn es mir paßt, dann nicke ich das ab und die Aktualisierung beginnt.

In der Regel läuft das auch völlig problemlos. Manchmal meldet sich dann auch der Update-Prozess damit, daß irgendwas an dem Update nicht paßt.

Und manchmal (selten, aber es passiert) erhalte ich dann ein System, welches dann nicht läuft.

Zitat von Sauerland

Oder den Kernel aus SLE installieren, oder einfach das radeon.ko aus dem alten in den nicht funktionierenden Kernel kopieren, steht beides im Bugreport.

glaube leider nicht, daß es wirklich so einfach ist, "radeon.ko" übernehmen.

Ich habe es jedenfalls eben versucht nach dem Strickmuster, welches bei dem ähnlichen Fehler unter 15.2 damals geholfen hat.

Es ist so, daß das System hier nach kopieren von radeon.ko, depmod und mkinitrd einfach nicht hochkommt, da kann ich radeon.ko kopieren wie ich will. Ich fürchte, daß ich abwarten muß, bis ein neuer Kernel kommt.

Ein update scheint ja in der Pipeline zu sein. Jedenfalls bekomme ich die Mitteilung, daß eine Aktualisierung ansteht und daß danach ein Neustart erforderlich ist, um die Änderung zu übernehmen.

Allerdings: Wenn ich das Update dann runterladen und einspielen will, dann erhalte ich die Fehlermeldung "Fehler beim Aktualisieren" und ich kann leider nichts einspielen.