February 2017 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1008682] New: Login difficulties with LXDM 0.5.3
by bugzilla_noreply＠novell.com 17 Sep '21

17 Sep '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1008682 Bug ID: 1008682 Summary: Login difficulties with LXDM 0.5.3 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: SUSE Other Status: NEW Severity: Critical Priority: P5 - None Component: LXDE Assignee: andrea(a)opensuse.org Reporter: Markus.Elfring(a)web.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I would like to achieve another graphical login with the software “LX Display Manager 0.5.3-1.1”. Unfortunately, I observed that it did not work as expected. -- You are receiving this mail because: You are on the CC list for the bug.

2 1

[Bug 1013687] New: KMail 5.3.0 - search index not being rebuild
by bugzilla_noreply＠novell.com 16 Sep '21

16 Sep '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1013687 Bug ID: 1013687 Summary: KMail 5.3.0 - search index not being rebuild Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: KDE Applications Assignee: opensuse-kde-bugs(a)opensuse.org Reporter: axel.braun(a)gmx.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 704846 --> http://bugzilla.opensuse.org/attachment.cgi?id=704846&action=edit building search index After upgrade of Leap 42.1 to 42.2 and from Kmail 4.14.10 to 5.3.0 the search is not working properly. I tried: akonadictl fsck akonadictl vaccum akonadictl restart. Despite the KMail search always complains that no index is build (see attachment). There is no progress on index building, and search results are frankly speaking wrong -- You are receiving this mail because: You are on the CC list for the bug.

2 24

[Bug 1013550] New: plasmashell freezing
by bugzilla_noreply＠novell.com 16 Sep '21

16 Sep '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1013550 Bug ID: 1013550 Summary: plasmashell freezing Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.2 Hardware: x86-64 OS: SUSE Other Status: NEW Severity: Normal Priority: P5 - None Component: KDE Workspace (Plasma) Assignee: opensuse-kde-bugs(a)opensuse.org Reporter: opensuse(a)mike.franken.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0 Build Identifier: On one of my machines (Lenovo T420 notebook) I have a problem with plasmashell freezing often when a notification is shown. The notification frame shows up, but no content and then the complete desktop freezes. Killing and restarting plasmashell cures the problem for a short time - til one of the the next notifications wants to display something. It doesn't happen for all notifications, though. Using tools like notify-send the problem can not be reproduced, but notifications stemming from plasma-nm and plasma-workspace itself (like the one for a removed plasmoid) always lead to the freeze. The system originally was openSuSE Leap 42.2, but because of the problem I upgraded step by step to - the latest kernel from the kernel stable repo, - the latest X server plus everyting from the X11:Xorg repo - and the latest plasma workspace including everything from the KDE:Framework5 repo. The problem remained unchanged, though. A few more facts: - The X server is xf86-video-intel. - Switching off the compositor doesn't help either. - Everything worked with Leap 42.1 - No according entry in the journal or .xsession-errors* can be found. - And a curiosity: After removing .config/plasmarc and restarting plasmashell the problem vanishes for a few hours or even a day, before it comes back. - Logging off or restarting the machine doesn't help in case the problems exists at that time. In found a few bug reports for plasma freezes, but none of them seems to fit exactly. Reproducible: Sometimes Steps to Reproduce: 1. unlock widgets 2. remove widget 3. a notification tries to popup 4. plasmashell freezes 1. wait for a plasma-nm notification 2. plasmashell freezes Actual Results: plasmashell freezes Expected Results: plasmashell should not freeze, the notification shoold popup see details -- You are receiving this mail because: You are on the CC list for the bug.

2 43

[Bug 902583] New: Thunderbird fails to connect when launched before Internet connection is up
by bugzilla_noreply＠novell.com 09 Sep '21

09 Sep '21

http://bugzilla.opensuse.org/show_bug.cgi?id=902583 Bug ID: 902583 Summary: Thunderbird fails to connect when launched before Internet connection is up Classification: openSUSE Product: openSUSE Distribution Version: 13.2 RC 1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Firefox Assignee: bnc-team-mozilla(a)forge.provo.novell.com Reporter: sb56637(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Hi, I have noticed that if I launch Thunderbird before my network connection is up (NetworkManager WiFI connection), it will fail to connect even after the network comes up. The only way to make it connect is by closing all instances and restarting Thunderbird. This appears to be related to Bug 90258. Thanks for looking into this! -- You are receiving this mail because: You are on the CC list for the bug.

