Beiträge von Hidalgo

Zitat von luigi

Ich sehe im Moment den Zusammenhang mit btrfs nicht und denke, dass es im gegebenen Fall auch mit den Konsole-Kommandos update-booloader etc. funktioniert.

Das Problem wurde doch nur durch die Parameter von SELinux in der boot-Zeile hervorgerufen. Sobald diese entfernt wurden (was übrigens auch im Falle der Anwendung des Yast-bootloader notwendig war), ließ sich der Rechner mit net.ifnames=0 problemlos booten.

Habe ich zwar im Verlauf anders gesehen, aber man kann das ja jeder Zeit ausprobieren.

Ich habe recherchiert.

Die Bootloader Konfiguration mit Hilfe von Yast2 funktioniert nicht über den einfachen grub-Befehl wie der in der Konsole eingegeben wird, sondern über ein integriertes Framework.

Yast stellt damit u.a. sicher, dass die Variable

SUSE_BTRFS_SNAPSHOT_BOOTING="true" in /etc/default/grub

korrekt gesetzt und ausgewertet wird. Des weiteren führt es zusätzlich Skripte aus, um die btrfs-Bootfähigkeit des aktuellen Systems zu erhalten. Yast2 ist also eng hinsichtlich der btrfs spezifischen Eigenheiten entwickelt/angepasst worden, seit SuSE das btrfs Filesystem übernahm.

Darum funktioniert das mit yast2 und nicht ohne weiteres in der Konsole.

Das wusste ich auch alles nicht. Nur meine Erfahrung mit yast Bootloaderkonfigurationen unter btrfs ließen mich auf diesen "Schuss in den Teich" hinweisen. Wer die Hintergründe verstehen will - so ungefähr - der weiß die jetzt und ich auch. Fragt sich nur, ob zukünftig diese Methode bei späteren Leap-Versionen 'rausfliegt.

Habe noch etwas gefunden:

Man soll unter openSUSE Leap 16 grundsätzlich YaST2 Bootloader oder das Tool sdbootutil verwenden(falls BLS aktiv ist), um die Konfiguration zu aktualisieren, statt manuelle Grub-Befehle verwenden.

Hinweise zu BLS und sdbootutil findet man im Netz (sowieso!).

Dann verstehe ich etwas Grundsätzliches wohl nicht.

Postfix soll die Umbennung so lassen, also bleibt doch nur für die dovecot config (aktuell):

%{user | username | lower}

1. user: Nimmt den vollen Namen (z. B. BananenKiste@meinserver.de).
2. | username: Schneidet die Domain ab (BananenKiste).
3. | lower: Wandelt in Kleinschreibung um (bananenkiste).

und damit landet genau das bei Dovecot an, was in der System-Passwortdatei steht.

Mangels eigenem System bin ich jetzt allerdings 'raus - recherchieren kann jeder selbst.

Ja ist ärgerlich - Dovecot in Leap 16 funktioniert restriktiver. Auch da hat sich leider grundlegend etwas geändert.

Gibt es bei dir in /etc einen Ordner /dovecot/conf.d/ mit einer Konfigurationsdatei dovecot.conf oder 10-auth.conf ?

Bei mir nicht!

Aber für deine Einrichtung könnte so ein Ordner vorhanden sein.

Wenn ja, dann suche mal nach untenstehender Sektion darin

userdb {
  driver = passwd
  # Das Hinzufügen von 'args' kann helfen, 
  # aber oft ist das globale Stripping sauberer:
}

# Erzwingt, dass nur der Teil vor dem @ für den Lookup verwendet wird
auth_username_format = %n

und gebe dort wie oben auth_username_format = %n ein. Vorher natürlich die betreffende Konfigurationsdatei sichern.

Es sollte dann wieder nur "bananenkiste" bei dir berücksichtigt werden.

Ob dann allerdings alles zur Zufriedenheit läuft, klärt nur ein Versuch.

Die Sicherheitsmodule apparmor und / oder SELinux habe ich nie gebraucht und auch nie vermisst.

Somit bleibt bei mir alles so wie's ist.

Diese Diskussion wäre aber ein anderes Thema und das könnte mit Recht Herrn Alero auf den Plan rufen (wäre eine neue Diskussionswurzel).

Ufff ... jetzt geht es ans Eingemachte!

