Beiträge von bellofant

Hallo Bananenkiste,

ich hab damals beim Upgrade auf Leap 15.3 auf dovecot umgestellt, nachdem das hier empfohlen wurde.

Läuft so weit astrein

Schöne Grüße,

bellofant

Hallo highb,

nur mal so ein Schuss ins Blaue:

ich vermute, dass 50% der Klasse tatsächlich eine ftp-Verbindung aufbaut, diese 50% müssen dann nicht sftp:// im FileZilla eingeben und "unterhalten" sich tatsächlich mit vsftpd. Für diese 50% gelten somit auch die dort konfigurierten Einstellungen, also z.b. die chroot-Umgebung, etc.

Die andere Hälfte gibt sftp:// ein, baut also eine sftp-Verbindung auf und spricht somit mit sshd. Dem sshd ist die vsftpd-Konfiguration wiederum egal, somit können die user wenn am System nicht anders vorgegeben bis nach / navigieren.

Das wär' mal so meine Hypothese, vielleicht hilft das ja weiter. Sollte also wirklich eine unverschlüsselte ftp-Verbindung gewünscht sein, dann muss erstmal sichergestellt werden, dass alle Clients auch eine ftp-Verbindung aufbauen. Möglicherweise haben die Clients da etwas dagegen, vielleicht akzeptiert aber auch vsftpd in der default-Konfiguration nur eine begrenzte Anzahl gleichzeitiger Verbindungen (verwende schon ewig kein ftp mehr...), an diesen beiden Stellen würde ich mal zu suchen beginnen...

Hoffe das hilft Dir weiter,

bellofant

Hallo zusammen,

ich hatte ähnliches im Sinn

Im Oktober 2020 habe ich von Leap auf Tumbleweed gewechselt, weil das zu dem Zeitpunkt die einzige Möglichkeit war, meine Renoir-GPU in 4K ans Laufen zu bekommen, siehe hier.

Jetzt wo Leap 15.3 vor der Türe steht wollte ich dahin gerne zurück wechseln (ich habe meine Gründe, die müssen wir hier nicht diskutieren, das kann ja jeder so sehen wie er möchte).

Der "übliche" Weg mit dem Austausch der repositories und einem beherzten "zypper dup" hat nicht funktioniert, ein gleichzeitiger downgrade von rpm und glibc im laufenden Betrieb geht eben nicht - das ist verständlich.

Das hat schon vor mir jemand erkannt und hier dokumentiert: LINK

Ich habe dann im nächsten Versuch das aktuelle Net-Inst-Image von Leap 15.3 heruntergeladen und auf einen USB-Stick gebügelt, und dann von diesem USB gebootet.

Hier im Bootmenü "Update" (oder Upgrade??) wählen, nicht Installation!

Nach dem Initialisieren und der Willkommensmeldung kommt man dann der Dialog zum Update. Hier sollte man aus einer Liste der erkannten Linux-Installation diejenige auswählen, die upgedatet werden soll. Diese Liste war bei mir leer. Rechts unten gibt's aber einen Button für "alle Partitionen listen" oder "Expert" oder so, damit kann man alle Partitionen im System anzeigen lassen.

Ich habe dann die root-Partition der Tumbleweed-Installation ausgewählt, es kommt noch eine Warnung, dass diese Upgrade-Prozedur Tumbleweed --> Leap 15.3 nicht kompatibel ist und nicht unterstützt wird.

Davon lasse ich mich natürlich nicht abhalten und mache weiter

Es sind dann einige Konflikte zu lösen (wegen vendor-change) bei denen manuell der Wechsel von z.b. packman auf suse bestätigt werden muss. Nach 10 Minuten war ich dann durch die Liste der Konflikte durch und habe das Update schliesslich gestartet.

Tja, was soll ich sagen, nach dem abschliessenden Reboot startet ein wunderschönes Leap 15.3 RC, sieht so weit mal alles gut aus, die wichtigsten Einstellungen und Programme (mit einer Ausnahme: Firefox, dazu weiter unten...) funktionieren nahtlos weiter so wie bisher (inkl. Virtualbox, usw).

Auch die Renoir GPU wird in Leap 15.3 automatisch erkannt, 4K Ausgabe ist kein Problem - so wünsche ich mir das!

Zwar wird beim ersten Start noch der Tumbleweed-Kernel geladen (weil neuer), im Bootmenü kann aber einfach der Leap-Kernel ausgewählt werden und wenn das System dann so gestartet ist, können die kernel-versionen von Tumbleweed mittels zypper rm deinstalliert werden, dann startet Leap in Zukunft immer mit dem eigenen kernel

Nach dem ersten boot musste ich als user noch meine firefox-profile downgraden:

dazu muss firefox einmalig von der commandline gestartet werden, mit

firefox -p --allow-downgrade

Alles in allem: Operation gelungen, Patient lebt

ACHTUNG: bei solchen Aktionen NIE auf Backups vergessen/verzichten, sonst gibt's evtl. keinen Weg zurück...

Hi Gerd,

das ist jetzt aus den Tiefen des Langzeitgedächtnisses, also ohne Gewähr

