August 2017 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1044294] New: FCoE, BUG: sleeping function called from invalid context at ../kernel/locking/mutex.c:97, QEMU, x86_64
by bugzilla_noreply＠novell.com 11 Jul '19

11 Jul '19

http://bugzilla.suse.com/show_bug.cgi?id=1044294 Bug ID: 1044294 Summary: FCoE, BUG: sleeping function called from invalid context at ../kernel/locking/mutex.c:97, QEMU, x86_64 Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.2 Hardware: x86-64 OS: openSUSE 42.2 Status: NEW Severity: Major Priority: P5 - None Component: Kernel Assignee: kernel-maintainers(a)forge.provo.novell.com Reporter: holger(a)fam-schranz.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Environment: 3 virtual machines, connected with FCoE, 2 of them are workers and 1 is a RAID-Server. Issue: This issue occurs always onto the RAID-Server after a while, depend to the load situation. >From the worksystems (SLES11SP4) are 4 path's configured and used to the VM which is the RAID system. A reconnect with: fcoeadm -r eth1/2 doesn't work and hangs. RAID:~ # hostnamectl Static hostname: RAID Icon name: computer-vm Chassis: vm Machine ID: 8861646bb10c9582ad7be1f6583d364a Boot ID: e31e33c369584f389cddd61d83b96e2d Virtualization: kvm Operating System: openSUSE Leap 42.2 CPE OS Name: cpe:/o:opensuse:leap:42.2 Kernel: Linux 4.4.70-18.9-default Architecture: x86-64 RAID:~ # uname -a Linux RAID 4.4.70-18.9-default #1 SMP Wed May 31 09:09:25 UTC 2017 (c1231a7) x86_64 x86_64 x86_64 GNU/Linux RAID:~ # ---------------------------- Jun 13 22:25:59 RAID kernel: BUG: sleeping function called from invalid context at ../kernel/locking/mutex.c:97 Jun 13 22:25:59 RAID kernel: in_atomic(): 1, irqs_disabled(): 0, pid: 11442, name: kworker/3:1 Jun 13 22:25:59 RAID kernel: CPU: 3 PID: 11442 Comm: kworker/3:1 Not tainted 4.4.70-18.9-default #1 Jun 13 22:25:59 RAID kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014 Jun 13 22:25:59 RAID kernel: Workqueue: events fcoe_ctlr_timer_work [libfcoe] Jun 13 22:25:59 RAID kernel: 0000000000000000 ffffffff81329447 ffff88007b5fa048 ffff88007b5fa048 Jun 13 22:25:59 RAID kernel: ffffffff8160cf6c ffff88007b5fa000 ffffffffa00945f1 ffff88007b5fa010 Jun 13 22:25:59 RAID kernel: 0000000101d6b8c0 ffff880078d74820 ffff880078d747d8 ffffffffa00b0fe9 Jun 13 22:25:59 RAID kernel: Call Trace: Jun 13 22:25:59 RAID kernel: [<ffffffff81019ea9>] dump_trace+0x59/0x320 Jun 13 22:25:59 RAID kernel: [<ffffffff8101a26a>] show_stack_log_lvl+0xfa/0x180 Jun 13 22:25:59 RAID kernel: [<ffffffff8101b011>] show_stack+0x21/0x40 Jun 13 22:25:59 RAID kernel: [<ffffffff81329447>] dump_stack+0x5c/0x85 Jun 13 22:25:59 RAID kernel: [<ffffffff8160cf6c>] mutex_lock+0x1c/0x38 Jun 13 22:25:59 RAID kernel: [<ffffffffa00945f1>] fc_rport_logoff+0x21/0xe0 [libfc] Jun 13 22:25:59 RAID kernel: [<ffffffffa00b0fe9>] fcoe_ctlr_timer_work+0x6a9/0xca0 [libfcoe] Jun 13 22:25:59 RAID kernel: [<ffffffff81097775>] process_one_work+0x155/0x440 Jun 13 22:25:59 RAID kernel: [<ffffffff810982b6>] worker_thread+0x116/0x4b0 Jun 13 22:25:59 RAID kernel: [<ffffffff8109d8a2>] kthread+0xd2/0xf0 Jun 13 22:25:59 RAID kernel: [<ffffffff8160f58f>] ret_from_fork+0x3f/0x70 Jun 13 22:25:59 RAID kernel: DWARF2 unwinder stuck at ret_from_fork+0x3f/0x70 Jun 13 22:25:59 RAID kernel: Jun 13 22:25:59 RAID kernel: Leftover inexact backtrace: Jun 13 22:25:59 RAID kernel: [<ffffffff8109d7d0>] ? kthread_park+0x50/0x50 Jun 13 22:26:03 RAID kernel: BUG: sleeping function called from invalid context at ../kernel/locking/mutex.c:97 Jun 13 22:26:03 RAID kernel: in_atomic(): 1, irqs_disabled(): 0, pid: 11442, name: kworker/3:1 Jun 13 22:26:03 RAID kernel: CPU: 3 PID: 11442 Comm: kworker/3:1 Not tainted 4.4.70-18.9-default #1 Jun 13 22:26:03 RAID kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014 Jun 13 22:26:03 RAID kernel: Workqueue: events fcoe_ctlr_timer_work [libfcoe] Jun 13 22:26:03 RAID kernel: 0000000000000000 ffffffff81329447 ffff880036a96048 ffff880036a96048 Jun 13 22:26:03 RAID kernel: ffffffff8160cf6c ffff880036a96000 ffffffffa00945f1 ffff880036a96010 Jun 13 22:26:03 RAID kernel: 0000000101d706e2 ffff880078d74820 ffff880078d747d8 ffffffffa00b0fe9 Jun 13 22:26:03 RAID kernel: Call Trace: Jun 13 22:26:03 RAID kernel: [<ffffffff81019ea9>] dump_trace+0x59/0x320 Jun 13 22:26:03 RAID kernel: [<ffffffff8101a26a>] show_stack_log_lvl+0xfa/0x180 Jun 13 22:26:03 RAID kernel: [<ffffffff8101b011>] show_stack+0x21/0x40 Jun 13 22:26:03 RAID kernel: [<ffffffff81329447>] dump_stack+0x5c/0x85 Jun 13 22:26:03 RAID kernel: [<ffffffff8160cf6c>] mutex_lock+0x1c/0x38 Jun 13 22:26:03 RAID kernel: [<ffffffffa00945f1>] fc_rport_logoff+0x21/0xe0 [libfc] Jun 13 22:26:03 RAID kernel: [<ffffffffa00b0fe9>] fcoe_ctlr_timer_work+0x6a9/0xca0 [libfcoe] Jun 13 22:26:03 RAID kernel: [<ffffffff81097775>] process_one_work+0x155/0x440 Jun 13 22:26:03 RAID kernel: [<ffffffff810982b6>] worker_thread+0x116/0x4b0 Jun 13 22:26:03 RAID kernel: [<ffffffff8109d8a2>] kthread+0xd2/0xf0 Jun 13 22:26:03 RAID kernel: [<ffffffff8160f58f>] ret_from_fork+0x3f/0x70 Jun 13 22:26:03 RAID kernel: DWARF2 unwinder stuck at ret_from_fork+0x3f/0x70 Jun 13 22:26:03 RAID kernel: Jun 13 22:26:03 RAID kernel: Leftover inexact backtrace: Jun 13 22:26:03 RAID kernel: [<ffffffff8109d7d0>] ? kthread_park+0x50/0x50 Jun 13 22:26:03 RAID kernel: BUG: scheduling while atomic: kworker/3:1/11442/0x00000002 Jun 13 22:26:03 RAID kernel: Modules linked in: fuse target_core_user tcm_loop tcm_qla2xxx qla2xxx vhost_scsi vhost iscsi_target_mod ib_srpt ib_cm ib_sa ib_mad ib_core ib_addr tcm_fc target_core_file target_core_iblock target_core_pscsi target_core_mod configfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi af_packet iscsi_ibft iscsi_boot_sysfs iTCO_wdt iTCO_vendor_support virtio_balloon ppdev acpi_cpufreq pcspkr i2c_i801 joydev lpc_ich mfd_core processor parport_pc parport shpchp button ext4 crc16 jbd2 mbcache sr_mod cdrom sd_mod virtio_gpu drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm virtio_console virtio_scsi hid_generic usbhid 8021q garp stp llc mrp bnx2fc cnic uio xhci_pci xhci_hcd usbcore usb_common ahci libahci virtio_pci virtio_ring virtio e1000 libata serio_raw fcoe libfcoe Jun 13 22:26:03 RAID kernel: libfc scsi_transport_fc sg scsi_mod autofs4 Jun 13 22:26:03 RAID kernel: CPU: 3 PID: 11442 Comm: kworker/3:1 Not tainted 4.4.70-18.9-default #1 Jun 13 22:26:03 RAID kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014 Jun 13 22:26:03 RAID kernel: Workqueue: events fcoe_ctlr_timer_work [libfcoe] Jun 13 22:26:03 RAID kernel: 0000000000000000 ffffffff81329447 ffff88017fd95c40 ffff8801022cfca0 Jun 13 22:26:03 RAID kernel: ffffffff8118a8ee ffff8801022cfce8 ffffffff8160afbe ffff8801470460c4 Jun 13 22:26:03 RAID kernel: ffff8801444c0d40 ffff8801022d0000 ffff8801444c0d40 ffff880178f9984c Jun 13 22:26:03 RAID kernel: Call Trace: Jun 13 22:26:03 RAID kernel: [<ffffffff81019ea9>] dump_trace+0x59/0x320 Jun 13 22:26:03 RAID kernel: [<ffffffff8101a26a>] show_stack_log_lvl+0xfa/0x180 Jun 13 22:26:03 RAID kernel: [<ffffffff8101b011>] show_stack+0x21/0x40 Jun 13 22:26:03 RAID kernel: [<ffffffff81329447>] dump_stack+0x5c/0x85 Jun 13 22:26:03 RAID kernel: [<ffffffff8118a8ee>] __schedule_bug+0x4b/0x59 Jun 13 22:26:03 RAID kernel: [<ffffffff8160afbe>] thread_return+0x5eb/0x6bd Jun 13 22:26:03 RAID kernel: [<ffffffff8160b0cc>] schedule+0x3c/0x90 Jun 13 22:26:03 RAID kernel: [<ffffffff8160b3f5>] schedule_preempt_disabled+0x15/0x20 Jun 13 22:26:03 RAID kernel: [<ffffffff8160ced6>] __mutex_lock_slowpath+0xb6/0x130 Jun 13 22:26:03 RAID kernel: [<ffffffff8160cf79>] mutex_lock+0x29/0x38 Jun 13 22:26:03 RAID kernel: [<ffffffffa00945f1>] fc_rport_logoff+0x21/0xe0 [libfc] Jun 13 22:26:03 RAID kernel: [<ffffffffa00b0fe9>] fcoe_ctlr_timer_work+0x6a9/0xca0 [libfcoe] Jun 13 22:26:03 RAID kernel: [<ffffffff81097775>] process_one_work+0x155/0x440 Jun 13 22:26:03 RAID kernel: [<ffffffff810982b6>] worker_thread+0x116/0x4b0 Jun 13 22:26:03 RAID kernel: [<ffffffff8109d8a2>] kthread+0xd2/0xf0 Jun 13 22:26:03 RAID kernel: [<ffffffff8160f58f>] ret_from_fork+0x3f/0x70 Jun 13 22:26:03 RAID kernel: DWARF2 unwinder stuck at ret_from_fork+0x3f/0x70 Jun 13 22:26:03 RAID kernel: Jun 13 22:26:03 RAID kernel: Leftover inexact backtrace: Jun 13 22:26:03 RAID kernel: [<ffffffff8109d7d0>] ? kthread_park+0x50/0x50 Jun 13 22:26:19 RAID kernel: BUG: sleeping function called from invalid context at ../kernel/locking/mutex.c:97 Jun 13 22:26:19 RAID kernel: in_atomic(): 1, irqs_disabled(): 0, pid: 11499, name: kworker/3:3 Jun 13 22:26:19 RAID kernel: CPU: 3 PID: 11499 Comm: kworker/3:3 Tainted: G W 4.4.70-18.9-default #1 Jun 13 22:26:19 RAID kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014 Jun 13 22:26:19 RAID kernel: Workqueue: events fcoe_ctlr_timer_work [libfcoe] Jun 13 22:26:19 RAID kernel: 0000000000000000 ffffffff81329447 ffff880178801848 ffff880178801848 Jun 13 22:26:19 RAID kernel: ffffffff8160cf6c Jun 13 22:26:19 RAID kernel: ffff880178801800 ffffffffa00945f1 ffff880178801810 Jun 13 22:26:19 RAID kernel: 0000000101d6d440 Jun 13 22:26:19 RAID kernel: ffff880036a17820 ffff880036a177d8 ffffffffa00b0fe9 Jun 13 22:26:19 RAID kernel: Call Trace: Jun 13 22:26:19 RAID kernel: [<ffffffff81019ea9>] dump_trace+0x59/0x320 Jun 13 22:26:19 RAID kernel: [<ffffffff8101a26a>] show_stack_log_lvl+0xfa/0x180 Jun 13 22:26:19 RAID kernel: [<ffffffff8101b011>] show_stack+0x21/0x40 Jun 13 22:26:19 RAID kernel: [<ffffffff81329447>] dump_stack+0x5c/0x85 Jun 13 22:26:19 RAID kernel: [<ffffffff8160cf6c>] mutex_lock+0x1c/0x38 Jun 13 22:26:19 RAID kernel: [<ffffffffa00945f1>] fc_rport_logoff+0x21/0xe0 [libfc] Jun 13 22:26:19 RAID kernel: [<ffffffffa00b0fe9>] fcoe_ctlr_timer_work+0x6a9/0xca0 [libfcoe] Jun 13 22:26:19 RAID kernel: [<ffffffff81097775>] process_one_work+0x155/0x440 Jun 13 22:26:19 RAID kernel: [<ffffffff810982b6>] worker_thread+0x116/0x4b0 Jun 13 22:26:19 RAID kernel: [<ffffffff8109d8a2>] kthread+0xd2/0xf0 Jun 13 22:26:19 RAID kernel: [<ffffffff8160f58f>] ret_from_fork+0x3f/0x70 Jun 13 22:26:19 RAID kernel: DWARF2 unwinder stuck at ret_from_fork+0x3f/0x70 Jun 13 22:26:19 RAID kernel: Jun 13 22:26:19 RAID kernel: Leftover inexact backtrace: Jun 13 22:26:19 RAID kernel: [<ffffffff8109d7d0>] ? kthread_park+0x50/0x50 Jun 13 22:26:51 RAID sshd[11500]: Accepted publickey for root from 192.168.101.100 port 33413 ssh2: DSA SHA256:p/NSgZGhYmtt2zdIWjlOuyPFGKDIf6OaB2FTiW8CV2c Jun 13 22:26:51 RAID sshd[11500]: pam_unix(sshd:session): session opened for user root by (uid=0) Jun 13 22:26:51 RAID systemd[1]: Created slice User Slice of root. Jun 13 22:26:51 RAID systemd[1]: Starting User Manager for UID 0... -- You are receiving this mail because: You are on the CC list for the bug.

