Beiträge von Scytale

Grundsatzfrage: Bist du auf dem aktuellsten Versionsstand von Leap 16.0, da laut User-Info du noch Leap 15.4 betreibst?

Die technisch saubere Lösung ist, in einer Linux-VM die Tests zu machen, was geht, und was nicht unter Linux geht. Und wenn für dich danach Linux als Haupt OS eine Option ist, solltest du das Windows per VM unter Linux laufen lassen. Alles, was du hier gerade machst, sind Probleme zu lösen, die du dir selbst kreiert hast. Bitte nicht als persönlichen Angriff verstehen, sondern einfach als nüchterne Beurteilung von mir als Techniker. In einem offiziellen Support Call würdest du direkt abgewürgt werden, weil du ein nicht unterstütztes Setup fährst, bei dem niemand sagen kann, woher etwaige technische Probleme kommen.

Ich präferiere immer den die einfachste Lösung für ein Problem, weil mehr Komplexität mehr Probleme nach sich zieht, und imho ist eine Dual Boot Umgebung immer ein Zeitzünder zur Selbstzerstörung. Entweder killt Windows mit einem Update den Linux Bootloader, oder du kommst zu dem Schluss, Linux nicht mehr zu brauchen, und du musst es alles wieder neu aufsetzen, weil der Linux Bootloader vor allem hängt.

Ich sags nur, du willst als Workaround auf ein Dateisystem zurückgreifen, was richtig veraltet ist, starke Limitierungen hat und tendenziell schneller als andere Dateisysteme kaputt geht? Ich mein nur, eine VM darauf laufen zu lassen, die extrem viele Schreibvorgänge hat, führt zur starker Fragementierung und FAT32 hat keine gute automatische Selbstreparatur. Das heißt im Klartext: Dein Workaround erhöht das Ausfallrisiko, und deswegen würde dir jeder Techniker davon ganz klar abraten. FAT32 kannst du benutzen, um Daten von einem PC zum anderen zu transferieren, aber eine VM darauf laufen zu lassen, ist einfach suboptimal nett gesagt..

Lass die Idee lieber.

Die VM muss auf einen Datenträger liegen, den beide OS lesen können. Das ist aktuell nur NTFS, und das ist absoluter Schrott und neigt bei Nutzung unter Linux "dirty" zu werden. D.h. du musst da öfter ein Scandisc drüber laufen, sonst kann es Linux nicht mehr mounten. Und das ist ein Pain in the ass.

Guter Rat: Entscheid dich für ein OS, ob Windows oder openSUSE. Dieser und dein letzter Thread gibts nur, weil du Dual Boot praktizieren willst, und davon rät jeder ab.

Kleines 2025 Update:

Ich hab einen Langzeitversuch von über einem Jahr auf 3 Geräten mit Tumbleweed.

Packman erhöht den Wartungsaufwand regelmäßig, weil zypper dup nicht durchläuft, und bei Updates am Grafikstack Mesa die Systemstabilität variiert. Mir ist bei einem Gerät mit Packman einfach der Suspend kaputt gegangen, dass das Gerät einfach gecrasht ist, ging sofort weg nach entfernen aller Packman Pakete.

Erfahrungsgemäß muss ich mit Packman Repo genau so gut wie unter Arch bei Updates aufpassen. Ohne kann ich so blind wie bei einem Debian oder Ubuntu einfach alle Updates ohne Bedenken einspielen.

Die AMD Treiber sind viel besser und direkt im Kernel.

Es ist immer noch das wahrscheinlichste, dass bei der Installation irgendwas so an den Defaults geändert wurde, dass Dinge kaputt gemacht wurden. Ich weiß jetzt nur, dass du nicht den Default gewählt hast, da kein btrfs und snapper vorhanden. Da kann man jetzt ganz böse sagen: Unsupporteter Bereich. Hast du dein Zweitgerät genau gleich aufgesetzt? Deine Vermutung mit BIOS und EFI ist quatsch, die haben nichts damit zu tun, dass das OS keine Booteinträge im Bootloader neu generiert. Das EFI weiß nur, wo der Bootloader liegt.

Das ist auch keine Reparatur, das ist ein One-Time Workaround genau bis zum nächsten Tumbleweed Update (war heute Nacht). Alle Einträge sollten nach jedem Kernel Update automatisch neu generiert werden, was sie aber scheinbar nicht machen. Da deine Installation nicht dem Default entspricht und du eine undokumentierte Datei bearbeitest, hab ich da so meine Vermutung.

Ich hab jetzt nur noch den News-Artikel zu Grub-BLS gefunden

Zitat

Updating the kernel command line can now be done by editing the boot loader, or the /etc/kernel/cmdline and calling sdbootutil update-all-entries to propagate the change into the boot entries of the current snapshot.

sdbootutil update-all-entries

ausführen.

Wenn du heute ein "zypper dup" ausführst, läuft denn zypper denn in irgendwelche Fehler, vor allem am Ende, wenns um das Kernel Update geht?

Du hast überhaupt kein Problem, das sind nur die vorherigen Kernels, die eh irgendwann gelöscht werden. Völlig normal, ein,zwei Versionen zu behalten.

Das hört sich nach unsupporteten Bereich an. Kein Snapper, aber snapshots sollen da sein? Dann ist das einfach nur ein anderer Bootentry des vorherigen Kernels. Dann wohl auch nicht mit btrfs?

sudo snapper rollback

Das markiert den aktuell gebooteten Snapshot Al's den default. Danach kümmern sich automatisch laufende maintenance Jobs um das löschen älterer Snapshots.