2 6

[Bug 1010186] New: Kdenlive locks up when trying to add new clips
by bugzilla_noreply＠novell.com 29 Aug '21

29 Aug '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1010186 Bug ID: 1010186 Summary: Kdenlive locks up when trying to add new clips Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: SUSE Other Status: NEW Severity: Normal Priority: P5 - None Component: KDE Applications Assignee: opensuse-kde-bugs(a)opensuse.org Reporter: neil(a)behindburlesque.co.uk QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- When trying to add clips to an existing project, Kdenlive locks up or crashes. This happens regularly, but not always. Detail: Open an existing project Remove item on timeline - see note below Click dropdown to add clip to project Dialog opens and application often locks up before anything else can be clicked Alternatively, application sometimes crashes without opening the dialog at all Note This seems to be more prone to happening after removing an item from the timeline -- You are receiving this mail because: You are on the CC list for the bug.

2 1

[Bug 909111] New: The rescan-scsi-bus.sh from the sgutils package is broken since SuSE-13.1
by bugzilla_noreply＠novell.com 26 Aug '21

26 Aug '21

http://bugzilla.opensuse.org/show_bug.cgi?id=909111 Bug ID: 909111 Summary: The rescan-scsi-bus.sh from the sgutils package is broken since SuSE-13.1 Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: x86-64 OS: openSUSE 13.2 Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: dmarkh(a)cfl.rr.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0 Build Identifier: This script no longer "finds new" or "removes no longer attached" scsi devices. As shown below, I have a scsi disk at scsi ID-0 at /dev/sg5. # lsscsi -g [0:0:0:0] disk ATA ST3320620AS K /dev/sda /dev/sg0 [13:0:0:0] process Marvell 91xx Config 1.01 - /dev/sg1 [16:0:0:0] disk IMPRIMIS 94601-15 4614 /dev/sdd /dev/sg5 [17:0:0:0] cd/dvd LITE-ON DVDRW LH-20A1P KL0G /dev/sr0 /dev/sg2 [18:0:0:0] disk ATA ST3160811AS E /dev/sdb /dev/sg3 [18:0:1:0] disk ATA ST3160815AS B /dev/sdc /dev/sg4 I remove the drive at scsi ID-0 drive and install an additional drive at scsi ID-1 then run the script. # rescan-scsi-bus.sh Scanning SCSI subsystem for new devices Scanning host 0 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning for device 0 0 0 0 ... OLD: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: ATA Model: ST3320620AS Rev: K Type: Direct-Access ANSI SCSI revision: 05 Scanning host 1 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning host 2 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning host 3 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning host 4 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning host 5 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning host 6 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning host 7 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning host 8 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning host 9 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning host 10 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning host 11 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning host 12 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning host 13 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning for device 13 0 0 0 ... OLD: Host: scsi13 Channel: 00 Id: 00 Lun: 00 Vendor: Marvell Model: 91xx Config Rev: 1.01 Type: Processor ANSI SCSI revision: 05 Scanning host 14 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning host 15 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning host 16 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning for device 16 0 0 0 ... OLD: Host: scsi16 Channel: 00 Id: 00 Lun: 00 Vendor: IMPRIMIS Model: 94601-15 Rev: 4614 Type: Direct-Access ANSI SCSI revision: 01 Scanning host 17 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning for device 17 0 0 0 ... OLD: Host: scsi17 Channel: 00 Id: 00 Lun: 00 Vendor: LITE-ON Model: DVDRW LH-20A1P Rev: KL0G Type: CD-ROM ANSI SCSI revision: 05 Scanning host 18 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs Scanning for device 18 0 0 0 ... OLD: Host: scsi18 Channel: 00 Id: 00 Lun: 00 Vendor: ATA Model: ST3160811AS Rev: E Type: Direct-Access ANSI SCSI revision: 05 Scanning for device 18 0 1 0 ... OLD: Host: scsi18 Channel: 00 Id: 01 Lun: 00 Vendor: ATA Model: ST3160815AS Rev: B Type: Direct-Access ANSI SCSI revision: 05 0 new or changed device(s) found. 0 remapped or resized device(s) found. 0 device(s) removed. # lsscsi -g [0:0:0:0] disk ATA ST3320620AS K /dev/sda /dev/sg0 [13:0:0:0] process Marvell 91xx Config 1.01 - /dev/sg1 [16:0:0:0] disk IMPRIMIS 94601-15 4614 /dev/sdd /dev/sg5 [17:0:0:0] cd/dvd LITE-ON DVDRW LH-20A1P KL0G /dev/sr0 /dev/sg2 [18:0:0:0] disk ATA ST3160811AS E /dev/sdb /dev/sg3 [18:0:1:0] disk ATA ST3160815AS B /dev/sdc /dev/sg4 It not only did not remove the one at ID-0 that was removed, but did not find the new one attached. Below is an "lsscsi -g" after a reboot with BOTH drives attached. #lsscsi -g [0:0:0:0] disk ATA ST3320620AS K /dev/sda /dev/sg0 [13:0:0:0] process Marvell 91xx Config 1.01 - /dev/sg1 [16:0:0:0] disk IMPRIMIS 94601-15 4614 /dev/sdd /dev/sg5 [16:0:1:0] disk IMPRIMIS 94601-15 4614 /dev/sde /dev/sg6 [17:0:0:0] cd/dvd LITE-ON DVDRW LH-20A1P KL0G /dev/sr0 /dev/sg2 [18:0:0:0] disk ATA ST3160811AS E /dev/sdb /dev/sg3 [18:0:1:0] disk ATA ST3160815AS B /dev/sdc /dev/sg4 Reproducible: Always Steps to Reproduce: 1. See details 2. 3. Actual Results: This script, before SuSE-13.1 would remove any disks physically removed and add any physically added since boot. It is broken This is NOT kernel related as the same thing happens with a vanilla 3.16.7 kernel. I'm fairly certain this is a systemd issue. -- You are receiving this mail because: You are on the CC list for the bug.