Hier meine Sichtweise, warum es wahrscheinlich nicht klappt mit update-bootloader. Bin für jede bessere Hilfe / Korrektur als meine dankbar!

Leap 16 benutzt doch standartmäßig snapshots wegen btrfs Filesystem. Ein update-bootloader schreibt wahrscheinlich in die Konfiguration des

aktuellen Snapshots!

Grub scheint den Pfad zum aktuellen btrfs subvolume nicht richtig zu finden, erzeugt dann fehlerhafte Konfiguration des Loaders und somit muß auf

"read-only" snapshots ausgewichen werden, was du ja auch gemacht hast.

Die vorgeschlagene Lösung in #14 klappt auch nicht? (Bin jetzt am rotieren....)

Mache ggfs. doch mal folgendes - ja ich verweise jetzt auf yast!

sudo yast2 bootloader

Das funktioniert nämlich noch unter Leap 16!

Gehe oben zum Reiter "Kernel-Parameter" und füge dort bei "Optionaler Parameter für Kernel-Befehlszeile"

net.ifnames=0

hinzu und speichere das mit ok.

Yast sorgt dann für ordnungsgemäßes aktualisieren des aktuellen Bootloaders - auch bei btrfs, denn weil das in der Vergangenheit bei btrfs bei mir (allerdings nicht bei Netzwerkproblemen probiert) klappte, ist das mal einen Versuch wert. Parameter wurden immer übernommen im aktuellen laufenden btrfs-System.

Zitat von Sauerland

Das macht update-bootloader aber bei allen installierten Kerneln.

Und soweit ich weiß auch bei grub-bls, der ja nicht mehr auf /boot/grub/grub.cfg aufsetzt.

Stimmt! Und wieder schlauer ...

Deine "anderen Rechner" haben höchstwahrscheinlich 32 bit Support.

Schließe mich #2 an.

Das Migrationstool hat also tatsächlich Mist gebaut.

Macht aber nix:

sudo nano /etc/default/grub

Zeile suchen:

GRUB_CMDLINE_LINUX_DEFAULT

und dort am Ende zwischen den Anführungszeichen


net.ifnames=0 biosdevname=0

einfügen.

Dann

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

und System neu starten.

Hab' grade gesehen es wurde schon geantwortet - such' dir halt was aus.

Meine VM für Leap 15.6 und Vorversionen lief unter Windows 10. Aber seit langem nutze ich keine VM mehr und gönne Linux einen eigenen Rechner.

Das Problem bei dir vermute ich im Upgrade auf Leap 16 unabhängig von der VM.

Ohne jetzt zu sehr auf Details einzugehen: Wicked läuft aus und Networkmanager ist jetzt Standart.

Hattest Du vorher Wicked in Leap 15.6?

Falls ja:

Dann kann es sein, dass die Anpassung für die br0 (Bridge) nicht richtig angepasst wurde.

Das Migrationstool stellt die Netzwerkverwaltung nämlich meines Wissens(!) um bei Upgrade auf Leap 16

Das müsste dann mit

systemctl status NetworkManager

herauszufinden sein. Fehlt dort die br0 in der Meldung?

Falls Du aber auch schon vorher den Networkmanager gewählt hattest, kann es sein, dass das Migrationstool fehlerhaft gearbeitet hat (ist ja noch in der Erfahrungs/Experimentierphase), auch wenn es allgemein relativ gut arbeitet.

Wenn also das Migrationstool Schnittstellen umbenennt, dann kann die Bridge funktionsunfähig werden wenn auf ein nicht existentes Gerät verwiesen wird.

Was war deine Schnittstelle vorher? Eth0?

Wie heißt die jetzt? Falls anders, haben wir den Fehler (denke ich!)

Das müsste man herausfinden können mit:

ip link show

So würde ich in deinem Fall suchen - Basis dazu sind können immer nur meine eigenen Erfahrungen Stand jetzt sein.

Könnte sein, dass wieder jemand um die Ecke kommt und sagt: Warum so und nicht so - darauf habe ich ehrlich keinen Bock!

Viel Erfolg!

Nun fällt mir noch etwas ein:

Mit "nmtui" siehe #3 kannste verwaiste bridges löschen und eine neue einrichten ...

die sollte dann wohl "br0" genant werden.