1 82

[Bug 997052] New: when console is rotated splash screen is not
by bugzilla_noreply＠novell.com 11 Jul '19

11 Jul '19

http://bugzilla.suse.com/show_bug.cgi?id=997052 Bug ID: 997052 Summary: when console is rotated splash screen is not Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: msuchanek(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Hello, I boot with GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/system/swap splash=silent quiet showopts console fbcon=rotate:3" This can be detected by parsing the commandline or examining /sys/class/graphics/fbcon/rotate (3) and /sys/class/graphics/fb0/rotate (0) which should be more reliable should the console get rotated automagically by some other script. -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 1051306] New: kwin: horizontally maximizing window and unmaximizing it makes it grow by 8 pixels
by bugzilla_noreply＠novell.com 11 Jul '19

11 Jul '19

http://bugzilla.suse.com/show_bug.cgi?id=1051306 Bug ID: 1051306 Summary: kwin: horizontally maximizing window and unmaximizing it makes it grow by 8 pixels Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.3 Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: KDE Workspace (Plasma) Assignee: opensuse-kde-bugs(a)opensuse.org Reporter: mkubecek(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I started to encounter this problem after upgrade from 42.2 to 42.3. Steps to reproduce: 1. Make one window maximized only in vertical direction (e.g. by middle click on the "maximize" button) and check its geometry with xwininfo. 2. Maximize the window horizontally by right-clicking its "maximize" button. 3. Restore the geometry by right-clicking its "maximize" button again. 4. Check the geometry with xwininfo. Result: the position of window's top left corner is preserved, its width is larger by 8 pixels. This is especially annoying for windows aligned with right edge of the screen because maximizing and unmaximizing the window makes the window grow beyond screen edge. Notes: - horizontal position doesn't seem to matter; reproduced with windows aligned to left screen edge, aligned to right edge or somewhere between - the window must be maximized vertically; when it's not, its size is restored correctly (including windows aligned with top or bottom screen edge) - reproduced on two machines, one with a single 2560x1440 monitor, one with two 1920x1080 monitors (combined into 3840x1080 workspace) - 100% reproducible (on my machines with 42.3, that is) -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1054841] New: Hostname set in Yast not used by Wicked Service
by bugzilla_noreply＠novell.com 11 Jul '19

