Beiträge von buabe

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

    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.

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

    Zitat von Welm

    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.

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

    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.

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

    Zitat von 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.

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

    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.

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

    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.

  • NFS-Problem mit tumbleweed 20220317

    Sehen wir das mal anders: Ich bin davon ausgegangen, dass in diesem Forum Besonderheiten in der opensuse aufgezeigt werden. Deshalb dachte ich, es wird vielleicht auch von Entwicklern gesehen, dass hier Änderungen im tumbleweed release Auswirkungen auf den Betrieb haben.

    Jetzt wurden z.B. neue Änderungen "vfs" betreffend im kernel untergbracht. Seitdem kommt zumindest wieder eine Antwort auf den ls-Befehl mit der ersten Struktur auf dem Mount wenn der mount mit nfsvers=4.2 erfolgte. Das war bisher nicht der Fall. Beim Versuch in tiefere Strukturen vorzudringen bleibt der ls-Befehl die Antwort schuldig und "hängen".

  • Wie kann ich LVM aktivieren in initrd?

    Meine Beschreibung ist ein wenig kurz. Ich habe das Internet durchsucht, finde aber keine Lösung, lediglich eine halbwegs funktionierend Umgehung.

    Bei opensuse gibt es eine Beschreibung , die initrd mittels "recovery-system" neu zu erstellen. Dabei werden aber nicht alle VGs aktiviert.

    Eine Hilfe zum platzieren des Aktivierungsbefehl habe ich auch nicht in der Literatur zu dracut und mkinitrd gefunden.

    Hat jemand eine Tipp für bessere Quellen oder eine bessere Suche nach Aktivieren von lvm in initrd unter tumbleweed?

    Mit den Fragen, die ich stellen konnte, gibt das Web nichts passendes her.

  • NFS-Problem mit tumbleweed 20220317

    Aus dem QNAP Forum habe ich die Bestätigung, dass die Zusammenarbeit von QNAP-NAS Systemen mit linux-Kernel >= 5.16.10 unter nfs Version 4 nur dann funktioniert, wenn beim mount explizit "nfsvers=4.0" mitgegeben wird. Entweder im mount-Befehl mit "-o nfsvers=4.0" oder im entsprechenden fstab Parameter.

    Bei höheren Versionen funktioniert zwar der mount selbst aber Dateizugriffe sind danach nicht möglich.