Deine Installation des Treibers, wenn Du diese unter Yast mit dem älteren laufenden Kernel *****.54 anschaust, sieht doch auch so aus?
exakt genau so.
Deine Repos sind in der Yast-Darstellung übersichtlicher nachzuvollziehen, bei mir sieht das so aus:
stimmt, bei mir aucht, Auf die Idee eines Screen-Shots bin ich nicht gekommen. Aber es ist, glaube ich, auch über dem Umweg über eine Textdatei klar geworden, welche Repos bei mir aktiv geschaltet sind und welche nicht.
Bitte benutze Code-Tags für Konsolenausgaben, ist einfach übersichtlicher.
... tut mir leid, bei mir sieht es immer gleich bescheuert aus. Deshalb jetzt per Datei-Output.
Hast du irgendwelche Kernel Pakete (Treiber) selbst kompiliert oder irgendwelche kmps installiert?
Codezypper se -si kmp
nein.
> zypper se -si kmp
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...
Keine passenden Objekte gefunden.
Codezypper lr -d
zypper lr -d
# | Alias | Name | Enabled | GPG Check | Refresh | Priority | Type | URI |
Serv->
---+-----------------------------+---------------------------------------------------------------------------------------------+-----------+-----------------+----------------+-----------+--------+-------------------------------------------------------------------------+-
------
1 | google-chrome | google-chrome | Ja | (r ) Ja | Ja | 99 | rpm-md | https://dl.google.com/linux/chrome/rpm/stable/x86_64 |
2 | openSUSE-Leap-15.3-1 | openSUSE-Leap-15.3-1 | Nein | ---- | ---- | 99 | NONE | cd:/?devices=/dev/disk/by-id/ata-HL-DT-ST_DVDRAM_GH22NS50_K2EA6DA0803 |
3 | repo-backports-debug-update | Update repository with updates for openSUSE Leap debuginfo packages from openSUSE Backports | Nein | ---- | ---- | 99 | NONE | http://download.opensuse.org/u…eap/15.3/backports_debug/ |
4 | repo-backports-update | Update repository of openSUSE Backports | Ja | (r ) Ja | Ja | 99 | rpm-md | http://download.opensuse.org/update/leap/15.3/backports/ |
5 | repo-debug | Debug Repository | Nein | ---- | ---- | 99 | NONE | http://download.opensuse.org/d…ution/leap/15.3/repo/oss/ |
6 | repo-debug-non-oss | Debug Repository (Non-OSS) | Nein | ---- | ---- | 99 | NONE | http://download.opensuse.org/d…n/leap/15.3/repo/non-oss/ |
7 | repo-debug-update | Update Repository (Debug) | Nein | ---- | ---- | 99 | NONE | http://download.opensuse.org/debug/update/leap/15.3/oss/ |
8 | repo-debug-update-non-oss | Update Repository (Debug, Non-OSS) | Nein | ---- | ---- | 99 | NONE | http://download.opensuse.org/debug/update/leap/15.3/non-oss/ |
9 | repo-non-oss | Non-OSS Repository | Ja | (r ) Ja | Ja | 99 | rpm-md | http://download.opensuse.org/d…n/leap/15.3/repo/non-oss/ |
10 | repo-oss | Haupt-Repository | Ja | (r ) Ja | Ja | 99 | rpm-md | http://download.opensuse.org/d…ution/leap/15.3/repo/oss/ |
11 | repo-sle-debug-update | Update repository with debuginfo for updates from SUSE Linux Enterprise 15 | Nein | ---- | ---- | 99 | NONE | http://download.opensuse.org/debug/update/leap/15.3/sle/ |
12 | repo-sle-update | Update repository with updates from SUSE Linux Enterprise 15 | Ja | (r ) Ja | Ja | 99 | rpm-md | http://download.opensuse.org/update/leap/15.3/sle/ |
13 | repo-source | Source Repository | Nein | ---- | ---- | 99 | NONE | http://download.opensuse.org/s…ution/leap/15.3/repo/oss/ |
14 | repo-update | Hauptaktualisierungs-Repository | Ja | (r ) Ja | Ja | 99 | rpm-md | http://download.opensuse.org/update/leap/15.3/oss |
15 | repo-update-non-oss | Aktualisierungs-Repository (Nicht-Open-Source-Software) | Ja | (r ) Ja | Ja | 99 | rpm-md | http://download.opensuse.org/update/leap/15.3/non-oss/ |
Alles anzeigenWill man mal etwas auf die Schnelle für sich probieren und einen neuen Kernel
zum Arbeiten bewegen, der von sich aus so nicht mit der betreffenden Grafikkarte
zusammenarbeitet, dann kann man beim Starten unter den Boot-Optionen mal
versuchen:
nomodeset xforcevesa
Erst mal auf die Schnelle:
Wenn ich diese Parameter in der Befehlszeile in Grub eingebe, dann kommt das System vmlinuz-5.3.18-150300.59.54-default hoch, Die Anmeldescreen ist zwar verzerrt, aber sie startet. Das System vmlinuz-5.3.18-150300.59.60-default kommt nicht hoch.
Es ist auch nicht so (wie vor ein paar Monaten), das das System starten würde, nur halt mit einer black screen: Es ist so, daß das System gar nicht startet. Das mit den Boot-Meldungen muß ich ausprobieren. Das dauert ein bißchen.
Also, erst mal der Reihe nach, ich habe gestern nicht ins Forum geschaut:
Ne, aber bei der Corona Impfung gibt es auch Komplikationen..........
Daher stellt sich die Frage, ob an dem Gerät des TE etwas besonderes ist oder nicht?????????
Es reicht schon ein "krummes" Hersteller-Bios.....
Ich gehe davon aus, daß mit "TE" ich gemeint bin:
Es ist kein Laptop, sondern ein Desktop, den ich zusammengestellt habe:
Mainboard Asus B550M, Prozessor Ryzen 5 3600, 32 GB memory zum Mainboard passenden Typs, 1 TB Samsung SSD 970 EVO Plus, Grafikkarte Radeon HD 6450 1GB DDR3, noch 2 über ATA angeschlossene SSDs auf denen Nutzerdaten liegen, sonst nichts. Der Rest (LAN-Schnittstelle, Sound,...) vom Mainboard.
Reicht das?
CodeLäuft auf dem Laptop: uname -a && lsb-release -id
weiß nicht, ob ich mich klar genug ausgedrückt habe. Ich komme gar nicht so weit, daß ich ein Terminal-Fenster öffnen könnte.
> uname -a && lsb-release -id
Linux Mozart 5.3.18-150300.59.54-default #1 SMP Sat Mar 5 10:00:50 UTC 2022 (1d0fa95) x86_64 x86_64 x86_64 GNU/Linux
Distributor ID: openSUSE
Description: openSUSE Leap 15.3
....Dann habe ich immer einen Bugreport auf Bugzilla geschrieben und es gesellten sich schnell weitere Betroffene dort hinzu.
Mit solchen Hinweisen auf Fehler im System hilft man den SuSE Entwicklern und erhält i.d.R. auch recht schnell Rückmeldungen. Das ist das Einzige wozu ich Dir raten kann.
Einen Bugreport habe ich für openSUSE noch nie geschrieben. Vielleicht sollte ich das künftig wirklich tun.
Ob es in diesem Fall an meiner Graka liegt, weiß ich nicht. Ich kann nur beobachten, daß der Startprozess kurz nach Grub hängen bleibt.
Nun gut, sobald openSUSE 15.4 rauskommt (und ich ein paar Tests gemacht habe, um mich davon zu überzeugen, daß alles läuft, was ich so brauche) fliegt meine Graka raus.. Ich habe einen Ryzen 5 5600G in Wartestellung. Den benutze ich momentan zu Testzwecken auf einem separaten Rechner unter openSUSE 15.4-Beta und das sieht gar nicht so schlecht aus.
Und nun?
Nix "und nun".
Ich dachte mir nur, daß jemand das wissen sollte, daß es Systeme gibt, die mit dieser Kernel-Version nicht starten. Ich wüßte nicht, daß ich besondere Bedingungen hier hätte (mal abgesehen von meiner älteren und schmalbrüstigen Grafikkarte). Aber soweit ich es verstehe, kommt die Grafikkarte gar nicht richtig zum Zug.
Habe den Bootloader wieder so konfiguriert, daß ein funktionierender Kernel per default angestartet wird. Damit kann ich vorläufig leben. Vielleicht funkioniert der nächste Kernel bei mir wieder.
Wenn ich etwas ausprobieren, eine Frage beantworten soll: Ich bin gerne bereit dazu. Mehr kann ich nicht tun.
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.
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.
