May 2019 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1094772] New: Distributed phpPgAdmin 5.1 does not support distributed PostgreSQL 10.3
by bugzilla_noreply＠novell.com 04 May '20

04 May '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1094772 Bug ID: 1094772 Summary: Distributed phpPgAdmin 5.1 does not support distributed PostgreSQL 10.3 Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.0 Hardware: x86-64 OS: SUSE Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: woe.2018(a)wizonet.ch QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- The phpPgSql tool shipped with openSuSE Leap15 does not support the shipped PostgreSQL version 10.3. Loggin into a 10.3 server ends up with this message: Ihre PostgreSQL-Version wird nicht unterstützt. Bitte stellen Sie Ihre Datenbank auf Version oder eine neuere Version um. I've tried to deinstal postgresql10-server and then install postgresql96-server, but postgresql10-server is an dependency of postgresql96-server and therefore this ends up in an installed postgres 10.3 server again. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1121298] New: 389-ds from server:Kolab:Extras doesn't
by bugzilla_noreply＠novell.com 03 May '20

03 May '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1121298 Bug ID: 1121298 Summary: 389-ds from server:Kolab:Extras doesn't Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.0 Hardware: Other OS: openSUSE Factory Status: NEW Severity: Major Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: ecsos(a)schirra.net QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- The 389 Directory Server (389-ds) doesn't start. Directory /var/lib/dirsrv has 0750 dirsrv:dirsrv but kolab need write rights. So /var/lib/dirsrv need: 0770 dirsrv:kolab or need: 0770 dirsrv:dirsrv and kolab must in group dirsrv. Without that Server can not be start. -- You are receiving this mail because: You are on the CC list for the bug.

1 13

[Bug 1125664] New: Spyder 3.3.2 broken menu and toolbars icons
by bugzilla_noreply＠novell.com 01 May '20

01 May '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1125664 Bug ID: 1125664 Summary: Spyder 3.3.2 broken menu and toolbars icons Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Development Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: cygnix(a)tutanota.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 797005 --> http://bugzilla.opensuse.org/attachment.cgi?id=797005&action=edit broken icons screen caption As of openSUSE Tumbleweed 20190214, all menu and toolbars icons are broken on Spyder 3.3.2. -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1134805] New: Graphical artifacts in KDE and SDDM, using radeon driver
by bugzilla_noreply＠novell.com 01 May '20