11 Jul '19

http://bugzilla.suse.com/show_bug.cgi?id=1054841 Bug ID: 1054841 Summary: Hostname set in Yast not used by Wicked Service Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.3 Hardware: x86-64 OS: Linux Status: NEW Severity: Normal Priority: P5 - None Component: Network Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: jr87654(a)gmx.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- DHCP client persists in sending DHCPREQUEST packets with 'OPTION: 12 ( 10) Host name' set to the original hostname generated automatically during installation, and not to the current user-friendly hostname reset using Yast -> Network Settings. The result is that my local DNS server (router dnsmasq) has the wrong name for my PC and reverse lookups by other network devices (eg reporting previous logins) show and log the wrong name. To replicate the issue, relevant settings in Yast -> Network Settings are: Global Options: Network Setup Method = wicked DHCP Client Options -> Hostname to Send = [user-friendly hostname] Overview: eth0 -> Network Card Setup -> Address -> Dynamic Address = DHCP (DHCP IP4 only) Hostname/DNS: Hostname = jeremy Assign Hostname to Loopback IP = yes (ticked) Set Hostname via DHCP = no All other values are installation defaults. There is only one network interface eth0, which is to wired LAN. No WLAN. Yast has correctly updated /etc/HOSTNAME. $HOST = $HOSTNAME = [user friendly hostname]. Likewise /bin/hostname returns the updated hostname. I used grep to scan the whole filesystem (recursively from the filesystem root as superuser, including /var /usr /etc). I can find no instance of a file containing the old hostname. This issue with DHCPREQUEST packets has persisted for days after the update hostname, etc was entered in Yast, during which the system was rebooted many times (and the router, too). So I have concluded that this is a bug in the DHCP client managed by Wicked Service v6.40-7.1. It may be a regression to bug 910323 reported resolved/fixed in 2015 for OpenSuse 13.2. -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1054425] New: boot hangs on loading initial ramdisk iniupgrade to kernel 4.4.79-19-default
by bugzilla_noreply＠novell.com 11 Jul '19

