Das von Sauerland im post #17 geschilderte Problem (opensuse-migration-tool) mit den fehlenden selinux-rpms lässt sich vermeiden, in dem man bei der Installations-Menüauswahl immer das voreingestellte 'SELinux" deaktiviert und stattdessen "bei AppArmor bleiben" auswählt. Eine Umstellung auf SELinux ist auch nach erfolgreichem upgrade auf 16.0 leicht möglich, wenn gewünscht.
Auf jeden Fall zuerst einen Probelauf durchführen:
sudo opensuse-migration-tool --dry-runJSC : da sehe ich eher kaum Probleme, zumal keine zu kleine Partition für / erstellt wurde ...
Um zusätzlich Leap 16 zu installieren, müsste zunächst dafür Platz auf sdb oder sdc geschaffen werden.
Ich denke, es ist daher für dich einfacher, mit dem migration-tool auf Leap 16.0 upzugraden, wie bereits u.a. von Sauerland empfohlen wurde.
Ein vorheriges backup ist anzuraten, insbesondere auch weil dein home-Verzeichnis keine eigene Partition ist
Leap15.6 ist bei mir auf einer separaten Festplatte und läuft super stabil. Ich will es momentan ohne Veränderungen erhalten.
Luigi, ich wollte Leap16.0 auf sdb3 installieren. Dort ist auch Leap 15.6.
Das geht so nicht. Du kannst nicht zwei unterschiedliche OS in eine einzige Partition installieren.
Daher meine Frage von post #8, wie groß ist sdb1?
Oder ist noch Platz hinter sdb3?
Zeige bitte
sudo fdisk -l /dev/sdbAuf welcher Disk willst du Leap 16.0 installieren? Wie groß ist sdb1?
Oder willst du die ntfs-Partition sdc1 verkleinern und Leap 16.0 auf dem frei werdenden Bereich unterbringen, so dass sdb und sda nicht angefasst werden müssen, außer dem notwendigen grub2-Eintrag im MBR von sda?
Als Markierung finde ich auf der Festplatte "legacy boot", wenn das etwas hilft.
Ja, das sieht nach einem non-uefi System aus.
Zur Kontrolle zeige bitte:
ls /sys/firmware/efiFalls hier nichts gefunden wird, dann kein uefi.
Und für die weitere Planung wäre hilfreich:
lsblk -f Läuft beides bei mir hier einwandfrei.
Vielen Dank für die Tipps.
Bisher habe ich nur sehr selten mit ZeroTier auf die entfernten Rechner zugegriffen. Die Einrichtung war einfach und der Zugriff ausreichend schnell.
Aber eigentlich will ich nicht andauern updates einspielen, eine Tätigkeit, welche die user in den vergangenen Jahren doch alle selbst erfolgreich durchführen konnten.
ZitatBisher konnten die anderen Familienmitglieder regelmäßig Updates durch / mit dem kleinen Symbol "Aktualisieren" in der Taskleiste direkt starten. Passwort, gar von root, war nicht erforderlich.
Das funktioniert eh nicht zuverlässig.....
Diese Aussage kann ich so allgemein nicht bestätigen. Über mehrere Jahre (... Leap 15.4, 15.5, 15.6) haben Freunde und Verwandte mit diesem Updateverfahren problemlos arbeiten können. Ich erinnere mich nur an einen Fall, wo ich helfen musste, weil die Rechner nach einem Kernelupdate nicht mehr funktionierten und man temporär wieder auf den vorherigen kernel umstellen musste. Das gleiche Problem hatte ich übrigens auch bei meinem Rechner, bei dem die updates immer mit zypper up durchgeführt wurden/werden.
Die von mir angesprochenen Rechner befinden sich übrigens nicht in meinem Heimnetz, sondern sind über die Republik verstreut. Da komme ich mit einem einfachen ssh ohne zusätzliche Installationen natürlich nicht hin.
Bisher habe ich auch noch keine Idee, was ich meinen 'Linux clienten' als Alternative zum einfachen und gewohnten, aber durchaus funktionierenen früheren Verfahren anbieten könnte. Nach meinem bisherigen Kenntnisstand gibt es derzeit keine Bemühungen, das frühere Prozedere wieder aufleben zu lassen.
Habe hier Leap 15.6, 16.0, 16.1 (beta) als auch Slowroll auf einer einzigen SSD (MBR) ohne Probleme laufen. Muss man aber je nach MBR- bzw. Uefi-Modus unterschiedlich bewerkstelligen.
Ist das ein Fehler in der Dependency-Liste des neuen Pakets?
Bei mir lief das mit zypper up durchgeführte Update nach dem Entfernen (zypper rl <Nr>) der vor ein paar Tagen gesetzten locks von mariadb, mariadb-client und mariadb-errormessages ohne Probleme durch ...