01 May '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1134805 Bug ID: 1134805 Summary: Graphical artifacts in KDE and SDDM, using radeon driver Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: X.Org Assignee: xorg-maintainer-bugs(a)forge.provo.novell.com Reporter: opensuse.lietuviu.kalba(a)gmail.com QA Contact: xorg-maintainer-bugs(a)forge.provo.novell.com Found By: --- Blocker: --- Created attachment 804814 --> http://bugzilla.opensuse.org/attachment.cgi?id=804814&action=edit /var/log/Xorg.0.log I see graphical artifacts during KDE logout and in SDDM. Operating System: openSUSE Tumbleweed 20190509 KDE Plasma Version: 5.15.5 KDE Frameworks Version: 5.57.0 Qt Version: 5.12.3 Kernel Version: 5.0.11-1-default OS Type: 32-bit Processors: 1 × Intel® Celeron® D CPU 3.06GHz Memory: 1,8 GiB /etc/X11/xorg.conf does not exist > zypper se --details --installed-only xf86-video- Loading repository data... Reading installed packages... S | Name | Type | Version | Arch ---+-------------------+---------+------------+----- i+ | xf86-video-amdgpu | package | 19.0.1-1.1 | i586 i+ | xf86-video-ati | package | 19.0.1-1.1 | i586 i | xf86-video-dummy | package | 0.3.8-1.6 | i586 i+ | xf86-video-fbdev | package | 0.5.0-1.4 | i586 i+ | xf86-video-mach64 | package | 6.9.6-1.4 | i586 i+ | xf86-video-r128 | package | 6.11.0-1.2 | i586 i+ | xf86-video-vesa | package | 2.4.0-1.4 | i586 > rpm -q sddm | head -n3 sddm-0.18.0-7.1.i586 > rpm --changelog -q sddm | head -n3 * Mon Feb 18 2019 Fabian Vogt <fabian(a)ritter-vogt.de> - Add patch to fix reading garbage from getpwnam (boo#1125624): * 0001-Use-C-scoping-for-handling-buffer-deletion.patch > rpm --changelog -q Mesa | head -n3 * Fri Apr 26 2019 Stefan Dirsch <sndirsch(a)suse.com> - Update to 19.0.3 * quiet release with just 19 patches (excluding release churn) > rpm --changelog -q xorg-x11-server | head -n3 * Wed Apr 24 2019 Martin Li?ka <mliska(a)suse.cz> - Disable LTO (boo#1133294). > rpm --changelog -q xf86-input-evdev | head -n3 * Wed May 30 2018 sndirsch(a)suse.com - upt to version 2.10.6 * Since evdev is in maintenance mode there aren't a lot of > rpm --changelog -q xf86-video-ati | head -n3 * Fri Mar 22 2019 Stefan Dirsch <sndirsch(a)suse.com> - Update to release 19.0.1 * Fixes for two regressions which crept into the 19.0.0 release. > rpm --changelog -q xf86-video-fbdev | head -n3 * Mon Jun 04 2018 sndirsch(a)suse.com - Update to version 0.5.0 * Compatibility updates for xserver 1.20. > rpm --changelog -q xf86-video-modesetting | head -n3 package xf86-video-modesetting is not installed > rpm --changelog -q xf86-video-vesa | head -n3 * Fri Feb 16 2018 sndirsch(a)suse.com - Update to version 2.4.0 * Nothing terribly exciting, but enough bug fixes to justify a > hwinfo --gfx 14: PCI 105.0: 0300 VGA compatible controller (VGA) [Created at pci.386] Unique ID: ul7N.n3FKoMfWx+7 Parent ID: vSkL.4UFp5fHqms6 SysFS ID: /devices/pci0000:00/0000:00:01.0/0000:01:05.0 SysFS BusID: 0000:01:05.0 Hardware Class: graphics card Model: "ATI Radeon XPRESS 200 5A61 (PCIE)" Vendor: pci 0x1002 "ATI Technologies Inc" Device: pci 0x5a61 "Radeon XPRESS 200 5A61 (PCIE)" SubVendor: pci 0x8086 "Intel Corporation" SubDevice: pci 0xd601 Driver: "radeon" Driver Modules: "radeon" Memory Range: 0x80000000-0x8fffffff (ro,non-prefetchable) I/O Ports: 0x2000-0x2fff (rw) Memory Range: 0xa0100000-0xa010ffff (rw,non-prefetchable) Memory Range: 0x000c0000-0x000dffff (rw,non-prefetchable,disabled) IRQ: 17 (3009 events) I/O Ports: 0x3c0-0x3df (rw) Module Alias: "pci:v00001002d00005A61sv00008086sd0000D601bc03sc00i00" Driver Info #0: XFree86 v4 Server Module: radeon Driver Info #1: XFree86 v4 Server Module: fglrx 3D Support: yes Extensions: dri Config Status: cfg=new, avail=yes, need=no, active=unknown Attached to: #20 (PCI bridge) -- You are receiving this mail because: You are on the CC list for the bug.

1 34

[Bug 1066021] New: Always getting 'Failed unmounting Runtime Directory' (and /var) during shutdown
by bugzilla_noreply＠novell.com 01 May '20