11 Jul '19

http://bugzilla.suse.com/show_bug.cgi?id=1054425 Bug ID: 1054425 Summary: boot hangs on loading initial ramdisk iniupgrade to kernel 4.4.79-19-default Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.3 Hardware: x86-64 OS: openSUSE 42.3 Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: denis.polom(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Fresh install on Lenovo T430u from iso LEAP 42.3 downloaded from repos. After the installation System boots fine. Then running 'zypper up' and reboot the laptop after finishing the updates makes system hanging on loading initial ram disk. Boot the OS is possible only by selecting to boot the older kernel on grub menu. Let me know details you need. -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 1053976] New: wicked: dearth info about IP_OPTIONS in ifcfg(5)
by bugzilla_noreply＠novell.com 11 Jul '19

11 Jul '19

http://bugzilla.suse.com/show_bug.cgi?id=1053976 Bug ID: 1053976 Summary: wicked: dearth info about IP_OPTIONS in ifcfg(5) Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.3 Hardware: All OS: openSUSE 42.3 Status: NEW Severity: Enhancement Priority: P5 - None Component: Network Assignee: wicked-maintainers(a)suse.de Reporter: mt(a)suse.com QA Contact: qa-bugs(a)suse.de CC: mfilka(a)suse.com, mt(a)suse.com, suse-20050616(a)bgcomp.co.uk, whdu(a)suse.com Found By: --- Blocker: --- +++ This bug was initially created as a clone of Bug #1053244 +++ I can set the default source IPv6 address via "ip addr change 2001:XXX:XX:2::FE/128 dev eth0 preferred_lft 0" We need someway of having this done automatically thought the ifcfg-* config files and yast. (In reply to Marius Tomaschewski from comment #2) > in ifcfg-eth0 it would be: > IPADDR[INDEX]='2001:XXX:XX:2::FE/128' > IP_OPTIONS[INDEX]='preferred_lft 0' (In reply to Bob Goddard from comment #4) > Yup, IP_OPTIONS seems to work. > > Looking at the man page for ifcfg, there is a dearth of information on that > setting, hence why I never knew about it. -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1053253] New: rpm should warn about unsigned package files
by bugzilla_noreply＠novell.com 11 Jul '19

