October 2020 - openSUSE Users (Deutsch)

Fenster kommt beim Überfahren mit der Maus automatisch in den Vordergrund - wie abstellen?
by Jürgen Hochwald 12 May '21

12 May '21

Hallo, ich habe hier ein Problem, welches mich tierisch nervt: Das Programmfenster der Programme - Boinc-Manager - CqrLog kommt automatisch in den Vordergrund, sobald man es mit dem Mauszeiger überstreicht (kein Klick). Ich weiß allerdings nicht, ob das in den Programmen explizit so programmiert ist oder woran das liegt. Zumindest kann ich in beiden Programmen keine Einstellung finden, um das abzuschalten. System ist Opensuse Leap 15.1, Oberfläche KDE. Gibt es irgendeine Möglichkeit, den Programmen dieses Verhalten anzugewöhnen ? Jürgen -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe(a)opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner(a)opensuse.org

3 5

Firewalld Dienst defekt auf 15.1
by Andreas Ernst 10 Jan '21

10 Jan '21

Hi, kann das sein, dass die Firewall nicht mehr klappt? iptables -L Chain f2b-dovecot (1 references) target prot opt source destination REJECT all -- 45.142.195.3 anywhere reject-with icmp-port-unreachable Fail2Ban log 2020-04-22 12:02:16,098 fail2ban.filter [22038]: INFO [dovecot] Found 45.142.195.3 - 2020-04-22 12:02:15 2020-04-22 12:02:53,848 fail2ban.filter [22038]: INFO [dovecot] Found 45.142.195.3 - 2020-04-22 12:02:53 2020-04-22 12:03:31,098 fail2ban.filter [22038]: INFO [dovecot] Found 45.142.195.3 - 2020-04-22 12:03:30 2020-04-22 12:04:08,598 fail2ban.filter [22038]: INFO [dovecot] Found 45.142.195.3 - 2020-04-22 12:04:08 2020-04-22 12:04:46,099 fail2ban.filter [22038]: INFO [dovecot] Found 45.142.195.3 - 2020-04-22 12:04:45 2020-04-22 12:04:46,615 fail2ban.actions [22038]: WARNING [dovecot] 45.142.195.3 already banned 2020-04-22 12:05:23,348 fail2ban.filter [22038]: INFO [dovecot] Found 45.142.195.3 - 2020-04-22 12:05:22 2020-04-22 12:06:00,098 fail2ban.filter [22038]: INFO [dovecot] Found 45.142.195.3 - 2020-04-22 12:05:59 2020-04-22 12:06:37,098 fail2ban.filter [22038]: INFO [dovecot] Found 45.142.195.3 - 2020-04-22 12:06:36 2020-04-22 12:07:14,348 fail2ban.filter [22038]: INFO [dovecot] Found 45.142.195.3 - 2020-04-22 12:07:14 2020-04-22 12:07:51,348 fail2ban.filter [22038]: INFO [dovecot] Found 45.142.195.3 - 2020-04-22 12:07:50 2020-04-22 12:07:51,653 fail2ban.actions [22038]: WARNING [dovecot] 45.142.195.3 already banned 2020-04-22 12:08:28,599 fail2ban.filter [22038]: INFO [dovecot] Found 45.142.195.3 - 2020-04-22 12:08:28 2020-04-22 12:09:05,598 fail2ban.filter [22038]: INFO [dovecot] Found 45.142.195.3 - 2020-04-22 12:09:05 Kann das jemand noch bestätigen? Grüße Andreas -- ae | Andreas Ernst | IT Spektrum Postfach 5, 65612 Beselich Schupbacher Str. 32, 65614 Beselich, Germany Tel: +49-6484-91002 Fax: +49-6484-91003 ae(a)ae-online.de | www.ae-online.de www.tachyon-online.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe(a)opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner(a)opensuse.org

3 11

Tumbleweed : USB
by Karl Brandt 22 Dec '20

22 Dec '20