01 May '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1066021 Bug ID: 1066021 Summary: Always getting 'Failed unmounting Runtime Directory' (and /var) during shutdown Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.3 Hardware: x86-64 OS: openSUSE 42.3 Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: studio(a)anchev.net QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Each time I shutdown/reboot I get these red colored messages: ---- Failed unmounting Runtime Directory. ... Failed unmounting /var. ---- This has been happening since I installed Leap 42.1 (currently I use 42.3). Nothing seems to have been broken so far but once during a recent boot there was some more extensive disk check. I have followed the steps given here: https://lists.opensuse.org/opensuse-factory/2016-05/msg00341.html As the guys in the forums asked to look at the beginning of the log here are the first 20 lines of the latest log file: https://susepaste.org/71c124c1 These are the last 40 lines of the log: https://susepaste.org/29aa84b3 The message "Failed to unmount /var" appears during shutdown right before this message (I don't know why it is not in the log though): [ 31.245825] systemd-shutdown[1]: Unmounting /var. /var is sdb3 Another message which always appears in the log is this one: [ 10.165896] FAT-fs (sdd1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck. sdd1 is /boot/efi Looking at SMART tests - all disks are fine, i.e. it is not a hardware issue. I am hesitant to share the full shutdown-log.txt as I am cautious about the security of the system (it seems to expose certain data) but if there is any other way to diagnose this and provide necessary data please let me know. You can see the whole forum discussion: https://forums.opensuse.org/showthread.php/527879-Always-getting-Failed-unm… -- You are receiving this mail because: You are on the CC list for the bug.

1 9

[Bug 1076039] New: science/slepc: Bug slepc-openmpi-devel not installable
by bugzilla_noreply＠novell.com 30 Apr '20

30 Apr '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1076039 Bug ID: 1076039 Summary: science/slepc: Bug slepc-openmpi-devel not installable Classification: openSUSE Product: openSUSE.org Version: unspecified Hardware: Other OS: openSUSE 42.2 Status: NEW Severity: Normal Priority: P5 - None Component: 3rd party software Assignee: dmitry(a)roshchin.org Reporter: gass(a)search.ch QA Contact: opensuse-communityscreening(a)forge.provo.novell.com Found By: --- Blocker: --- slepc-openmpi-devel is not installable on openSUSE Tumbleweed or openSUSE Leap 42.2. Commands to reproduce the problem: zypper addrepo 'http://download.opensuse.org/repositories/science/openSUSE_Leap_42.2/' science zypper install slepc-openmpi-devel Relevant output: Problem: nothing provides petsc-openmpi-devel needed by slepc-openmpi-devel-3.7.3-1.19.x86_64 Greetings Nathan Gass -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1123328] New: obs-arm-7 hangs on umount/mount (obs worker kvm builds) with kernel >= 4.19
by bugzilla_noreply＠novell.com 29 Apr '20

29 Apr '20

http://bugzilla.suse.com/show_bug.cgi?id=1123328 Bug ID: 1123328 Summary: obs-arm-7 hangs on umount/mount (obs worker kvm builds) with kernel >= 4.19 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-maintainers(a)forge.provo.novell.com Reporter: dmueller(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- when obs-arm-7 (Cavium ThunderX CN99xx) builds with kernel >= 4.19, the initial umount/mount of filesystems is hanging: # ps -elf | grep umou 4 D root 60909 1 0 80 0 - 995 blk_mq Jan22 ? 00:00:00 umount /var/cache/obs/worker/root_3/.mount 0 D root 102921 102894 0 80 0 - 998 blkdev 10:11 pts/20 00:00:00 mount -o noatime,loop /var/cache/obs/worker/root_5/root /var/cache/obs/worker/root_5/.mount 0 D root 102949 102922 0 80 0 - 998 blkdev 10:11 pts/23 00:00:00 mount -o noatime,loop /var/cache/obs/worker/root_8/root /var/cache/obs/worker/root_8/.mount 0 D root 102977 102950 0 80 0 - 998 blkdev 10:11 pts/22 00:00:00 mount -o noatime,loop /var/cache/obs/worker/root_7/root /var/cache/obs/worker/root_7/.mount 0 D root 103005 102978 0 80 0 - 998 blkdev 10:11 pts/25 00:00:00 mount -o noatime,loop /var/cache/obs/worker/root_10/root /var/cache/obs/worker/root_10/.mount 0 D root 103063 103036 0 80 0 - 998 blkdev 10:12 pts/24 00:00:00 mount -o noatime,loop /var/cache/obs/worker/root_9/root /var/cache/obs/worker/root_9/.mount 0 D root 103137 103110 0 80 0 - 998 blkdev 10:13 pts/17 00:00:00 mount -o noatime,loop /var/cache/obs/worker/root_2/root /var/cache/obs/worker/root_2/.mount 0 D root 103253 103217 0 80 0 - 998 blkdev 10:14 pts/26 00:00:00 mount -o noatime,loop /var/cache/obs/worker/root_11/root /var/cache/obs/worker/root_11/.mount 0 D root 103273 103226 0 80 0 - 998 blkdev 10:14 pts/27 00:00:00 mount -o noatime,loop /var/cache/obs/worker/root_12/root /var/cache/obs/worker/root_12/.mount 0 D root 103324 103292 0 80 0 - 998 blkdev 10:14 pts/30 00:00:00 mount -o noatime,loop /var/cache/obs/worker/root_15/root /var/cache/obs/worker/root_15/.mount 0 D root 103875 103843 0 80 0 - 998 blkdev 10:21 pts/16 00:00:00 mount -o noatime,loop /var/cache/obs/worker/root_1/root /var/cache/obs/worker/root_1/.mount sysrq-W gives: [1213689.321930] task PC stack pid father [1213689.325022] umount D 0 60909 1 0x00000009 [1213689.325027] Call trace: [1213689.325035] __switch_to+0x9c/0xd8 [1213689.325042] __schedule+0x2a0/0x888 [1213689.325045] schedule+0x30/0x88 [1213689.325050] blk_mq_freeze_queue_wait+0x54/0xa0 [1213689.325053] blk_freeze_queue+0x30/0x58 [1213689.325055] blk_mq_freeze_queue+0x20/0x30 [1213689.325064] loop_clr_fd+0x4c/0x288 [loop] [1213689.325067] lo_release+0xa4/0xc8 [loop] [1213689.325072] __blkdev_put+0x22c/0x260 [1213689.325074] blkdev_put+0xe4/0x118 [1213689.325079] kill_block_super+0x44/0x58 [1213689.325082] deactivate_locked_super+0x50/0x90 [1213689.325084] deactivate_super+0x74/0x80 [1213689.325087] cleanup_mnt+0x44/0x88 [1213689.325089] __cleanup_mnt+0x20/0x30 [1213689.325093] task_work_run+0xb8/0xe8 [1213689.325096] do_notify_resume+0x2f4/0x390 [1213689.325097] work_pending+0x8/0x14 [1213689.325101] mount D 0 61620 1 0x00000001 [1213689.325104] Call trace: [1213689.325106] __switch_to+0x9c/0xd8 [1213689.325109] __schedule+0x2a0/0x888 [1213689.325111] schedule+0x30/0x88 [1213689.325113] schedule_preempt_disabled+0x14/0x20 [1213689.325115] __mutex_lock.isra.1+0x2c0/0x4b8 [1213689.325117] __mutex_lock_slowpath+0x24/0x30 [1213689.325120] mutex_lock+0x48/0x50 [1213689.325122] __blkdev_get+0x70/0x488 [1213689.325124] blkdev_get+0x10c/0x368 [1213689.325125] blkdev_open+0x9c/0xb0 [1213689.325128] do_dentry_open+0x11c/0x340 [1213689.325130] vfs_open+0x38/0x48 [1213689.325133] do_last+0x224/0x830 [1213689.325135] path_openat+0x68/0x238 [1213689.325137] do_filp_open+0x70/0xd0 [1213689.325139] do_sys_open+0x15c/0x1e8 [1213689.325141] __arm64_sys_openat+0x2c/0x38 [1213689.325145] el0_svc_common+0x98/0x100 [1213689.325147] el0_svc_handler+0x38/0x78 [1213689.325149] el0_svc+0x8/0xc [1213689.325153] mount D 0 62347 1 0x00000001 [1213689.325155] Call trace: [1213689.325157] __switch_to+0x9c/0xd8 [1213689.325160] __schedule+0x2a0/0x888 [1213689.325162] schedule+0x30/0x88 [1213689.325164] schedule_preempt_disabled+0x14/0x20 [1213689.325166] __mutex_lock.isra.1+0x2c0/0x4b8 [1213689.325168] __mutex_lock_slowpath+0x24/0x30 [1213689.325170] mutex_lock+0x48/0x50 [1213689.325172] __blkdev_get+0x70/0x488 [1213689.325174] blkdev_get+0x10c/0x368 [1213689.325176] blkdev_open+0x9c/0xb0 [1213689.325178] do_dentry_open+0x11c/0x340 [1213689.325179] vfs_open+0x38/0x48 [1213689.325182] do_last+0x224/0x830 [1213689.325184] path_openat+0x68/0x238 [1213689.325186] do_filp_open+0x70/0xd0 [1213689.325187] do_sys_open+0x15c/0x1e8 [1213689.325189] __arm64_sys_openat+0x2c/0x38 [1213689.325191] el0_svc_common+0x98/0x100 [1213689.325193] el0_svc_handler+0x38/0x78 [1213689.325195] el0_svc+0x8/0xc [1213689.325199] mount D 0 62405 1 0x00000001 [1213689.325201] Call trace: [1213689.325203] __switch_to+0x9c/0xd8 [1213689.325205] __schedule+0x2a0/0x888 [1213689.325207] schedule+0x30/0x88 [1213689.325209] schedule_preempt_disabled+0x14/0x20 [1213689.325211] __mutex_lock.isra.1+0x2c0/0x4b8 [1213689.325214] __mutex_lock_slowpath+0x24/0x30 [1213689.325216] mutex_lock+0x48/0x50 [1213689.325218] __blkdev_get+0x70/0x488 [1213689.325220] blkdev_get+0x10c/0x368 [1213689.325222] blkdev_open+0x9c/0xb0 [1213689.325223] do_dentry_open+0x11c/0x340 [1213689.325225] vfs_open+0x38/0x48 [1213689.325227] do_last+0x224/0x830 [1213689.325229] path_openat+0x68/0x238 [1213689.325231] do_filp_open+0x70/0xd0 [1213689.325233] do_sys_open+0x15c/0x1e8 [1213689.325234] __arm64_sys_openat+0x2c/0x38 [1213689.325237] el0_svc_common+0x98/0x100 [1213689.325239] el0_svc_handler+0x38/0x78 [1213689.325240] el0_svc+0x8/0xc [1213689.325244] mount D 0 62568 1 0x00000001 [1213689.325246] Call trace: [1213689.325248] __switch_to+0x9c/0xd8 [1213689.325250] __schedule+0x2a0/0x888 [1213689.325252] schedule+0x30/0x88 [1213689.325254] schedule_preempt_disabled+0x14/0x20 [1213689.325256] __mutex_lock.isra.1+0x2c0/0x4b8 [1213689.325258] __mutex_lock_slowpath+0x24/0x30 [1213689.325260] mutex_lock+0x48/0x50 [1213689.325262] __blkdev_get+0x70/0x488 [1213689.325264] blkdev_get+0x10c/0x368 [1213689.325266] blkdev_open+0x9c/0xb0 [1213689.325267] do_dentry_open+0x11c/0x340 [1213689.325269] vfs_open+0x38/0x48 [1213689.325271] do_last+0x224/0x830 [1213689.325273] path_openat+0x68/0x238 [1213689.325275] do_filp_open+0x70/0xd0 [1213689.325277] do_sys_open+0x15c/0x1e8 [1213689.325279] __arm64_sys_openat+0x2c/0x38 [1213689.325281] el0_svc_common+0x98/0x100 [1213689.325283] el0_svc_handler+0x38/0x78 [1213689.325284] el0_svc+0x8/0xc [1213689.325288] mount D 0 62723 1 0x00000001 [1213689.325290] Call trace: [1213689.325292] __switch_to+0x9c/0xd8 [1213689.325294] __schedule+0x2a0/0x888 [1213689.325296] schedule+0x30/0x88 [1213689.325298] schedule_preempt_disabled+0x14/0x20 [1213689.325300] __mutex_lock.isra.1+0x2c0/0x4b8 [1213689.325302] __mutex_lock_slowpath+0x24/0x30 [1213689.325304] mutex_lock+0x48/0x50 [1213689.325306] __blkdev_get+0x70/0x488 [1213689.325308] blkdev_get+0x10c/0x368 [1213689.325310] blkdev_open+0x9c/0xb0 [1213689.325312] do_dentry_open+0x11c/0x340 [1213689.325313] vfs_open+0x38/0x48 [1213689.325315] do_last+0x224/0x830 [1213689.325317] path_openat+0x68/0x238 [1213689.325319] do_filp_open+0x70/0xd0 [1213689.325321] do_sys_open+0x15c/0x1e8 [1213689.325323] __arm64_sys_openat+0x2c/0x38 [1213689.325325] el0_svc_common+0x98/0x100 [1213689.325327] el0_svc_handler+0x38/0x78 [1213689.325328] el0_svc+0x8/0xc [1213689.325333] mount D 0 66786 1 0x00000001 [1213689.325335] Call trace: [1213689.325337] __switch_to+0x9c/0xd8 [1213689.325340] __schedule+0x2a0/0x888 [1213689.325342] schedule+0x30/0x88 [1213689.325344] schedule_preempt_disabled+0x14/0x20 [1213689.325346] __mutex_lock.isra.1+0x2c0/0x4b8 [1213689.325348] __mutex_lock_slowpath+0x24/0x30 [1213689.325350] mutex_lock+0x48/0x50 [1213689.325352] __blkdev_get+0x70/0x488 [1213689.325354] blkdev_get+0x10c/0x368 [1213689.325356] blkdev_open+0x9c/0xb0 [1213689.325358] do_dentry_open+0x11c/0x340 [1213689.325360] vfs_open+0x38/0x48 [1213689.325362] do_last+0x224/0x830 [1213689.325364] path_openat+0x68/0x238 [1213689.325366] do_filp_open+0x70/0xd0 [1213689.325368] do_sys_open+0x15c/0x1e8 [1213689.325370] __arm64_sys_openat+0x2c/0x38 [1213689.325372] el0_svc_common+0x98/0x100 [1213689.325374] el0_svc_handler+0x38/0x78 [1213689.325375] el0_svc+0x8/0xc [1213689.325379] mount D 0 72349 1 0x00000001 [1213689.325381] Call trace: [1213689.325383] __switch_to+0x9c/0xd8 [1213689.325386] __schedule+0x2a0/0x888 [1213689.325388] schedule+0x30/0x88 [1213689.325390] schedule_preempt_disabled+0x14/0x20 [1213689.325392] __mutex_lock.isra.1+0x2c0/0x4b8 [1213689.325394] __mutex_lock_slowpath+0x24/0x30 [1213689.325396] mutex_lock+0x48/0x50 [1213689.325399] __blkdev_get+0x70/0x488 [1213689.325400] blkdev_get+0x10c/0x368 [1213689.325402] blkdev_open+0x9c/0xb0 [1213689.325404] do_dentry_open+0x11c/0x340 [1213689.325406] vfs_open+0x38/0x48 [1213689.325408] do_last+0x224/0x830 [1213689.325410] path_openat+0x68/0x238 [1213689.325412] do_filp_open+0x70/0xd0 [1213689.325414] do_sys_open+0x15c/0x1e8 [1213689.325416] __arm64_sys_openat+0x2c/0x38 [1213689.325418] el0_svc_common+0x98/0x100 [1213689.325420] el0_svc_handler+0x38/0x78 [1213689.325422] el0_svc+0x8/0xc [1213689.325425] mount D 0 75917 1 0x00000001 [1213689.325427] Call trace: [1213689.325429] __switch_to+0x9c/0xd8 [1213689.325432] __schedule+0x2a0/0x888 [1213689.325434] schedule+0x30/0x88 [1213689.325436] schedule_preempt_disabled+0x14/0x20 [1213689.325438] __mutex_lock.isra.1+0x2c0/0x4b8 [1213689.325440] __mutex_lock_slowpath+0x24/0x30 [1213689.325442] mutex_lock+0x48/0x50 [1213689.325444] __blkdev_get+0x70/0x488 [1213689.325446] blkdev_get+0x10c/0x368 [1213689.325448] blkdev_open+0x9c/0xb0 [1213689.325449] do_dentry_open+0x11c/0x340 [1213689.325451] vfs_open+0x38/0x48 [1213689.325453] do_last+0x224/0x830 [1213689.325455] path_openat+0x68/0x238 [1213689.325457] do_filp_open+0x70/0xd0 [1213689.325459] do_sys_open+0x15c/0x1e8 [1213689.325461] __arm64_sys_openat+0x2c/0x38 [1213689.325463] el0_svc_common+0x98/0x100 [1213689.325465] el0_svc_handler+0x38/0x78 [1213689.325467] el0_svc+0x8/0xc [1213689.325471] mount D 0 77793 1 0x00000001 [1213689.325472] Call trace: [1213689.325474] __switch_to+0x9c/0xd8 [1213689.325477] __schedule+0x2a0/0x888 [1213689.325479] schedule+0x30/0x88 [1213689.325481] schedule_preempt_disabled+0x14/0x20 [1213689.325483] __mutex_lock.isra.1+0x2c0/0x4b8 [1213689.325485] __mutex_lock_slowpath+0x24/0x30 [1213689.325487] mutex_lock+0x48/0x50 [1213689.325489] __blkdev_get+0x70/0x488 [1213689.325491] blkdev_get+0x10c/0x368 [1213689.325493] blkdev_open+0x9c/0xb0 [1213689.325494] do_dentry_open+0x11c/0x340 [1213689.325496] vfs_open+0x38/0x48 [1213689.325498] do_last+0x224/0x830 [1213689.325500] path_openat+0x68/0x238 [1213689.325502] do_filp_open+0x70/0xd0 [1213689.325504] do_sys_open+0x15c/0x1e8 [1213689.325505] __arm64_sys_openat+0x2c/0x38 [1213689.325507] el0_svc_common+0x98/0x100 [1213689.325509] el0_svc_handler+0x38/0x78 [1213689.325511] el0_svc+0x8/0xc [1213689.325514] mount D 0 79041 1 0x00000001 [1213689.325516] Call trace: [1213689.325518] __switch_to+0x9c/0xd8 [1213689.325521] __schedule+0x2a0/0x888 [1213689.325523] schedule+0x30/0x88 [1213689.325525] schedule_preempt_disabled+0x14/0x20 [1213689.325527] __mutex_lock.isra.1+0x2c0/0x4b8 [1213689.325529] __mutex_lock_slowpath+0x24/0x30 [1213689.325531] mutex_lock+0x48/0x50 [1213689.325533] __blkdev_get+0x70/0x488 [1213689.325535] blkdev_get+0x10c/0x368 [1213689.325536] blkdev_open+0x9c/0xb0 [1213689.325538] do_dentry_open+0x11c/0x340 [1213689.325540] vfs_open+0x38/0x48 [1213689.325542] do_last+0x224/0x830 [1213689.325544] path_openat+0x68/0x238 [1213689.325546] do_filp_open+0x70/0xd0 [1213689.325547] do_sys_open+0x15c/0x1e8 [1213689.325549] __arm64_sys_openat+0x2c/0x38 [1213689.325551] el0_svc_common+0x98/0x100 [1213689.325553] el0_svc_handler+0x38/0x78 [1213689.325555] el0_svc+0x8/0xc [1213689.325559] mount D 0 79830 1 0x00000001 [1213689.325560] Call trace: [1213689.325562] __switch_to+0x9c/0xd8 [1213689.325565] __schedule+0x2a0/0x888 [1213689.325567] schedule+0x30/0x88 [1213689.325569] schedule_preempt_disabled+0x14/0x20 [1213689.325571] __mutex_lock.isra.1+0x2c0/0x4b8 [1213689.325573] __mutex_lock_slowpath+0x24/0x30 [1213689.325575] mutex_lock+0x48/0x50 [1213689.325577] __blkdev_get+0x70/0x488 [1213689.325579] blkdev_get+0x10c/0x368 [1213689.325581] blkdev_open+0x9c/0xb0 [1213689.325583] do_dentry_open+0x11c/0x340 [1213689.325584] vfs_open+0x38/0x48 [1213689.325586] do_last+0x224/0x830 [1213689.325588] path_openat+0x68/0x238 [1213689.325590] do_filp_open+0x70/0xd0 [1213689.325592] do_sys_open+0x15c/0x1e8 [1213689.325594] __arm64_sys_openat+0x2c/0x38 [1213689.325596] el0_svc_common+0x98/0x100 [1213689.325598] el0_svc_handler+0x38/0x78 [1213689.325600] el0_svc+0x8/0xc [1213689.325606] mount D 0 83698 1 0x00000001 [1213689.325607] Call trace: [1213689.325609] __switch_to+0x9c/0xd8 [1213689.325612] __schedule+0x2a0/0x888 [1213689.325614] schedule+0x30/0x88 [1213689.325616] schedule_preempt_disabled+0x14/0x20 [1213689.325619] __mutex_lock.isra.1+0x2c0/0x4b8 [1213689.325621] __mutex_lock_slowpath+0x24/0x30 [1213689.325623] mutex_lock+0x48/0x50 [1213689.325625] __blkdev_get+0x70/0x488 [1213689.325627] blkdev_get+0x10c/0x368 [1213689.325629] blkdev_open+0x9c/0xb0 [1213689.325630] do_dentry_open+0x11c/0x340 [1213689.325632] vfs_open+0x38/0x48 [1213689.325634] do_last+0x224/0x830 [1213689.325636] path_openat+0x68/0x238 [1213689.325638] do_filp_open+0x70/0xd0 [1213689.325640] do_sys_open+0x15c/0x1e8 [1213689.325641] __arm64_sys_openat+0x2c/0x38 [1213689.325643] el0_svc_common+0x98/0x100 [1213689.325645] el0_svc_handler+0x38/0x78 [1213689.325647] el0_svc+0x8/0xc ... -- You are receiving this mail because: You are on the CC list for the bug.

1 39

[Bug 1063167] New: crash of synergyc
by bugzilla_noreply＠novell.com 28 Apr '20

28 Apr '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1063167 Bug ID: 1063167 Summary: crash of synergyc Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Factory Status: NEW Severity: Normal Priority: P5 - None Component: X11 Applications Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: werner(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- noether:~ # coredumpctl list synergyc TIME PID UID GID SIG COREFILE EXE Tue 2017-09-05 14:35:11 CEST 3778 223 50 11 missing /usr/bin/synergyc Tue 2017-09-12 12:49:47 CEST 2474 223 50 11 missing /usr/bin/synergyc Thu 2017-10-05 08:23:57 CEST 2956 223 50 11 none /usr/bin/synergyc Thu 2017-10-05 08:56:20 CEST 32056 223 50 11 none /usr/bin/synergyc Thu 2017-10-05 10:17:47 CEST 2495 223 50 11 none /usr/bin/synergyc Thu 2017-10-05 10:51:14 CEST 4517 223 50 11 none /usr/bin/synergyc Mon 2017-10-09 13:54:01 CEST 2147 223 50 11 none /usr/bin/synergyc Mon 2017-10-09 14:28:03 CEST 12156 223 50 11 none /usr/bin/synergyc Tue 2017-10-10 12:45:05 CEST 13178 223 50 11 none /usr/bin/synergyc Wed 2017-10-11 15:02:24 CEST 20573 223 50 11 present /usr/bin/synergyc -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1127794] New: NetworkManager keeps OpenVPN processes running
by bugzilla_noreply＠novell.com 27 Apr '20

27 Apr '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1127794 Bug ID: 1127794 Summary: NetworkManager keeps OpenVPN processes running Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.0 Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Network Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: opensuse(a)pohw.nl QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- NetworkManager keeps all OpenVPN processes running, even if no vpn is actually active. Once you activate one, you can't get rid of it in the process list. Closing the vpn doesn't help. Worse: the processes are kept running even after all OpenVPN profiles have been deleted: # ps axu|grep openvpn nm-open+ 6865 0.0 0.0 47384 7564 ? S 18:01 0:02 /usr/sbin/openvpn --remote <IP> 443 udp --nobind (...) nm-open+ 19826 0.0 0.0 47384 7776 ? S 18:13 0:00 /usr/sbin/openvpn --remote <IP> 443 udp --nobind (...) At one time I had 4 profiles with 4 active processes. This causes unstable OpenVPN connections, with lots of TLS errors and invalidated connections (i.e.: no traffic is possible after a number of seconds). # journalctl -f Mon Mar 4 18:23:56 2019 80.155.9.251:51053 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Mon Mar 4 18:23:56 2019 80.155.9.251:51053 TLS Error: TLS handshake failed Mon Mar 4 18:23:56 2019 80.155.9.251:51053 SIGUSR1[soft,tls-error] received, client-instance restarting After deleting all OpenVPN profiles and killing all OpenVPN processes, I re-imported one OpenVPN profile and everything worked flawlessly after that. -- You are receiving this mail because: You are on the CC list for the bug.

1 11

[Bug 894783] New: CA management: Sign Request: Don't use sequential serial numbers
by bugzilla_noreply＠novell.com 26 Apr '20

26 Apr '20

https://bugzilla.novell.com/show_bug.cgi?id=894783 https://bugzilla.novell.com/show_bug.cgi?id=894783#c0 Summary: CA management: Sign Request: Don't use sequential serial numbers Classification: openSUSE Product: openSUSE 12.3 Version: Final Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: P5 - None Component: YaST2 AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: Ulrich.Windl(a)rz.uni-regensburg.de QAContact: jsrain(a)suse.com Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Firefox/31.0 (In openssl tradition certificates use sequential serial numbers) YaST's certificate signing function uses sequential serial numbers to issue (sign) certificates (like 01, 02, 03, ... 09, 0A, 0B, ...) Due to some weaknesses in SHA-1, there's a recommendation to use serial numbers with a higher entropy. See https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/ElekSignatur/BSI_SHA1_Z… (German): ---BEGIN quote--- Kollisionsangriffe gegen die Zertifikaterstellung mit SHA-1 können von vornherein verhindert werden, wenn folgendes gilt: 1) Es wird das X.509v3 Format gemäß ISIS-MTT verwendet. 2) Die Seriennummer ("serialNumber") des Zertifikats hat eine genügend hohe Entropie h für den Angreifer. D.h. die Unsicherheit des Angreifers über die Seriennummer eines zu erstellenden Zertifikats ist mindestens h Bits. (...) ---END quote--- Reproducible: Always Steps to Reproduce: 1. Sign a certificate request (CSR) in YaST's CA management Actual Results: The certificate gets a serial number that can easily be guessed Expected Results: The serial number should not be easy to guess See also http://www.heise.de/security/meldung/Fragwuerdige-Hash-Funktion-SHA-1-immer… (German) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 5