11 Jul '19

http://bugzilla.suse.com/show_bug.cgi?id=1053253 Bug ID: 1053253 Summary: rpm should warn about unsigned package files Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.3 Hardware: All OS: openSUSE 42.3 Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: duge(a)pre-sense.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- rpm warns on package files with unknown signatures, but it doesn't warn if there's any signature at all. -- That's not just an dangerous behavior. It's also inconsistent and an user might get the impression, that rpm will warn if he installs an package file without valid signature, because he sees that warnings on unknown signed packages files. But in fact there will just be no warning if there isn't any signature at all. And this really isn't a rare scenario. A lot of software which isn't available through the openSUSE official or unofficial repos is being provided without instruction for configuring the vendors Zypper repo (if one exists). Mostly there are just instructions for installing an rpm package file. (in case of Google the package configures a Zypper repo at installation time - but then it's already too late) E.g.: - Google Chrome and Earth - Skype - Atom (GitHubs Editor - btw. why it's not available via OSS repo!? it's FOSS!) - Microsoft Visual Studio Code - ... -- rpm on package file with unknown signature: | $ rpm -i vim-7.4.326-8.3.x86_64_unknown-sig.rpm | warning: vim-7.4.326-8.3.x86_64_unknown-sig.rpm: Header V3 DSA/SHA1 | Signature, key ID 6aef2783: NOKEY | $ rpm -K vim-7.4.326-8.3.x86_64_unknown-sig.rpm | vim-7.4.326-8.3.x86_64_unknown-sig.rpm: (SHA1) DSA sha1 md5 (GPG) NOT OK (MISSING KEYS: GPG#6aef2783) rpm on package file without signature: | $ rpm -i vim-7.4.326-8.2.x86_64_unsigned.rpm | $ rpm -K vim-7.4.326-8.2.x86_64_unsigned.rpm | vim-7.4.326-8.2.x86_64_unsigned.rpm: sha1 md5 OK -- Zypper and YaST just received an update for 42.2 to solve an equivalent problem for unsigned repos and package files. (bug boo#1045735) And for 42.3 and equivalent update should be in the pipeline. But as described, in some scenarios package files will be installed without repo, directly from the local filesystem after download via webbrowser. A workaround to get a warning is using Zypper or YaST to install rpm files. Since that recent update they also warn about unsigned rpm files. But this shouldn't be an "nofix" reason for this bug. Because rpm is clearly there for installing rpm package files and it's behavior is inconsistent with unknown signed package files. Zypper on rpm without signature (YaST gives an equivalent warning and also asks before continuing) | $ zypper in vim-7.4.326-8.2.x86_64_unsigned.rpm | [...] | vim-7.4.326-8.2.x86_64 (Plain RPM files cache): Signature verification failed [6-File is unsigned] | Abort, retry, ignore? [a/r/i] (a): -- Nice to have: Asking before continuing like Zypper and YaST is also even better. The Zypper behavior probably can't be used for rpm because it might break existing stuff like scripts. But at least consider introducing an option -s, --strictsig which aborts installation (or asks for continuation) before installing an unsigned package. So the user can use this option for safe package installation via rpm. Related: - bug boo#1052100 -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 1051777] New: Adaptec 6405H problem
by bugzilla_noreply＠novell.com 11 Jul '19