ich bins mal wieder: Ich habe ein ADALM-PLUTO (SDR-Device) erworben. Nur leider bekomme ich das Teil einfach nicht eingebunden. lsusb, udevadm monitor, ... zeigen das Gerät nicht an. Mit dmesg sehe ich folgnde Meldungen: .. [ 1461.405836] usb usb1-port6: attempt power cycle [ 1462.056002] usb 1-6: new high-speed USB device number 22 using xhci_hcd [ 1462.077911] usb 1-6: Dual-Role OTG device on non-HNP port [ 1462.078022] usb 1-6: set a_alt_hnp_support failed: -32 [ 1462.204002] usb 1-6: new high-speed USB device number 23 using xhci_hcd [ 1462.225899] usb 1-6: Dual-Role OTG device on non-HNP port [ 1462.226033] usb 1-6: set a_alt_hnp_support failed: -32 [ 1462.226098] usb usb1-port6: unable to enumerate USB device Das ich mit diesem Problem nicht allein bin habe ich über google erfahren. Leider habe ich aber keine funktionierende Lösung des Problems gefunden. Der Hersteller analgo-devices meint man könne das Problem lösen: " If you happen to see something like: [ 84.257337] usb usb1-port2: unable to enumerate USB device the solution is to use an external hub and after that all works. " So einen externen Hub habe ich natürlich nicht. Und so ganz glaube ich das auch nicht. Welche magische Wirkung geht von einen Hub aus? Habt ihr eine Lösung? Mit freundlichem Gruß Karl Brandt -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe(a)opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner(a)opensuse.org

4 4

Frage: Lebensdauer openSUSE 15.1
by Stefan Glaser 20 Nov '20

20 Nov '20

Hallo, sind die Angaben auf der deutschen Wikipedia korrekt, dass die Unterstützung für openSUSE 15.1 im kommenden Monat eingestellt wird? -- S. Glaser -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe(a)opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner(a)opensuse.org

13 39

USB- oder Bootproblem nach Update
by Stefan Glaser 19 Nov '20

19 Nov '20

Hallo Liste Carbon X1 (2019er Modell) ThinkPad Ultra Dock open SUSE 15.2 Seit dem Update vom Freitag bootet der Laptop nicht mehr wenn er in dem Dock eingeklinkt ist. Es endet nach 2 oder 3 Sekunden mit usb1-port3: unable to enumerate USB-device Diese Meldung kommt ein paarmal, dann ist Feierabend. Nichts geht mehr. Der Laptop alleine, also nicht im Dock, bootet normal. Es ist nun sehr lästig den jedes mal raus zu nehmen. -- S. Glaser -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe(a)opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner(a)opensuse.org

3 2

KVM, Gastzeit kann nach Upgrade OS15.1 -> 15.2 nicht gesetzt werden
by funedv＠gmx.de 17 Nov '20

17 Nov '20

Hallo, seit dem Upgrade mittels zyyper dup von OS15.1 auf OS15.2 kann ich auf meinen laufenden Gastsystemen die Zeit nicht mehr setzen. Das hat vorher immer zuverlässig funktioniert. Aktuell: Kernel 5.3.18-lp152.41-default qemu-kvm-4.2.1-lp152.9.3.1.x86_64 Seit dem Upgrade gibt es diese Fehlermeldung: ksc140:~ # virsh domtime openSUSE-Leap15.0 --now error: Timed out during operation: cannot acquire state change lock (held by agent=remoteDispatchDomainSetTime) Im Netz bin ich nicht zielführend fündig geworden. Es gibt dazu einen Bugzilla-Report (zwar wegen kaputtem Netzwerk, aber das Zeitproblem ist dort auch beschrieben). Das Zeitproblem tritt auch auf einem anderen Host nachvollziehbar auf. https://bugzilla.opensuse.org/show_bug.cgi?id=1174607 Hat jemand eine Idee dazu? Viele Grüße, Klaus -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe(a)opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner(a)opensuse.org

4 8

kdeinit5 Absturz - Leap 15.2
by Manfred Keller 14 Nov '20

14 Nov '20

