Beiträge von Spaceloop

    Du hast ein Verzeichnis zu viel:

    Code
    x86_64

    Danke für die Antwort. Mein Ergebnis: Versuche ich das zu ändern, d.h. die $basearch-Variable zu entfernen, erscheint ein Hinweis, dass dies vom Dienst openSUSE verwaltet wird und nach der nächsten Änderung wieder zurück gesetzt werden kann.


    Und so kommt es dann auch.


    beim nächsten zypper up-Test wird $basearch wieder an die Repo-URL angefügt und es hat sich nichts geändert. :(

    Hallo,


    ich versuche gerade, mein bisher auf Leap 15.6 laufendes Hauptsystem auf 16.0 zu upgraden. Dafür will ich das Migration Tool verwenden.


    Ich habe also zypper up durchgeführt und dann das Migration Tool installiert. Target war 16.0.


    Beim Abarbeiten des Upgrades hat das Migration Tool Fehler ausgeworfen, weil es bestimmte Repos nicht gefunden hat. Daher habe ich im Wiki recherchiert und folgendes geändert:


    1) Das openSUSE Games-Repo ist schon seit einiger Zeit umgezogen. Ich hatte einen falschen Link. --> Games-Repo erstmal gelöscht.

    2) Umstellung der Adressen von download.opensuse.org auf cdn.opensuse.org, wie es auch im Wiki für ein Upgrade beschrieben ist.


    Jetzt habe ich folgende Repos:


    ein einfaches zypper up liefert folgendes Ergebnis:


    Das Merkwürdige ist: Wenn ich im Terminal die angeblich fehlerhafen Links mit STRG anklicke, lande ich sofort mit Firefox im jeweiligen Repo. :/ :?:

    Solange sich zypper so verhält, kann ich aber nicht upgraden.

    zu 6. Repositories:


    -mit den Standard-Repos und dem Packman-Repo kommst du schon recht weit.

    -wenn bestimmte Pakete nicht auffindbar sind, lohnt es sich oft, die thematisch passenden opensuse-Zusatzrepos zu prüfen. Diese finden sich unter https://download.opensuse.org/repositories/ .... Leider hat sich hier über die Jahre ein gewisser Wildwuchs entwickelt. Viele Verzeichnisse beinhalten Repos, die nur bis zu früheren openSUSE-versionen gepflegt wurden. Aber die wichtigen sind auch für Leap 16 wieder da, z.B. https://download.opensuse.org/…tories/games/16.0/x86_64/, https://download.opensuse.org/…imedia:/apps/16.0/x86_64/ ...


    -tendenziell sehr vorsichtig bin ich bei den sog. 1-Click-Repos, wie sie z.T. im inzwischen kaum gepflegten Wiki angegeben werden. Ebenso Repos von einzelnen Nutzern aus dem OBS. Die können sehr schnell auch wieder verschwinden. Oder lösen Kompatibilitätsprobleme aus, wenn ein Paket irgendwann in den Haupt-Repos auftauchen sollte. Grundsätzlich ist bei den Repos Sparsamkeit zu empfehlen. Hier schlagen gelegentlich Leute auf, deren Probleme aus dem ständigen Hinzufügen der "1-Clicker" resultieren, und wo kein Mensch mehr in der Repoliste durchblickt...


    Multimediacodes lassen sich über die das Terminal mit "opi codecs" recht einfach dazu installieren. Das Packman-Repo ist danach in der Regel eingebunden.

    Wenn die unfreien NVidia-Grafiktreiber installiert werden sollen, erfolgt dies über ein Extra-Repo von NVidia. Noveau wird dann automatisch deinstalliert.


    Zitat

    Des weiteren, ich verzichte auf btrfs bei Dualboot/Multiboot - Grub, bzw. os-prober, zickt da oft rum.

    Das kann ich so überhaupt nicht bestätigen. Wobei ich nur Erfahrungen mit einem parallel installiertem Windows bzw. zwei parallel installierten Windows vorweisen kann. Aber hier lief in den letzten Jahren alles rund. Die btrfs-Snapshots haben mir schon an der ein oder anderen Stelle den A... gerettet bzw. mich davor bewahrt, das System neu aufsetzen zu müssen. Gerade, wenn man etwas Halbwissen mitbringt, spielt man auch mal an kritischeren Systemteilen herum. Wenn openSUSE dann nicht mehr hochfährt --> einfach in GRUB in den vorigen Snapshot booten, dort "sudo snapper rollback" ins terminal tippen, neu starten und voila, man ist wieder auf dem vorigen Stand und kann weiterarbeiten! 8)

    Würde ich gerade experimentierfreudigen Leuten mit Linux-Halbwissen empfehlen. Oder z.T. auch Usern mit der Kombi Tumbleweed+geschlossener NVIdia-Treiber.

    Snaphots einsehen geht bis Leap 15.6 und noch in Tumbleweed unter Yast. Generisch gibt es zwar unter Linux Butter und btrfs-assistant, allerdings weiss ich nicht, ob diese in den Leap-16-Repos verfügbar sind.


    Snapshots werden grundsätzlich vor jedem zypper up angelegt.

    Eine nicht uninteressante Nachricht:


    Suse holt zwei neue Führungskräfte
    Mit Nicholas Dimotakis und Astor Carlberg hat Suse zwei neue Führungskräfte für zentrale Rollen in Vertrieb und Strategie gewonnen. Beide sollen dazu…
    www.itreseller.ch


    -Nicholas Dimotakis: von Canonical abgeworben


    -Astor Carlberg: kommt vom Thinktank Open Forum Europe und wird sich mit Strategie/Digitaler Souveränität und Community Engagement  :/ befassen.


    Dann beiden mal einen guten Start bei SUSE...

    Irgendwie kommt hier aktuell keine Ruhe rein... Jetzt, nachdem sich die Verwirrungen um ALP, Leap 16 & Co. geklärt haben.


    Einem Reuters-Bericht zufolge prüft EQT laut Insidern bei Banken, wie man die SUSE SA zu Cash machen könnte. Dabei werden 6 Milliarden Dollar avisiert:


    https://www.reuters.com/business/eqt-eyes-potential-6-billion-sale-linux-pioneer-suse-sources-say-2026-03-09/


    SUSE Reportedly May Be For Sale Yet Again - Phoronix


    EDIT: hier inzwischen auf Deutsch:

    Linux-Spezialist SUSE soll verkauft werden
    Der schwedische Finanzinvestor EQT denkt einem Medienbericht zufolge über einen Verkauf des Linux-Spezialisten SUSE nach.
    www.it-daily.net

    Leap 16 ohne Yast ist ein Albtraum.


    Ich schmeiße jetzt das Handtuch und werde eine andere Distro verwenden.

    Es scheitert bei den einfachsten Sachen.

    Zitat

    Und du meinst, andere Distributionen haben Yast?

    Zitat

    Nimm Tumbleweed, da gibt es yast noch!

    Ich denke Slowroll wäre da ein guter Kandidat.

    "Dabei sein" heißt bei Tumbleweed ja, mindestens 10 - 15 Minuten pro Woche dem System beim Updaten zuzusehen. Besonders auch bei etwas älteren Systemen und/oder langsamerer Internetverbindung. Ich finde das so praktischer und wesentlich angenehmer. :)


    Aktuell wäre mein Recovery-Plan nach einem fehlerhaften Update, die transaktionalen updates zu disablen, wie in der Anleitung beschrieben:


    Code
    sudo systemctl disable --now transactional-update.timer transactional-update-cleanup.timer rebootmgr.service create-dirs-from-rpmdb.service

    Falls ich das nicht schnell genug schaffe, und das System fehlerhafte Updates erneut zieht, müsste eben vorübergehend eine Kindersicherung in der Fritzbox konfiguriert werden.


    Im Härtefall kombiniert mit einer Deinstallation der Pakete:


    Code
    sudo zypper rm transactional-update rebootmgr dracut-transactional-update


    Allerdings würde ich eine elegantere Lösung als die Kindersicherung bevorzugen, um das System vorübergehend aus dem Netz zu nehmen.

    Normalerweise sollten dir in den Standard-Installationseinstellungen von openSUSE btrfs Snapshots zum Booten angezeigt werden, die bei 99% aller Softwarefehler den Rollback auf einen funktionierenden Stand ermöglichen sollte. Hast du openSUSE nicht mit btrfs installiert und wenn nein, warum?

    Das würde mich auch interessieren. Gibt es im Bootmenü einen Menüpunkt "Start bootloader from read-only snaphot" o.ä.?


    Du könntest auch im GRUB-Bootmenü auf die GRUB-Shell (Taste c) und mal


    Code
    echo $root
    ls ($root)/.snapshots

    eingeben. Was wird angezeigt?

    Hallo Forum, :)


    ich habe jetzt mal ein Tumbleweed-System auf transaktionale Updates umkonfiguriert und dabei die folgende Anleitung inkl. Vendor-Changes und Flatpak-Updates umgesetzt:


    Enabling Automatic Updates on openSUSE Tumbleweed and Slowroll
    openSUSE Tumbleweed is a rolling-release Linux distribution well-known for its stability, thanks in part to its use of Btrfs snapshots. By enabling…
    lowtechlinux.com


    Die Erfahrungen sind bisher sehr gut! :thumbup:


    Ich habe zypper dup seither nicht mehr genutzt und bekomme im Regelbetrieb von den Updates nichts mit. Beim Starten von Tumbleweed in Grub wird gelegentlich die Kernel-Version hochgezählt, daran sieht man dann, dass ein Update durchgeführt wurde.


    Ansonsten hilft das in der Anleitung erwähnte


    Code
    sudo journalctl -u transactional-update.service --no-pager -n 50

    Grundsätzlich läuft das also bisher super und wie gedacht.


    Allerdings habe ich noch zwei Fragen:


    1: Bisher waren die Updates, wie unter openSUSE üblich, immer ausgereift und stabil. Wie wäre aber die Vorgehensweise, wenn das System nach einem fehlerhaften Update in einen schwarzen Bildschirm booten würde? Man würde ein snapper rollback durchführen, hätte dann aber wohl das Problem, dass das System sich dann ein fehlerhaften Update automatisch erneut ziehen würde? Wie könnte man das vermeiden? Meine Gedanken gehen aktuell in die Richtung, das frühere Image in Grub temporär mit einem Kernel-Parameter zu starten, welcher das Netzwerk deaktiviert oder falsch konfiguriert...


    2. Ich habe versucht, das Flatpak-Update-Script mit einer notify-send-Nachricht zu ergänzen, mit dem Ziel, auf dem Desktop einen Hinweis angezeigt zu bekommen, wenn es läuft. Funktioniert aber leider nicht.