Guten Abend,
was mir früher immer etwas augestoßen war, war das Fehlen von LUKS/cryptsetup im Rettungssystem.
Ich hab mir immer auf USB Platte ein extra Suse installiert, um ein Rettungssystem mit Luks zu haben, das würd ich mir gern sparen.
Hat sich das mittlerweile gebessert? Ist LUKS/cryptsetup mittlerweile (endlich) im Rettungssystem enthalten?
Gruß
Leap 15.2 mit Kernel 5.10.13
Ich krieg in dmesg tonnenweise Meldungen von nvme dieser Art hier, dmesg ist kaum noch lesbar damit....
[28937.009427] nvme 0000:01:00.0: 16.000 Gb/s available PCIe bandwidth, limited by 5.0 GT/s PCIe x4 link at 0000:00:01.1 (capable of 31.504 Gb/s with 8.0 GT/s PCIe x4 link)
[28937.049776] nvme 0000:01:00.0: 8.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s PCIe x4 link at 0000:00:01.1 (capable of 31.504 Gb/s with 8.0 GT/s PCIe x4 link)
[28952.425119] nvme 0000:01:00.0: 16.000 Gb/s available PCIe bandwidth, limited by 5.0 GT/s PCIe x4 link at 0000:00:01.1 (capable of 31.504 Gb/s with 8.0 GT/s PCIe x4 link)
[28952.465631] nvme 0000:01:00.0: 8.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s PCIe x4 link at 0000:00:01.1 (capable of 31.504 Gb/s with 8.0 GT/s PCIe x4 link)
[28960.048946] nvme 0000:01:00.0: 16.000 Gb/s available PCIe bandwidth, limited by 5.0 GT/s PCIe x4 link at 0000:00:01.1 (capable of 31.504 Gb/s with 8.0 GT/s PCIe x4 link)
[28960.130817] nvme 0000:01:00.0: 16.000 Gb/s available PCIe bandwidth, limited by 5.0 GT/s PCIe x4 link at 0000:00:01.1 (capable of 31.504 Gb/s with 8.0 GT/s PCIe x4 link)
[28960.335125] nvme 0000:01:00.0: 8.000 Gb/s available PCIe bandwidth, limited by 2.5 Das nvme Modul scheint aber keine Option zu besitzen, um es weniger verbose zu machen.
Da ich vermute, dass ich nicht der einzige bin, wollte ich mal fragen, ob jemand eine Lösung/Workaround hat. Tante Google hat leider nicht viel weitergeholfen....
Grüßle
EDIT, offenbar gelöst
Oh, das ist jetzt aber hochnotpeinlich....
Im Kernel einfach CONFIG_PCIE_BW nicht setzen.
Vielleicht hilfts dem ein oder anderen auch noch....
Hallo und N´abend,
wieso eigentlich unterhält SUSE/openSUSE eigentlich 2 Kernelzweige?
Einmal den TW Kernel und den Kernel von Leap, der ja von SLE kommt.
Ich kann ja verstehen, dass Leap als besonders stabil beworben wird, aber erstens werden mehr Ressourcen aufgewendet und zweitens würden die Leap Benutzer ja von einem aktuelleren Kernel profitieren. Viele Leute schaffen sich moderne Grafikkarten an oder wollen die neueste CPU installieren etc.
Mein Eindruck ist, der TW Kernel ist nicht viel weniger stabil als der von Leap, hat aber die neuesten Feature.
Ich werd wohl nicht der erste sein, dem der Gedanke kam....
lG
Aha!
Wer ist eigentlich dieser Sauerland, kennt den jemand, was der uns immer an Software zur Verfügung stellt ist ja fantastisch 
PS, in TW ist gscan scheinbar schon offizieller Teil, wird Leap dann nachziehen, oder erst nächste Leap Version?
Wenn ich mich mal an den alten Thread dranhängen darf...
gscan2pdf aus dem Publishing Repo lässt sich auf Leap 15.2 nicht installieren:
missing perl-Goo-Canvas2. perl-goo-canvas gibt es, scheint aber nicht auszureichen.
Was ich mich frage, wenn perl-Goo-Canvas2 zum Installieren fehlt, wie konnte gscan dann gebaut werden?
lG
Hallo!
Ist zufällig jemand hier, der einen aktuellen Epson Workforce benutzt?
Mir juckt der WF 2860 DWF in der Nase.
Im EPSON Download Center gibt es tatsächlich einen Linux Treiber für das Model.
Weiß aber jemand, ob bei aktuellen WF Modellen der Scanner funktioniert?
Gruß
Also ich kann mir das nur so erklären, dass die es sich nochmal überlegt haben.
Softwarepakete müssen dann plötzlich in /etc/ und /usr/etc suchen, Anwender finden plötzlich ihre gewohnten Sachen nicht mehr.... um es mal mit Grönemeyer zu sagen: was soll das?! 
Guten N´abend!
Ich hab in den Changelogs gelesen, dass beginnend mit Leap 15.2 die neue Struktur unter /usr/etc/ eingeführt werden soll.
Also ich habe nach einem Upgrade von 15.1 auf 15.2 kein /usr/etc/ auf dem Rechner....
Wird /usr/etc/ vielleicht nur bei Neuinstallation angelegt? Oder bei offline Update mit DVD?
Nicht, dass irgendwann ein Paket /usr/etc/ erwartet und das ist gar nicht existent hier....
Gruß
Jup, genau das habe ich vorhin auch gefunden und es hat gewirkt!
/var/log/zypp/history wächst im Laufe der Jahre doch etwas an....
Das zypp wegen so nem Logfile dermaßen gleich ins Staucheln gerät....
Ich hoffe, das Löschen (Backup gemacht) hat keine Nebenwirkungen...
PS, wie werden gelöste Fragen als gelöst markiert?
Hallo!
Ich habe gerade ein Live Upgrade von 15.1 auf 15.2 gemacht mit zypper dup. Hat soweit auch geklapppt.
So, dann habe ich Stück für Stück Repos wie Packman usw. wieder einbinden wollen, da fängt zypper an zu zicken.
Dann habe ich die Dritt Repos wieder deaktiviert und nur die openSUSE Repos aktiv gelassen, aber auch hier geht zypper nicht mehr.
Der Befehl zypper --verbose list-updates ergibt diesen Fehler:
Ausführlichkeitsgrad: 2
Ziel wird initialisiert
Es wird überprüft, ob die Metadaten für Haupt-Repository (NON-OSS) aktualisiert werden müssen
Es wird überprüft, ob die Metadaten für Aktualisierungs-Repository (Nicht-Open-Source-Software) aktualisiert werden müssen
Es wird überprüft, ob die Metadaten für Haupt-Repository (OSS) aktualisiert werden müssen
Es wird überprüft, ob die Metadaten für Hauptaktualisierungs-Repository aktualisiert werden müssen
Es wird überprüft, ob die Metadaten für openSUSE-Leap-15.2-Source aktualisiert werden müssen
Es wird überprüft, ob die Metadaten für openSUSE-Leap-15.2-Source-Non-Oss aktualisiert werden müssen
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...
Auflösung erzwingen: Nein
/usr/include/c++/7/bits/stl_vector.h:797: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) [with _Tp = std::__cxx11::basic_string<char>; _Alloc = std::allocator<std::__cxx11::basic_string<char> >; std::vector<_Tp, _Alloc>::reference = std::__cxx11::basic_string<char>&; std::vector<_Tp, _Alloc>::size_type = long unsigned int]: Assertion '__builtin_expect(__n < this->size(), true)' failed.
Abgebrochen (Speicherabzug geschrieben)Den Output von zypper lr häng ich mal als Screenshot an, als Text hier reingepastet sieht kaputt aus. Wie man sieht, nur die SUSE Repos aktiv.
Da Yast tadellos funktioniert, scheint die RPM Datenbank ja nicht beschädigt zu sein.
Wenn jemand eine Idee hat, gerne her damit.
Gruß