Hallo zusammen, seit einigen Tagen bekomme ich, ohne wissentlich was an der Systemumgebung geändert zu haben, außer Aktualisierungen über Yast, den Absturz des Programms "kdeinit5". Dabei kann es sein, dass in der Statusleiste mehrere Abstürze zu sehen sind, die manchmal auch wieder von selbst verschwinden. Das System scheint auch ohne Probleme zu funktionieren. Systeminformationen: uname -a Linux linux-PC 5.9.2-1.g4133ad1-default #1 SMP Thu Oct 29 10:16:52 UTC 2020 (4133ad1) x86_64 x86_64 x86_64 GNU/Linux KDE-Plasma-Version: 5.18.5 KDE-Frameworks-Version: 5.71.0 Qt-Version: 5.12.7 Sollten noch weitere Systeminformationen fehlen bitte Bescheid geben, so dass ich diese nachliefern kann. Vielen Dank für erhellende Hinweise, wo da was schief läuft. Folgende Entwickler-Informationen werden angezeigt, mit denen ich nichts anfangen kann. Application: kdeinit5 (kdeinit5), signal: Bus error Using host libthread_db library "/lib64/libthread_db.so.1". [KCrash Handler] #4 mdb_node_search (mc=mc@entry=0x563bf09bf3d0, key=key@entry=0x7ffe51564e10, exactp=exactp@entry=0x7ffe51564aec) at mdb.c:5149 #5 0x00007fe6a43164d1 in mdb_page_search_root (mc=mc@entry=0x563bf09bf3d0, key=key@entry=0x7ffe51564e10, flags=flags@entry=0) at mdb.c:5326 #6 0x00007fe6a431678e in mdb_page_search (mc=mc@entry=0x563bf09bf3d0, key=key@entry=0x7ffe51564e10, flags=flags@entry=0) at mdb.c:5477 #7 0x00007fe6a4316e55 in mdb_cursor_set (mc=mc@entry=0x563bf09bf3d0, key=key@entry=0x7ffe51564e10, data=data@entry=0x0, op=op@entry=MDB_SET_RANGE, exactp=exactp@entry=0x0) at mdb.c:5934 #8 0x00007fe6a4315758 in mdb_cursor_get (mc=0x563bf09bf3d0, key=key@entry=0x7ffe51564e10, data=data@entry=0x0, op=op@entry=MDB_SET_RANGE) at mdb.c:6174 #9 0x00007fe6a4a69f2d in Baloo::PostingDB::fetchTermsStartingWith (this=this@entry=0x7ffe51564e90, term=...) at /usr/src/debug/baloo5-5.71.0-lp152.1.1.x86_64/src/engine/postingdb.cpp:137 #10 0x00007fe6a4a70b30 in Baloo::Transaction::fetchTermsStartingWith (this=this@entry=0x7ffe51564ef0, term=...) at /usr/src/debug/baloo5-5.71.0-lp152.1.1.x86_64/src/engine/transaction.cpp:186 #11 0x00007fe6a51e632c in Baloo::TagListJob::start (this=0x563bf09bdef0) at /usr/src/debug/baloo5-5.71.0-lp152.1.1.x86_64/src/lib/taglistjob.cpp:59 #12 0x00007fe6b37d364e in KJob::exec (this=0x563bf09bdef0) at /usr/src/debug/kcoreaddons-5.71.0-lp152.1.1.x86_64/src/lib/jobs/kjob.cpp:183 #13 0x00007fe6a540d587 in Baloo::TagsProtocol::parseUrl (this=this@entry=0x7ffe51565320, url=..., flags=...) at /usr/src/debug/baloo5-5.71.0-lp152.1.1.x86_64/src/kioslaves/tags/kio_tags.cpp:335 #14 0x00007fe6a540f7ba in Baloo::TagsProtocol::listDir (this=0x7ffe51565320, url=...) at /usr/src/debug/baloo5-5.71.0-lp152.1.1.x86_64/src/kioslaves/tags/kio_tags.cpp:56 #15 0x00007fe6ac05219d in KIO::SlaveBase::dispatch (this=0x7ffe51565330, command=71, data=...) at /usr/src/debug/kio-5.71.0-lp152.2.9.1.x86_64/src/core/slavebase.cpp:1256 #16 0x00007fe6ac052c06 in KIO::SlaveBase::dispatchLoop (this=0x7ffe51565330) at /usr/src/debug/kio-5.71.0-lp152.2.9.1.x86_64/src/core/slavebase.cpp:338 #17 0x00007fe6a5412d65 in kdemain (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/baloo5-5.71.0-lp152.1.1.x86_64/src/kioslaves/tags/kio_tags.cpp:482 #18 0x0000563beebc78bf in launch (argc=4, _name=0x563bf09a2d38 "/usr/lib64/qt5/plugins/kf5/kio/tags.so", args=<optimized out>, cwd=<optimized out>, envc=<optimized out>, envs=<optimized out>, reset_env=false, tty=0x0, avoid_loops=false, startup_id_str=0x563beebca313 "0") at /usr/src/debug/kinit-5.71.0-lp152.1.1.x86_64/src/kdeinit/kinit.cpp:708 #19 0x0000563beebc8aec in handle_launcher_request (sock=8, who=<optimized out>) at /usr/src/debug/kinit-5.71.0-lp152.1.1.x86_64/src/kdeinit/kinit.cpp:1146 #20 0x0000563beebc945f in handle_requests (waitForPid=0) at /usr/src/debug/kinit-5.71.0-lp152.1.1.x86_64/src/kdeinit/kinit.cpp:1339 #21 0x0000563beebc442c in main (argc=5, argv=<optimized out>) at /usr/src/debug/kinit-5.71.0-lp152.1.1.x86_64/src/kdeinit/kinit.cpp:1777 [Inferior 1 (process 8478) detached] VG Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe(a)opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner(a)opensuse.org

