Beiträge von Spaceloop

    Repo 14 und 15 gehören nicht zu openSUSE, dafür fehlt:

    https://mirrorcache-eu.opensus…date/leap/15.4/backports/

    Danke, irgendwie sind da tatsächlich Repos doppelt drin. Die 14 und 15 hatte mir glaub ich Leap 15.3 als /SLE-15-SP3/standard/ reingegeben. Beim letzten Update habe ich dann extra manuell den Link auf SP4 angepasst, weil ich dachte es wäre wichtig...


    Das von dir monierte fehlende Repo ist tatsächlich mit Mirrorcache so anzumelden, oder ist es evtl. doch Nr. 22?


    Sieht jetzt so aus:

    EDIT: hab mir jetzt nochmal den Link zu meinem ursprünglichen Repo 22 angesehen:

    Scheint die gleiche Struktur zu enthalten wie der von dir angegebene Mirrorcache-Link, nur dass mein Link neuere Dateien aus 2023 hat... ??

    Zweiteilung wegen Zeichenlänge:

    Hallo,


    bei SUSE und openSUSE kündigen sich am Horizont große Umstellungen an. Wie bei anderen Distributionen auch, wird nach dem künftigen Leap 15.5 auf eine Container-Zentrierte Architektur umgestellt. Davon eigentlich unabhängig, aber im gleichen Aufwasch miterledigt, werden die Mindesthardwarevoraussetzungen angehoben. Bisher läuft openSUSE in Gestalt von Tumbleweed auch noch auf 32-Bit-Systemen, und mit einer schlanken DE sogar recht performant auf alten Computern.


    Der offizielle Support von SUSE und openSUSE für 32 Bit-Systeme, sowie auch für x64-v1-Systeme, wird mit der ALP-Plattform nach Leap 15.5 auslaufen bzw. Freiwilligen überantwortet werden. Dies schließt also auch 64-Bit Prozessoren bis ca. 2010/2011 wie z.B. die seinerzeit beliebten Intel Core /Core Duo...-Baureihen mit aus. Mein Desktop ist ein Haswell-i5 und hat damit kein Problem, mein alter Laptop ist damit aber leider betroffen. Bisher läuft auf beiden Leap, auf dem Läppi mit xfce, und das mehr als ausreichend flott...


    Ich frage mich, wie ich mit der Situation am Laptop umgehen werde.


    1) Schauen, was die Freiwilligen mit Tumbleweed x32 auf die Beine stellen? Allerdings ist dies schon unüberschaubar. Wenn eine kritische Menge an Freiwilligen ausfällt, steht man auf einmal sehr plötzlich ohne Support da...? Außerdem würde ich den Laptop auf 32 Bit downgraden. Dabei ist damit zu rechnen, dass die Mehrzahl der Tumbleweed-Pakete noch eher für 64 Bit (V2) gebaut werden und man sich mit einem bescheidenen 32-Bit-Paket-Rest begnügen muss. Und auch bei Flatpaks und Appimages würde man sich von einer großen Paketanzahl abschneiden. Der Vorteil wäre, dass man seine gewohnte und geliebte openSUSE-Umgebung behalten würde.


    2) Darauf hoffen, dass sich zusätzlich Freiwillige finden, die openSUSE für x64-v1 bauen? Man hätte dann zumindest bei Flatpaks und Appimages wieder die "gewohnte" Auswahl, aber bzgl. der langfristigen Unterstützung innerhalb des openSUSE-Projekts wäre ich doppelt skeptisch im Verglleich zu 1)...


    3) Eine alternative Distribution finden, welche geliebte Features von openSUSE ebenfalls hat. Sehr wichtig wäre mir z.B. BTRFS und snapper-GRUB. Wie oft hatte ich es in meiner Distro-Hopping-Zeit geschafft, irgendwas so an einer Installation zu verstellen, dass das System nicht mehr hochfuhr oder wahlweise unbenutzbar war. Dies hat bei openSUSE ein Ende gefunden, da man ja immer wieder einen vorigen Snapshot starten und wiederherstellen kann. Dazu wären grafische Einstellungs-Tools wichtig, was bei Suse durch Yast abgedeckt wird.


    Bisher habe ich z.B. Garuda-Linux gefunden. Auf Arch-Basis, aber eben mit grafischen Einstellungstools und Snapper-Grub... Eine deutsch-indische Distribution. Ich vermute, dass dort im Projekt wichtige Leute sitzen, welche auch openSUSE gut kennen. Die Tumbleweed-Gene sind teilweise spürbar. Allerdings ist das Projekt relativ klein. Der Livestick startet auf dem besagten Laptop.


    Auch stellt sich die Frage was aus der Richtung "Permutable Linux" noch kommt und welche Alternativen es schon gibt, wenn es einfach nur darum geht, alte Systemzustände starten zu können. Gibt es hier Tipps zu ressourcenschonenden x86-64v1-kompatiblen Distributionen mit halbwegs großer Verbreitung und Paketauswahl?

    Hallo,

    seit einiger Zeit erhalte ich bei meinen routinemäßigen Paketupdates via zypper up regelmäßig die Meldung, dass diverse %posttrans-Scripte failen.


    Das betrifft meistens den NVidia-Treiber, Kernel-Updates und zum Teil auch Pakete von Softmaker aus deren Repo. Es kommt mir so vor, als hätte ich ein generelles Problem mit %posttrans-Scriplets... Woran kann das liegen? Werden diese %posttrans-Scripte durch einen externen Prozess abgearbeitet, welcher dafür aus irgendeinem Grund zu wenig Rechte hat? Aktuell habe ich wieder so ein paar tolle Nachrichten.


    Bisher hat das System aber nach jedem Update normal gebootet.

    Ich habe aber die Befürchtung, dass es irgendwann nicht mehr der Fall sein könnte, oder sich irgendwelche Altlasten ansammeln.

    Ich blicke noch nicht 100% durch, was Allow Vendor Change und {releasever} betrifft...


    Das sind aktuell meine Repos.


    Das folgende sind die Urls:


    Wie gehe ich damit um? Anpassungsbedarf würde ich gemäß Anleitung bei

    Code
    http://download.opensuse.org/distribution/leap/15.3/repo/oss/
    https://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_15.3/
    https://download.opensuse.org/repositories/openSUSE:/Backports:/SLE-15-SP3/standard/

    sehen.



    Endergebnis sollte so aussehen?

    Code
    http://download.opensuse.org/distribution/leap/$releasever/repo/oss/
    https://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_$releasever/
    https://download.opensuse.org/repositories/openSUSE:/Backports:/SLE-15-SP4/standard/

    So, ich habe jetzt ./esets_gil als su ausgeführt. Es erscheint ein Uninstall-Assistent, welcher zumindest das Tray-Programm löscht. Der Service bleibt irgendwie noch bestehen und wird durch den Uninstaller nicht angetastet, aber da half

    Code
    systemctl stop esets

    sowie

    Code
    systemctl disable esets

    Anschließend bin ich dann noch in den unter

    Code
    systemctl cat esets

    angezeigten Pfad, und habe die Service-Datei gelöscht. Den Trick habe ich in einem Reddit ergoogelt.


    Dort wurde auch empfohlen, die Aktion mit


    Code
    systemctl daemon-reload
    systemctl reset-failed


    abzuschließen. Anschließend Neustart, und ESET scheint weg zu sein...

    Hallo,


    ich habe das folgende Problem:


    Wenn ich meinen PC hochfahre, mich in Leap 15.3 (KDE) einlogge und ein Flatpak-Programm mit 3D-Grafik starten möchte, bricht der Start ab. In der Konsole erscheinen Fehlermeldungen.


    Ich muss mich erst ausloggen und dann wieder einloggen, und dann funktioniert es plötzlich, auch in X11. Betroffene Programme sind Libre TrainSIm und Sweethome3D.


    Woran kann dieses Verhalten liegen?