Leap 16.0 LVM basiertes System mit tar recovern liefert "non-startable" System

Hinweis: In dem Thema Leap 16.0 LVM basiertes System mit tar recovern liefert "non-startable" System gibt es 9 Antworten. Der letzte Beitrag () befindet sich ganz unten auf dieser Seite.
  • Ich benutze seit langer Zeit tar-Archive um meine Systeme mit allen Einstellungen und Programmen verteilbar und sauber wieder herstellbar zu machen.

    Aus diesem Grund verwende ich auch seit etwa Leap 15.0 die Methode "upgrade" um auf ein neues System-Release umzurüsten.

    Seit ich eine Leap 15.6 auf Leap 16.0 "upgegraded" habe, bootet ein wiederhergestelltes System nicht mehr, selbst dann, wenn ich es auf den Platz schreibe, aus dem es gesichert wurde. Vor der Wiederherstellung des System auf den ursprünglichen Platz lösche ich dessen Inhalt mittels "rm -rf *" innerhalb des Dateisystem auf welches geschrieben werden soll. Leider bricht der Ladevorgang so ab, dass es weder Logs noch ablesbare Fehlermeldungen gibt.

    Zu meinem System:

    Als Multi-Systemumgebung habe ich Windows 11 und mehrere Linux-Systeme auf einer m.2 NVM SSD installiert.

    Die Linuxsysteme liegen in logischen Laufwerken in einer gemeinsamen Volume-Gruppe (lvm-basiert).

    Ich habe alle Linux-Systeme in root und home Partitionen aufgeteilt und nutze für beides ext4 als Filesystemtyp.

    Ich habe eine ziemlich aktuelle Tumbleweed-Installation als zweites System in dieser Volume-Group und noch ein drittes System für Test-Zwecke.

    In Linux nutze ich nur opensuse Systeme.

    Für den Inhalt des Beitrages 325541 haftet ausdrücklich der jeweilige Autor: buabe

  • Nach durchsuchen der gemeldeten Fehler im Zusammenhang mit Boot und Leap 16.0 fand ich nun auf ein Problem mit der Umstellung auf "selinux" während der Migration. Dort habe ich den Lösungsweg durchgegangen und festgestellt, dass ich auch dem Restore ein lauffähiges System erhalte, sobald ich sicher selinux ausgeschaltet habe.

    Die Aktivierung von selinux auf meinem System funktioniert nicht.

    Für den Inhalt des Beitrages 325546 haftet ausdrücklich der jeweilige Autor: buabe

  • Bei zwei Sachen würde ich vorsichtig sein:


    tar richtet sich normalerweise nach den Usernamen und nicht nach deren Nummern. So kommen die Dateien von "otto" des einen Rechners zu "otto" des anderen Rechners auch wenn die bei den beiden verschiedene Nummern haben. Wenn aber die Datei mit der Nummernzuordnung (/etc/passwd) mit gespeichert wird, wird die Sache hinterlistig. Dann sollte man bei tar den Parameter "--numeric-owner" benutzen.


    "rm -rf *" entfernt meines Wissens nicht die mit "." anfangenden Dateien.

    Für den Inhalt des Beitrages 325547 haftet ausdrücklich der jeweilige Autor: Welm

  • Nach durchsuchen der gemeldeten Fehler im Zusammenhang mit Boot und Leap 16.0 fand ich nun auf ein Problem mit der Umstellung auf "selinux" während der Migration.

    Mal nachgeschaut, das alle selinux Pakete installiert sind?

    Oder mal als root ausgeführt:

    Code
    touch /.autorelabel

    Danach neu starten und es werden alle Dateien neu gelabelt, was dann den Neustart natürlich verzögert, bei mir mit 2x2TB Festplatte ca 10 Minuten.

    Für den Inhalt des Beitrages 325548 haftet ausdrücklich der jeweilige Autor: Sauerland

  • Mal nachgeschaut, das alle selinux Pakete installiert sind?

    Oder mal als root ausgeführt:

    Code
    touch /.autorelabel

    Danach neu starten und es werden alle Dateien neu gelabelt, was dann den Neustart natürlich verzögert, bei mir mit 2x2TB Festplatte ca 10 Minuten.

    Bei mir sind wohl nicht all diese Pakete installiert.




    aber ich habe mit

    Code
    zypper install -t pattern selinux
    Dienst 'openSUSE' wird aktualisiert.
    Repository-Daten werden geladen...
    Installierte Pakete werden gelesen...
    'pattern:selinux' ist bereits installiert.
    Kein Aktualisierungskandidat für 'pattern:selinux-20241218-160000.2.2.x86_64'. Die neueste Version ist bereits installiert.
    Paketabhängigkeiten werden aufgelöst...


    überprüft, ob alles notwendige installiert ist.


    Das System hängt sich schon vor erkennen der Systempartition auf.

    Für den Inhalt des Beitrages 325553 haftet ausdrücklich der jeweilige Autor: buabe

  • Nachdem nun mein System nicht mehr startete, habe ich eine Sicherung meines Leap 15.6 genommen und erneut ein Upgrade nach Leap 16.0 durchgeführt. auch da habe ich beim opensuse-migration-tool bei dem zum Schluss angebotenen Security Wechsel "selinux" markiert. Erst jetzt ist mir die Meldung "dry-run ...." danach aufgefallen.

    Ich prüfe das noch einmal und vergleiche mit der Anleitung für die Aktivierung von selinux.

    apparmor aus der Vorgängerversion ist auch noch vorhanden aber nicht aktiv.

    Für den Inhalt des Beitrages 325554 haftet ausdrücklich der jeweilige Autor: buabe

  • Bei zwei Sachen würde ich vorsichtig sein:


    tar richtet sich normalerweise nach den Usernamen und nicht nach deren Nummern. So kommen die Dateien von "otto" des einen Rechners zu "otto" des anderen Rechners auch wenn die bei den beiden verschiedene Nummern haben. Wenn aber die Datei mit der Nummernzuordnung (/etc/passwd) mit gespeichert wird, wird die Sache hinterlistig. Dann sollte man bei tar den Parameter "--numeric-owner" benutzen.


    "rm -rf *" entfernt meines Wissens nicht die mit "." anfangenden Dateien.

    Es ist genau mein Ziel, das Linuxs-System mit allen Userinformationen zu duplizieren, damit die Daten für einen bestimmten Benutzer auf allen Rechnern ihm gehören. Mir ist das bewusst und ich sichere daher mit "tar cpf" um alle permission mitzunehmen.

    Den "rm -rf *" führe ich unter root aus. Dort zeigt ein "ls -l" automatisch auch "hidden" Dateien und Verzeichnisse an. Er scheint hier tatsächlich alles zu löschen.

    Für den Inhalt des Beitrages 325555 haftet ausdrücklich der jeweilige Autor: buabe

  • Ich weiß nicht, ob das migration-tool inzwischen geändert wurde, aber als ich es vor einiger Zeit mehrfach genutzt habe, verlief die Umstellung von apparmor zu selinux jedes Mal fehlerhaft.

    Ich bin dann zunächst bei apparmor gebliegen und habe erst nach dem upgrade auf 16.0 auf selinux umgestellt.

    Für den Inhalt des Beitrages 325556 haftet ausdrücklich der jeweilige Autor: luigi

  • Mittlerweile habe ich, Dank eurer Tipps, das System auch nach Restore aus meinem tar-Archiv wieder in ein lauffähiges System bekommen. Die Falle, in der ich war, war tatsächlich die Sicherheit, die SELinux mitbringt.

    In der chroot Umgebung muss, wenn das System restored wird folgendes durchgeführt werden um die SELinux Sicherheit zu korrigieren.


    Edit von /etc/selinux/config und SELINUX auf "permissive" setzen

    und nach Anpassung der /etc/fstab

    Code
    mount -a
    update-bootloader
    dracut --regenerate-all --force
    touch /.autorelabel
    yast bootloader

    Beim ersten Boot muss der Bootstring editiert werden. Beim grub-Menu mittels "e" den Editor starten und an der Stelle wo enforcing=1 steht, die "1" durch eine "0" ersetzt werden und durch drücken von F10 den Boot durchführen.

    Wenn das System nun läuft muss in /etc/selinux/config "permissive" wieder durch "enforcing" ersetzt werden.

    Ab dem nächsten Boot ist das System wieder sicher.

    3 Mal editiert, zuletzt von buabe () aus folgendem Grund: versehentlich zu früh abgeschickt Tippfehler fehlend Informationen ergämnzt

    Für den Inhalt des Beitrages 325569 haftet ausdrücklich der jeweilige Autor: buabe

  • Damit ist auch eine tar-Sicherung eines SELinux geschützten System aus der Sicherung wiederherstellbar bzw. transportabel auf andere Rechner.

    Für den Inhalt des Beitrages 325689 haftet ausdrücklich der jeweilige Autor: buabe