June 2017 - openSUSE Bugs - openSUSE Mailing Lists

[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 1039889] New: Yast handle category and pattern on a strange way for user visible/invisible
by bugzilla_noreply＠novell.com 26 Aug '21

26 Aug '21

http://bugzilla.suse.com/show_bug.cgi?id=1039889 Bug ID: 1039889 Summary: Yast handle category and pattern on a strange way for user visible/invisible Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers(a)suse.de Reporter: mlin(a)suse.com QA Contact: jsrain(a)suse.com CC: dimstar(a)opensuse.org Found By: --- Blocker: --- On TW snapshot 20170517 we see a strange situation on yast[1], while send 'down' key to 'x pattern', after press 'down' after 'font pattern'(x pattern is the next one) the list page is scroll up, the reason is 'Primary Functions' and 'Kubic Stack' entries suddenly appears on the top side. Dig into this issue I see weird behavior below: 1) at the beginning 'Primary Functions' and 'Kubic Stack' does not appear while scroll down the list to the bottom side, however after that, move to the top side these two entries appears at the top side. 2) press 'end' move the focus to the bottom side, and start repeating send 'up' key, till the focus was on the 'Server Functions' then press 'up' key again the next one is 'Kubic Stack'[2], and send 'up' key again the focus is lost[3], keep sending 'up' key the scroll bar does not change, now drag the scroll bar to the top side, I see 'Primary Functions' and 'Kubic Stack' is there, and the focus is on the 'Primary Functions' entry. issues lead us so confused the ordering of entries(and timing to resort entries) and pattern's visible/invisible, and thought that entry appeared suddenly at some point is a real bug. Note that, this issue now we only seen on NET install due to many patterns is only available from net install, tro to reproduce this issue from net iso[5] you have to set Server: openqa.opensuse.org and Directory: /assets/repo/openSUSE-Tumbleweed-oss-i586-x86_64-Snapshot20170517 from testing HEAD due to it's not published yet to download.o.o. [1] https://openqa.opensuse.org/tests/405554#step/installer_desktopselection/39 [2] http://susepaste.org/82684928 [3] http://susepaste.org/20244118 [4] http://susepaste.org/76581180 [5] https://openqa.opensuse.org/tests/405554/asset/iso/openSUSE-Tumbleweed-NET-… -- You are receiving this mail because: You are on the CC list for the bug.

2 3

[Bug 1033081] New: fetchmail hardcoded to use log file - syslogging thus unavailable
by bugzilla_noreply＠novell.com 18 Aug '21

18 Aug '21

http://bugzilla.suse.com/show_bug.cgi?id=1033081 Bug ID: 1033081 Summary: fetchmail hardcoded to use log file - syslogging thus unavailable Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.2 Hardware: x86-64 OS: openSUSE 42.2 Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: jmozdzen(a)nde.ag QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- :~ # rpm -qi fetchmail Name : fetchmail Version : 6.3.26 Release : 18.1 Architecture: x86_64 Looking at fetchmail.service -> /usr/lib/fetchmail-systemd-exec, I see that using logging to log file is hard-coded there: --- cut here: /usr/lib/fetchmail-systemd-exec --- [...] exec /usr/bin/fetchmail $OPTS $FETCHMAIL_EXPERT_OPTIONS \ -f $FETCHMAIL_RC_PATH -L /var/log/fetchmail --- cut here --- Hence, activating logging to syslog via options doesn't work: --- cut here --- :~ # grep syslog /etc/fetchmailrc set syslog :~ # systemctl restart fetchmail :~ # 2017-04-09T17:36:13.480966+02:00 myhost fetchmail[4441]: syslog and logfile options are both set, ignoring syslog, and logging to /var/log/fetchmail --- cut here --- A possible change would be to move "-L /var/log/fetchmail" to /etc/sysconfig/fetchmail (i.e. to FETCHMAIL_EXPERT_OPTIONS variable, or a new one). -- You are receiving this mail because: You are on the CC list for the bug.

2 14

[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

[Bug 901887] New: Lenovo t440s / Intel 4400: External display non-functional
by bugzilla_noreply＠novell.com 03 Aug '21

03 Aug '21

http://bugzilla.suse.com/show_bug.cgi?id=901887 Bug ID: 901887 Summary: Lenovo t440s / Intel 4400: External display non-functional Classification: openSUSE Product: openSUSE Factory Version: 201410* 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 610633 --> http://bugzilla.suse.com/attachment.cgi?id=610633&action=edit Xorg.0.log On the same system where I experienced bug 899501, I've updated the system to a later Factory build and can now no longer activate my external display at all. Though xrandr reports: 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) The output on DP4 is black, and the monitor does not detect a signal. -- You are receiving this mail because: You are on the CC list for the bug.

2 6

[Bug 903189] New: USB trackball not detected on reboot
by bugzilla_noreply＠novell.com 03 Aug '21

03 Aug '21

http://bugzilla.suse.com/show_bug.cgi?id=903189 Bug ID: 903189 Summary: USB trackball not detected on reboot Classification: openSUSE Product: openSUSE Factory Version: 201410* Hardware: Other OS: Other Status: NEW Severity: Normal 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: --- Created attachment 611775 --> http://bugzilla.suse.com/attachment.cgi?id=611775&action=edit lsusb -v directly after reboot After a reboot, the kernel doesn't detect the USB attached trackball automatically. I have to unplug and plug it in again. I'm attaching lsusb output directly after a reboot and after the unplug/plug step (to the same USB port). Note that it is attached to a port on the docking station. -- You are receiving this mail because: You are on the CC list for the bug.

2 2