11 Jul '19

http://bugzilla.suse.com/show_bug.cgi?id=1051777 Bug ID: 1051777 Summary: Adaptec 6405H problem Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.3 Hardware: x86-64 OS: openSUSE 42.3 Status: NEW Severity: Major Priority: P5 - None Component: KVM Assignee: kvm-bugs(a)forge.provo.novell.com Reporter: kiyomi.kakitsubata(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Hi, I have some problem with Adaptec(PMC-Sierra) 6405H SAS Host Bus Adapter. First,installing OS,when format target sas disk or installing rpm package, installer freeze or happen 'Unknown Error'. In dmesg kernell log, it seems file system crashed, but sas bus trace says sas disk returns queue full,but SAS HBA send messages infinity. I think,if sas disk returns queue full,SAS HBA must have wait few seconds or return busy to OS. Does it correct? Second, setting pci passthrough at kvm with virsh and virt-manager, guest OS can not power on and crash host OS. So,I could not setup guest OS. I tried other SAS HBA, Broadcom 9300-8E, I could setup guest OS. Other Environment is same. Perhaps,first and second problem is same problem. Chheers Kazufumi Watanabe -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1049661] New: Loglevel in OpenStack image is too verbose
by bugzilla_noreply＠novell.com 11 Jul '19

11 Jul '19

http://bugzilla.suse.com/show_bug.cgi?id=1049661 Bug ID: 1049661 Summary: Loglevel in OpenStack image is too verbose Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.3 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: gmoro(a)suse.com Reporter: mnowak(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 733135 --> http://bugzilla.suse.com/attachment.cgi?id=733135&action=edit screenshot of logs on console With OpenStack's image loglevel I get too much messages on console. printk is set to: 7 4 1 7 -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1049659] New: Leap JeOS OpenStack should use XFS file system
by bugzilla_noreply＠novell.com 11 Jul '19

11 Jul '19

http://bugzilla.suse.com/show_bug.cgi?id=1049659 Bug ID: 1049659 Summary: Leap JeOS OpenStack should use XFS file system Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.3 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: gmoro(a)suse.com Reporter: mnowak(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 733131 --> http://bugzilla.suse.com/attachment.cgi?id=733131&action=edit df -hT JeOS is using btrfs filesystem, but probably should use XFS (as SLES JeOS does). -- You are receiving this mail because: You are on the CC list for the bug.

1 3