#root Partition mounten:
mount /dev/hda2 /mnt #falls hda2 die root-partition ist...
#ggf. boot usw. mounten, kannst Du mit cat /mnt/etc/fstab checken.
mount /dev/hdXY /mnt/boot
#jetzt kommt proc und dev dran:
mount -o bind /dev /mnt/dev
mount -o bind /proc /mnt/proc
#gabs da schon /sys? ich glaube nicht. Falls doch:
mount -o bind /sys /mnt/sys

#ins System chrooten:
chroot /mnt

#und grub installieren (da bin ich nicht sicher, grub1 ist schon lange her)
#an der Stelle kannst Du aber auch YaST (Kommando: yast) auf der Konsole verwenden, wenn es nicht klappen sollte
grub-install --recheck /dev/hda  #für den MBR

#chroot verlassen
exit

#diverses Zeug unmounten
umount /mnt/sys
umount /mnt/proc
umount /mnt/dev
umount /mnt/boot
...
umount /mnt

#und jetzt eine beherztes reboot

Hoffe das hilft weiter,

bellofant

Und ein letztes mal:

ich hab' in Post #15 offensichtlich nicht alles korrekt wiedergegeben. Es wird nicht xcmddc gepatcht, sondern der Kernel.

Und bevor ich weiteren Unsinn verzapfe zitiere ich lieber den Meister, da kann man nix falsch machen:

Takashi Iwai:

I submitted the fix patches to upstream, and backported to openSUSE master branch, which will be merge to stable branch for TW update later.

The submitted series:  https://lore.kernel.org/amd-gfx/20201023074656.11855-1-tiwai@suse.de/

Hi Emre ,

also ich bin nicht sicher, ob ich das Problem jetzt richtig erfasse, aber:

Wenn Du Dein "home" mit z.B: luks verschlüsselt hast, dann liegt da irgenwdo auf Deiner Platte (hoffentlich) noch der verschlüsselte Container herum.

Das /home-Verzeichnis bleibt so lange leer, bis dieser Container mittels cryptsetup luksOpen dorthin gemountet wird.

Früher hat das dein Betriebssystem beim Booten für Dich im Hintergrund erledigt, die Live-Distros wissen davon erstmal nichts und unternehmen daher auch nichts in die Richtung.

Kannst Du von den diversen live-Medien noch auf die ehemalige bzw. verwaiste root-partition zugreifen?

Falls ja wie sieht denn da die /etc/crypttab und die /etc/fstab aus? Dort sollte drin stehen, wo Dein Container physisch liegt/lag...

Gutes gelingen,

bellofant

Hm, das hat bei mir so genügt.

Ändere mal den Timeout um +/-1 Sekunde (damit sich auch sicher etwas ändert) und schreibe die Konfiguraton aus yast heraus neu, vielleicht hilft das.

Ein Problem könnte evtl. auch sein, dass z.B. Linux (und damit auch grub) im BIOS-mode, Windows aber im EFI-mode installiert wurde (oder umgekehrt).

Hi Omegator ,

also zumindest unter Leap 15.2 ist diese Option am 3. Tab (Bootloader-Optionen) vom Modul Bootloader versteckt:

Hallo nocheinmal,

also wenn ich im Bug-Report jetzt alles richtig verstanden habe, dann war/ist das Problem das folgende:

Das Programm xcmddc (aus dem Paket xcm) wird wohl beim Boot via udev aufgerufen. Kommt es dabei zu mehreren gleichzeitigen Zugriffen per gpio (z.b. setzen/auslesen der EDID Tabelle des Displays), so wird eine kernel-warnung getriggert. Durch eine ungünstige Konstellation im Kernel führen diese gleichzeitig getriggerten warnings zur kernel-panic.

So wie ich das interpretiere ist der vorgeschlagene fix nun, das xcmddc-Programm zu reparieren, um diese gleichzeitigen Zugriffe abzufangen bzw. anders aufzurufen, um dieses Problem in Zukunft zu vermeiden.

Als Workaround lässt sich das Problem durch simples Deinstallieren von xcm beheben (sofern nicht benötigt), dann können ganz normal die Kernel aus TW, kernel:stable oder kernel:head verwendet werden. Alternativ kann ein Kernel 5.7.x oder älter eingesetzt werden, der verträgt sich scheinbar auch mit xcm.

Oder man verwendet den kernel 5.9.1 von hier: https://download.opensuse.org/…wai:/bsc1177973/standard/ bis xcm gefixt wurde...

Danke nochmal an alle, schöne Grüße,

bellofant

Zitat von Sauerland

Wenn einer helfen kann, dann Takashi Iwai.

Hi,

ja, der Typ ist echt der Wahnsinn. Ich bastel da 2 Monate herum und versuche den Fehler einzugrenzen oder irgendwie zu "ergoogeln", er schaut mal einen Augenblick auf ein unscharfes Foto meiner Logmeldungen, haut einen neuen Kernel raus und Bingo

So einen Support hab' ich echt noch nie erlebt (so schnell + positiv), da könnten sich einige (auch die ganz grossen) kommerzielle Anbieter ein Beispiel nehmen!

Hier im Forum war's um Nichts schlechter, die "Lösung" kam natürlich vom Guru, aber weil ich hier so gut durchbegleitet wurde spende ich da rechts oben jetzt mal

Also nochmal Danke auch hier an alle Beteiligten!

Ich warte noch Takashis nächste Antworten/Nachfragen ab, dann werde ich den Thread auch hier als erledigt markieren...

Schöne Grüße,

bellofant