2 3

leap 15.1 upgrade auf leap 15.2: check_dhcp Ergebnisse nicht mehr korrekt
by Mark Wenzel 03 Nov '20

03 Nov '20

Hallo zusammen, ich habe hier ein seltsames Verhalten nach dem Upgrade von leap 15.1 auf leap 15.2. Zum Verständnis: Ich habe drei Maschinen in diesem Szenario: 1. primärer DHCP-Server 192.168.23.10 (physischer Host) 2. sekundärer DHCP-Server 192.168.23.11 (physischer Host) 3. Icinga2-Server zur Systemüberwachung 192.168.23.21 (virtuelle Maschine unter VirtualBox; wahlweise auf dem ersten oder zweiten physischen Host). Der Icinga2-Server prüft regelmäßig beide dhcp-Server über das Plugin check_dhcp (aus monitoring-plugins-dhcp vom Haupt-Repository). Bisherlief icinga2 unter leap 15.1 und hat bei beiden dhcp-Servern zuverlässig funktioniert, egal auf welcher physischen Maschine die VM lief. Gestern habe ich den icinga2-server auf leap 15.2 aktualisiert. Die icinga2-Maschine läuft in diesem Beispiel auf dem ersten Host als virtuelle Maschine. Nun bekomme ich nur noch beim primären Server ein positives Ergebnis. Beim sekundären Server bekomme ich meistens einen critical-Fehler. Manchmal ist das Ergebnis aber auch OK. Ich habe daher das ganz auch mal manuell ausgeführt und dabei das Log des jeweiligen Servers angesehen: icinga2# /usr/lib/nagios/plugins/check_dhcp -s 192.168.23.11 -u CRITICAL: Received 844387 DHCPOFFER(s), 0 of 1 requested servers responded, max lease time = 600 sec. secdhcp# journalctl -u dhcpd -f Okt 30 11:59:02 secdhcp dhcpd[5183]: DHCPDISCOVER from 08:00:27:4b:d1:e5 via eth0 Okt 30 11:59:02 secdhcp dhcpd[5183]: DHCPOFFER on 192.168.23.48 to 08:00:27:4b:d1:e5 via eth0 und icinga2# /usr/lib/nagios/plugins/check_dhcp -s 192.168.23.10 -u OK: Received 945640 DHCPOFFER(s), 1 of 1 requested servers responded, max lease time = 600 sec. pridhcp# journalctl -u dhcpd -f Okt 30 12:01:04 pridhcpdhcpd[19895]: DHCPDISCOVER from 08:00:27:4b:d1:e5 via eth0 Okt 30 12:01:05 pridhcpdhcpd[19895]: DHCPOFFER on 192.168.23.63 to 08:00:27:4b:d1:e5 via eth0 Ein tcpdump auf den beiden dhcp-Servern zeigt, dass die Anfragen beide beantwortet werden, was die Ausgaben im journal bestätigt. Mache ich auf dem icinga-Server einen tcpdump, tauchen dann aber die folgenden Datenpakete auf (Ich habe der besseren Lesbarkeit hier auf IP-Adressen verzichtet). source | destination | Info icinga2 | secdhcp | DHCP Discover pridhcp | icinga2 | DHCP Offer secdhcp | icinga2 | DHCP Offer Icinga2 | secdhcp | DHCP Discover pridhcp | icinga2 | DHCP Offer Warum antwortet der primäre dhcp-Server, wenn doch der sekundäre alleine angesprochen wird? Und warum filtert das Plugin nicht die relevante Antwort heraus? Verschiebe ich den icinga-Server auf den anderen physischen Host, ist das Verhalten genau umgekehrt. Das heißt, dass nur noch der dhcp-Server erfolgreich getestet wird, der auf dem selben physischen Host läuft wie die VM mit icinga2. Um eine Beteiligung der Firewall auszuschließen habe ich die Firewalls temporär auch schon alle ausgeschaltet. Das hat keinen Effekt! Vielen Dank für das Mitdenken und den Schubs in die richtige Richtung. Mark -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe(a)opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner(a)opensuse.org