2 16

[Bug 927832] New: libreoffice does not discover printers in client only mdns setup
by bugzilla_noreply＠novell.com 18 Aug '21

18 Aug '21

http://bugzilla.suse.com/show_bug.cgi?id=927832 Bug ID: 927832 Summary: libreoffice does not discover printers in client only mdns setup Classification: openSUSE Product: openSUSE Factory Version: 201503* Hardware: Other OS: Other Status: NEW Severity: Major Priority: P5 - None Component: LibreOffice Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: lnussel(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- libreoffice only offers "Generic Printer" when run without cupsd. Printers can be discovered nevertheless using mdns and e.g. evince works fine. LO probably needs to be compiled to use the new cups 1.6 APIs: http://www.cups.org/documentation.php/doc-2.0/api-cups.html#cupsEnumDests -- You are receiving this mail because: You are on the CC list for the bug.

2 5

[Bug 1026449] New: vagrant fails configuring VM network
by bugzilla_noreply＠novell.com 09 Aug '21

09 Aug '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1026449 Bug ID: 1026449 Summary: vagrant fails configuring VM network Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: Other OS: openSUSE 42.1 Status: NEW Severity: Normal Priority: P5 - None Component: Virtualization:Other Assignee: virt-bugs(a)suse.de Reporter: dennis.keck(a)rock5.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Using 1.9.1-9.1-x86_64 from Virtualization When using vagrant up for a Ubuntu VM with configured "vm.network" this error occurs: /usr/share/vagrant/plugins/guests/debian/cap/configure_networks.rb:3:in `require_relative': cannot load such file -- /usr/share/vagrant/plugins/guests/debian/cap/vagrant/util/template_renderer (LoadError) This happens because of a wrongly set require_relative which is still just like it should be when using vagrant as a rubygem. See this bugreport on the Debian bug mailing list: https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1449666.h… This change should be applied to all distribution specific configure_networks.rb templates. Full error output: /usr/share/vagrant/plugins/guests/debian/cap/configure_networks.rb:3:in `require_relative': cannot load such file -- /usr/share/vagrant/plugins/guests/debian/cap/vagrant/util/template_renderer (LoadError) from /usr/share/vagrant/plugins/guests/debian/cap/configure_networks.rb:3:in `<top (required)>' from /usr/share/vagrant/plugins/guests/debian/plugin.rb:15:in `require_relative' from /usr/share/vagrant/plugins/guests/debian/plugin.rb:15:in `block in <class:Plugin>' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/registry.rb:27:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/registry.rb:27:in `get' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/capability_host.rb:170:in `block in capability_module' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/capability_host.rb:164:in `each' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/capability_host.rb:164:in `capability_module' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/capability_host.rb:92:in `capability' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/guest.rb:43:in `capability' from /usr/share/vagrant/plugins/providers/virtualbox/action/network.rb:133:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/vagrant/plugins/providers/virtualbox/action/clear_network_interfaces.rb:26:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/vagrant/plugins/providers/virtualbox/action/prepare_nfs_settings.rb:18:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builtin/synced_folders.rb:87:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builtin/synced_folder_cleanup.rb:28:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/vagrant/plugins/synced_folders/nfs/action_cleanup.rb:25:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/vagrant/plugins/providers/virtualbox/action/prepare_nfs_valid_ids.rb:12:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builtin/handle_forwarded_port_collisions.rb:49:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/vagrant/plugins/providers/virtualbox/action/prepare_forwarded_port_collision_params.rb:30:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builtin/env_set.rb:19:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builtin/provision.rb:80:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/vagrant/plugins/providers/virtualbox/action/clear_forwarded_ports.rb:15:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/vagrant/plugins/providers/virtualbox/action/set_name.rb:19:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/vagrant/plugins/providers/virtualbox/action/clean_machine_folder.rb:17:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/vagrant/plugins/providers/virtualbox/action/check_accessible.rb:18:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:95:in `block in finalize_action' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builder.rb:116:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/runner.rb:66:in `block in run' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/util/busy.rb:19:in `busy' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/runner.rb:66:in `run' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builtin/call.rb:53:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:95:in `block in finalize_action' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builder.rb:116:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/runner.rb:66:in `block in run' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/util/busy.rb:19:in `busy' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/runner.rb:66:in `run' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builtin/call.rb:53:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:95:in `block in finalize_action' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builder.rb:116:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/runner.rb:66:in `block in run' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/util/busy.rb:19:in `busy' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/runner.rb:66:in `run' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builtin/call.rb:53:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builtin/box_check_outdated.rb:78:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builtin/config_validate.rb:25:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/vagrant/plugins/providers/virtualbox/action/check_virtualbox.rb:17:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:95:in `block in finalize_action' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:95:in `block in finalize_action' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builder.rb:116:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/runner.rb:66:in `block in run' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/util/busy.rb:19:in `busy' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/runner.rb:66:in `run' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builtin/call.rb:53:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builtin/config_validate.rb:25:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:95:in `block in finalize_action' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:95:in `block in finalize_action' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builder.rb:116:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/runner.rb:66:in `block in run' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/util/busy.rb:19:in `busy' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/runner.rb:66:in `run' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builtin/call.rb:53:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/vagrant/plugins/providers/virtualbox/action/check_virtualbox.rb:17:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builder.rb:116:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/runner.rb:66:in `block in run' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/util/busy.rb:19:in `busy' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/runner.rb:66:in `run' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/machine.rb:225:in `action_raw' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/machine.rb:200:in `block in action' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/environment.rb:533:in `lock' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/machine.rb:186:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/machine.rb:186:in `action' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/batch_action.rb:82:in `block (2 levels) in run' -- You are receiving this mail because: You are on the CC list for the bug.

2 1

[Bug 977987] New: Kernel NULL pointer dereference crash from "t-daemon"
by bugzilla_noreply＠novell.com 03 Aug '21

03 Aug '21

http://bugzilla.suse.com/show_bug.cgi?id=977987 Bug ID: 977987 Summary: Kernel NULL pointer dereference crash from "t-daemon" Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Critical Priority: P5 - None Component: Kernel Assignee: kernel-maintainers(a)forge.provo.novell.com Reporter: lmb(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- The current tumbleweed kernel crashes for me on boot - it continues to run, but the OS hangs in random places. Going back to 4.4.3 and system is stable. Kernel details: kernel-default-4.5.0-3.3.x86_64 Source Timestamp: 2016-03-28 09:27:57 +0200 GIT Revision: 8cf0ce6b84d58647e9ee955bc81db84023542f5f GIT Branch: stable Distribution: openSUSE Factory Logs with a bit of context: -- Logs begin at Wed 2014-10-01 14:53:05 CEST, end at Mon 2016-05-02 09:54:42 CEST. -- May 02 09:41:16 hermes dbus[1569]: [system] Activating via systemd: service name='org.freedesktop.RealtimeKit1' unit='rtkit-daemon.service' May 02 09:41:16 hermes systemd[1]: Starting RealtimeKit Scheduling Policy Service... May 02 09:41:16 hermes audit: NETFILTER_CFG table=filter family=10 entries=0 May 02 09:41:16 hermes audit: NETFILTER_CFG table=mangle family=10 entries=0 May 02 09:41:16 hermes audit: NETFILTER_CFG table=filter family=2 entries=0 May 02 09:41:16 hermes audit: NETFILTER_CFG table=raw family=2 entries=0 May 02 09:41:16 hermes audit: NETFILTER_CFG table=raw family=10 entries=0 May 02 09:41:16 hermes audit: NETFILTER_CFG table=nat family=2 entries=0 May 02 09:41:16 hermes audit[3200]: SYSCALL arch=c000003e syscall=272 success=yes exit=0 a0=40000000 a1=7ffcc5e4ed20 a2=fffffffffffffff5 a3=7fcebc3088c0 items=0 ppid=1 pid=3200 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="(t-daemon)" exe="/usr/lib/systemd/systemd" key=(null) May 02 09:41:16 hermes audit: PROCTITLE proctitle="(t-daemon)" May 02 09:41:16 hermes kernel: audit: type=1325 audit(1462174876.310:161): table=filter family=10 entries=0 May 02 09:41:16 hermes kernel: audit: type=1325 audit(1462174876.310:161): table=mangle family=10 entries=0 May 02 09:41:16 hermes kernel: audit: type=1325 audit(1462174876.310:161): table=filter family=2 entries=0 May 02 09:41:16 hermes kernel: audit: type=1325 audit(1462174876.310:161): table=raw family=2 entries=0 May 02 09:41:16 hermes kernel: audit: type=1325 audit(1462174876.310:161): table=raw family=10 entries=0 May 02 09:41:16 hermes kernel: audit: type=1325 audit(1462174876.310:161): table=nat family=2 entries=0 May 02 09:41:16 hermes kernel: audit: type=1300 audit(1462174876.310:161): arch=c000003e syscall=272 success=yes exit=0 a0=40000000 a1=7ffcc5e4ed20 a2=fffffffffffffff5 a3=7fcebc3088c0 items=0 ppid=1 pid=3200 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="(t-daemon)" exe="/usr/lib/systemd/systemd" key=(null) May 02 09:41:16 hermes kernel: audit: type=1327 audit(1462174876.310:161): proctitle="(t-daemon)" May 02 09:41:16 hermes kernel: BUG: unable to handle kernel NULL pointer dereference at 0000000000000060 May 02 09:41:16 hermes kernel: IP: [<ffffffff8122c06a>] copy_tree+0x13a/0x370 May 02 09:41:16 hermes kernel: PGD 0 May 02 09:41:16 hermes kernel: Oops: 0000 [#1] PREEMPT SMP May 02 09:41:16 hermes kernel: Modules linked in: fuse ebtable_filter ebtables nf_log_ipv6 ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_pkttype xt_physdev br_netfilter xt_TCPMSS nf_log_ipv4 nf_log_common xt_LOG xt_limit iptable_nat nf_nat_ipv4 nf_nat af_packet bridge stp llc iscsi_ibft iscsi_boot_sysfs uvcvideo btusb videobuf2_vmalloc videobuf2_memops btrtl btbcm videobuf2_v4l2 videobuf2_core btintel videodev bluetooth arc4 msr iTCO_wdt iTCO_vendor_support snd_hda_codec_realtek snd_hda_codec_generic intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass iwlmvm mac80211 snd_hda_intel ghash_clmulni_intel snd_hda_codec rtsx_pci_ms pcspkr snd_hda_core iwlwifi snd_hwdep joydev snd_pcm i2c_i801 e1000e lpc_ich mei_me memstick snd_timer cfg80211 ptp mei pps_core thinkpad_acpi shpchp rfkill battery ac May 02 09:41:16 hermes kernel: snd fjes wmi soundcore thermal tpm_tis tpm ip6t_REJECT nf_reject_ipv6 xt_tcpudp nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw ipt_REJECT nf_reject_ipv4 iptable_raw xt_CT iptable_filter ip6table_mangle nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables xt_conntrack nf_conntrack ip6table_filter ip6_tables x_tables xfs libcrc32c drbg ansi_cprng dm_crypt algif_skcipher af_alg hid_generic usbhid rtsx_pci_sdmmc mmc_core crct10dif_pclmul crc32_pclmul crc32c_intel aesni_intel aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd serio_raw i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt ehci_pci fb_sys_fops ehci_hcd xhci_pci xhci_hcd rtsx_pci mfd_core usbcore drm usb_common video button dm_mirror dm_region_hash dm_log dm_mod sg May 02 09:41:16 hermes kernel: CPU: 1 PID: 3200 Comm: (t-daemon) Not tainted 4.5.0-3-default #1 May 02 09:41:16 hermes kernel: Hardware name: LENOVO 20AR000YAT/20AR000YAT, BIOS GJET78WW (2.28 ) 07/29/2014 May 02 09:41:16 hermes kernel: task: ffff8802feb92080 ti: ffff8803046b4000 task.ti: ffff8803046b4000 May 02 09:41:16 hermes kernel: RIP: 0010:[<ffffffff8122c06a>] [<ffffffff8122c06a>] copy_tree+0x13a/0x370 May 02 09:41:16 hermes kernel: RSP: 0018:ffff8803046b7e00 EFLAGS: 00010246 May 02 09:41:16 hermes kernel: RAX: 0000000000000000 RBX: ffff88032f6cc3c0 RCX: 000000000000000f May 02 09:41:16 hermes kernel: RDX: 0000000000000004 RSI: 0000000000000000 RDI: ffffffff81e0a4c4 May 02 09:41:16 hermes kernel: RBP: ffff8803046b7e50 R08: 0000000000000000 R09: 00000000000000ff May 02 09:41:16 hermes kernel: R10: 0000000000001494 R11: 0000000000015789 R12: ffff88009ecf2b00 May 02 09:41:16 hermes kernel: R13: ffff88031fae2540 R14: ffff88032e6ecfa0 R15: ffff88032f24b800 May 02 09:41:16 hermes kernel: FS: 00007fcebc3088c0(0000) GS:ffff88033e240000(0000) knlGS:0000000000000000 May 02 09:41:16 hermes kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 May 02 09:41:16 hermes kernel: CR2: 0000000000000060 CR3: 00000002ff7f8000 CR4: 00000000001406e0 May 02 09:41:16 hermes kernel: Stack: May 02 09:41:16 hermes kernel: ffff88017e1bfe10 ffff88017f802b58 ffff88009ecf2b88 0000000500000000 May 02 09:41:16 hermes kernel: ffffffff00000004 ffff88017e1bfdc0 ffff88033055b700 ffff8803304ea5c0 May 02 09:41:16 hermes kernel: ffffffff81e44760 ffff88017e917a40 ffff8803046b7e90 ffffffff8122d549 May 02 09:41:16 hermes kernel: Call Trace: May 02 09:41:16 hermes kernel: [<ffffffff8122d549>] copy_mnt_ns+0x79/0x290 May 02 09:41:16 hermes kernel: [<ffffffff8109c742>] create_new_namespaces+0x62/0x190 May 02 09:41:16 hermes kernel: [<ffffffff8109c9ea>] unshare_nsproxy_namespaces+0x5a/0xb0 May 02 09:41:16 hermes kernel: [<ffffffff8107d1a1>] SyS_unshare+0x1a1/0x330 May 02 09:41:16 hermes kernel: [<ffffffff816cc0b2>] entry_SYSCALL_64_fastpath+0x16/0x71 May 02 09:41:16 hermes kernel: DWARF2 unwinder stuck at entry_SYSCALL_64_fastpath+0x16/0x71 May 02 09:41:16 hermes kernel: May 02 09:41:16 hermes kernel: Leftover inexact backtrace: May 02 09:41:16 hermes kernel: Code: 48 8b 43 60 48 39 45 b0 48 8d 58 a0 75 8c 4c 89 e0 48 83 c4 28 5b 41 5c 41 5d 41 5e 41 5f 5d c3 8b 45 c8 49 8b 76 20 85 c0 75 0e <48> 81 7e 60 80 31 83 81 0f 84 c8 01 00 00 49 8b 46 10 4c 39 e8 May 02 09:41:16 hermes kernel: RIP [<ffffffff8122c06a>] copy_tree+0x13a/0x370 May 02 09:41:16 hermes kernel: RSP <ffff8803046b7e00> May 02 09:41:16 hermes kernel: CR2: 0000000000000060 May 02 09:41:16 hermes kernel: ---[ end trace f848a64a7ccebe9d ]--- May 02 09:41:16 hermes kernel: audit: type=1130 audit(1462174876.354:162): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=rtkit-daemon comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed' May 02 09:41:16 hermes audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=rtkit-daemon comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed' May 02 09:41:16 hermes systemd[1]: rtkit-daemon.service: Main process exited, code=killed, status=9/KILL May 02 09:41:16 hermes systemd[1]: Failed to start RealtimeKit Scheduling Policy Service. May 02 09:41:16 hermes systemd[1]: rtkit-daemon.service: Unit entered failed state. May 02 09:41:16 hermes systemd[1]: rtkit-daemon.service: Failed with result 'signal'. -- You are receiving this mail because: You are on the CC list for the bug.

2 3

[Bug 899501] New: Only one display wakes up after powersave
by bugzilla_noreply＠novell.com 03 Aug '21

03 Aug '21

http://bugzilla.suse.com/show_bug.cgi?id=899501 Bug ID: 899501 Summary: Only one display wakes up after powersave Classification: openSUSE Product: openSUSE Factory Version: 201409* Hardware: x86-64 OS: Other Status: NEW Severity: Major Priority: P5 - None Component: X.Org Assignee: bnc-team-xorg-bugs(a)forge.provo.novell.com Reporter: lmb(a)suse.com QA Contact: xorg-maintainer-bugs(a)forge.provo.novell.com Found By: --- Blocker: --- Created attachment 608781 --> http://bugzilla.suse.com/attachment.cgi?id=608781&action=edit Xorg.0.log I have a Lenovo Thinkpad T440s with Intel graphics. I'm using a dual monitor setup - the internal 1920x1080 display on eDP1 and a 1920x1200 screen (HP ZR24w on DP4 via the docking station). (Running Factory as of now, but tried 13.2b1 yesterday and had the same effect.) Leaving the system alone for a bit leads to the screens being turned off (powersave). However, only the internal display wakes up again; the external output remains in power-save mode. (e.g., the monitor doesn't find any signal on any port.) I tried using xrandr --output --off and turning it on with --auto again, turning off the monitor itself, etc. No change; the only apparent way to resolve this and get my external monitor back is to reboot, which seems a bit harsh. Any suggestions? 00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 0b) Screen 0: minimum 8 x 8, current 1920 x 1200, maximum 32767 x 32767 eDP1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 309mm x 175mm 1920x1080 60.01*+ 1400x1050 59.98 1280x1024 60.02 1280x960 60.00 1024x768 60.00 800x600 60.32 56.25 640x480 59.94 DP1 disconnected (normal left inverted right x axis y axis) DP2 disconnected (normal left inverted right x axis y axis) DP3 disconnected (normal left inverted right x axis y axis) DP4 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 546mm x 352mm 1920x1200 59.95*+ 1920x1080 59.99 1600x1200 60.00 1680x1050 59.95 1280x1024 60.02 1440x900 59.89 1280x960 60.00 1024x768 60.00 800x600 60.32 640x480 60.00 DP5 disconnected (normal left inverted right x axis y axis) HDMI1 disconnected (normal left inverted right x axis y axis) HDMI2 disconnected (normal left inverted right x axis y axis) VIRTUAL1 disconnected (normal left inverted right x axis y axis) Pl -- You are receiving this mail because: You are on the CC list for the bug.

2 4