1 1

Re: verändertes Verhalten der Kontrollleiste nach Updates
by Herbert Albert 01 Nov '20

01 Nov '20

Am Freitag, 30. Oktober 2020, 19:29:11 CET schrieben Sie: > Hallo Herbert, > > Am Freitag 30 Oktober 2020 schrieb Herbert Albert: > > [...] > > > Wie jetzt gerade hatte ich einen Dolphin, einen Firefox und ein > > KMail offen. Der Dolphin hatte kein Icon, nur den Namen des > > Verzeichnisses, Der Firefox hatte das Icon des Dolphins und KMail > > war korrekt. Öffne ich weiter Applikation, stimmt dann oft die > > Zuordnung wieder. > > > > Hat jemand ein ähnliches Verhalten? Mein Plasma Stil ist Oxygen, > > Fensterdekoration Plasma, > > Riecht für mich nach einem Fehler in Oxygen? Klappt es mit einem > anderem Stil? (Wenn Du Deine Deskopeinstellungen nicht riskieren > willst, mach Dir einen anderen User und probiere da rum. Da weißt Du > auch, ob das Problem global ist oder nur einen User trifft. Dann > liegt es leider an dessen individuellen Einstellungen). > > > Helga > > (auch schon viel Abenteuerliches mit KDE erlebt) Hallo Helga, bin gerade dabei das mit einem anderen Plasma-Stil zu testen. Früher hatte ich immer seamless als man noch einzelne Komponenten ändern konnte. Also alles bis auf die Kontrollleiste seamless und diese Oxygen, Hat mir gefallen, aber diese Einstellung wurde irgendwie entfernt. Herbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe(a)opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner(a)opensuse.org

2 5

Akonadi wurde unerwartet beendet
by Stefan Glaser 01 Nov '20

01 Nov '20

Hallo Liste, seit Sonntag (Update) erscheint beim Versuch Kmail zu starten ein kleines Fenster mit dem Inhalt Akonadi wurde unerwartet beendet. Scheiben sie einen Bericht. Was allerdings nicht geht, denn diese Fenster ist blockiert und ich bekomme es nur weg, indem ich mich ab- und wieder anmelde. Was soll das nun schon wieder? -- S. Glaser -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe(a)opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner(a)opensuse.org

11 21