August 2018 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1084758] New: seccheck fails to cleanup some temporary files created during daily and weekly run
by bugzilla_noreply＠novell.com 14 Feb '21

14 Feb '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1084758 Bug ID: 1084758 Summary: seccheck fails to cleanup some temporary files created during daily and weekly run Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.0 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: security-team(a)suse.de Reporter: d_werner(a)gmx.net QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 Build Identifier: During each run of the daily or weekly cron jobs of seccheck afterwards temporary files are left. Specifically these files are daily: created by the pattern specia_files_owner.XXXX in security_daily_helper.inc e.g. /tmp/specia_files_owner.Jx25 weekly: created by the pattern rpm-md5.XXXX in helper.inc e.g. /tmp/rpm-md5.AYWm This is observed with the rpm seccheck-3.0-lp150.2.3.noarch.rpm from Leap 15.0 Build 153.1 Reproducible: Always Steps to Reproduce: 1.have the seccheck rpm installed (and ensure the START_SECCHK="yes" which is the default) 2.let the time pass when the cron job triggers or tweak it to run "soon" 3.check if the files /tmp/rpm-md5.* or /tmp/specia_files_owner.* exist after the cronjob is finished dependent whether the daily or the weekly cron job was executed. Note: the weekly job can run for several minutes. Actual Results: Temporary files created by the cron job are left after the cron job completes. /tmp/specia_files_owner.???? /tmp/rpm-md5.???? Expected Results: seccheck should not leave temporary files after it finishes successfully. I do not consider this bug is not an actual security problem, it is just in a security related component. As far as I remember it even was already once fixed but crept in again. Note: this is not a new problem, AFAIK it also exists in Leap 42.3 and Tumbleweed, but maybe now is a good time to fix it and the fix is simple. -- You are receiving this mail because: You are on the CC list for the bug.

2 3

[Bug 1094834] New: Unable to install leap 15 on Lenovo T430 along with Windows 10 in dual boot
by bugzilla_noreply＠novell.com 13 Feb '21

13 Feb '21

http://bugzilla.suse.com/show_bug.cgi?id=1094834 Bug ID: 1094834 Summary: Unable to install leap 15 on Lenovo T430 along with Windows 10 in dual boot Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.0 Hardware: Other OS: Other Status: NEW Severity: Critical Priority: P5 - None Component: Installation Assignee: yast2-maintainers(a)suse.de Reporter: rashmiranjan.mohanty(a)microfocus.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- Created attachment 771520 --> http://bugzilla.suse.com/attachment.cgi?id=771520&action=edit Screenshot of hung install I am unable to install openSUSE Leap 15.0 on my Lenovo T430 laptop. It already has Windows 10 installed. I am trying to install Leap 15 as dual OS. It just gets stuck on the progress bar screen (After loading Kernel and before installer UI comes up). Attaching screenshot. System does not hang though. System responds to Ctrl+Alt+Delete fine and reboots. Additional information : 1. On the same laptop Windows 7 and OpenSUSE leap 42.3 were running fine in dual boot mode before formatting the whole system. 2. I tried DVD and NET media for Leap 15 and it gets stuck at same place. 3. Even tried installing Leap 42.3. That also got stuck in the progress screen. 4. Then I tried installing Fedora 27 and it installed fine. I know since the media is already released there may not be much that can be done to fix the issue in media, but if any workaround can be provided so that I can install Leap 15 on the system, I will be more than happy. -- You are receiving this mail because: You are on the CC list for the bug.

2 43

[Bug 1093098] New: document minimum disk size
by bugzilla_noreply＠novell.com 13 Feb '21

13 Feb '21

http://bugzilla.suse.com/show_bug.cgi?id=1093098 Bug ID: 1093098 Summary: document minimum disk size Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.0 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Release Notes Assignee: sknorr(a)suse.com Reporter: lnussel(a)suse.com QA Contact: lnussel(a)suse.com CC: ancor(a)suse.com Found By: --- Blocker: --- The installer will only propose a partitioning scheme if the available hard disk size is larger than 12GB. Administrators wanting to install e.g. very small virtual machines images will have to use the guided setup to tune the parameters for the partitioning manually. -- You are receiving this mail because: You are on the CC list for the bug.

2 11

[Bug 1091103] New: Release notes entry about automatic Qt HiDPI scaling
by bugzilla_noreply＠novell.com 13 Feb '21

13 Feb '21

http://bugzilla.suse.com/show_bug.cgi?id=1091103 Bug ID: 1091103 Summary: Release notes entry about automatic Qt HiDPI scaling Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.0 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Release Notes Assignee: sknorr(a)suse.com Reporter: fvogt(a)suse.com QA Contact: lnussel(a)suse.com CC: opensuse-kde-bugs(a)opensuse.org Found By: --- Blocker: --- Release notes entry for bsc#1089932 and related. It's a rather complicated topic unfortunately, with no easy fix or workarounds available. Qt supports automatic per-monitor scaling on X. It uses the DPI value of the virtual X screen to calculate the font size for the primary monitor, which is by default 96. It uses the relative DPI of the primary monitor to derive font DPI for all other monitors. If the primary monitor is HiDPI (>= 144dpi), this means the font has effectively a 0.5x scale on all monitors. Applications which request it (e.g. VLC) have too small text on all monitors. Applications which do not request scaling (e.g. YaST) are not affected and use the same DPI value on all monitors. Applications run on KDE Plasma or GNOME are not affected as Plasma disables automatic scaling by default and GNOME sets Xft.dpi according to the monitor scale. Workarounds: a) Use a non-HiDPI monitor as primary monitor. VLC is then scaled accordingly on the HiDPI monitor. b) Set the font DPI (Xft.dpi) using the DE configuration or "echo Xft.dpi: <value> | xrdb -nocpp -merge" to equal the DPI of the primary monitor c) Disable automatic scaling: export QT_AUTO_SCREEN_SCALE_FACTOR=0 (maybe this part into a separate section?) HiDPI support in sddm: To enable HiDPI support in sddm, edit /etc/sddm.conf and set: [X11] EnableHiDPI=true ServerArguments=-nolisten tcp -dpi <dpi> with <dpi> being 96*scale of the first monitor listed by "xrandr". -- You are receiving this mail because: You are on the CC list for the bug.

2 10

[Bug 1089315] New: Tracker bug for bugs impacting transactional-netboot
by bugzilla_noreply＠novell.com 11 Feb '21

11 Feb '21

http://bugzilla.suse.com/show_bug.cgi?id=1089315 Bug ID: 1089315 Summary: Tracker bug for bugs impacting transactional-netboot Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: fvogt(a)suse.com Reporter: fvogt(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- This is a tracker bug for all issues having an impact on transactional-netboot. -- You are receiving this mail because: You are on the CC list for the bug.

2 6

[Bug 1089349] New: overlayfs does not work with NFS as lower layer
by bugzilla_noreply＠novell.com 11 Feb '21

11 Feb '21

http://bugzilla.suse.com/show_bug.cgi?id=1089349 Bug ID: 1089349 Summary: overlayfs does not work with NFS as lower layer 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: fvogt(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 766955 --> http://bugzilla.suse.com/attachment.cgi?id=766955&action=edit 0001-ovl-Allow-copying-of-files-to-the-upper-layer-from-c.patch When replicating a file/dir from a lower to the upper layer, it tries to copy all xattrs. However, this fails with NFSv4 as it has a special "system.nfs4_acl" xattr" which can't be written if the upper layer isn't NFSv4 (which is not supported anyway). A patch which fixes this issue is attached, but I'm not very familiar with either overlayfs nor xattrs to be able to tell whether it's correct. -- You are receiving this mail because: You are on the CC list for the bug.

2 21

[Bug 912059] New: networkmanager plasmoid shows nearly everybody connected (although it seems that only one wpa2 is correctly connected
by bugzilla_noreply＠novell.com 11 Feb '21

11 Feb '21

http://bugzilla.opensuse.org/show_bug.cgi?id=912059 Bug ID: 912059 Summary: networkmanager plasmoid shows nearly everybody connected (although it seems that only one wpa2 is correctly connected Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: x86-64 OS: openSUSE 13.2 Status: NEW Severity: Minor Priority: P5 - None Component: KDE4 Applications Assignee: kde-maintainers(a)suse.de Reporter: stakanov(a)freenet.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 618858 --> http://bugzilla.opensuse.org/attachment.cgi?id=618858&action=edit wrong connection info of networkmanager plugin Create several users. Create in user A a connection with wpa2 encryption, choose: only this user can connect. Save and connect. Look at the list of the plasmoid: it shows all available wlan as not connected and the one you created as connected. Now change to user B or C. As you are still up with user A and you are connected, now in user B or C it should show the same as in user A. Only it should not be possible to end simply this connection or to start it. But you will be able to use it. What happens: in B or C respectively, the list of all available stations shows up as "connected". So in theory you are connected to all wireless of the area. All? No, some do show up correctly as "not connected" but the list here is so long that I can show only the beginning of the screen-shot. The output of ifconfig and netstat seem normal. So this seems to be more an apparent than a real bug. I join a screenshot. What should have done the program: show the correct connection information. Screen-shot: the only "real" connection iw the one with the button disconnect. The other ssids are from the neighborhood. -- You are receiving this mail because: You are on the CC list for the bug.

2 3

[Bug 1096072] New: systemd hangs on initrd-switch-root.service for 1.5 minutes when booting
by bugzilla_noreply＠novell.com 10 Feb '21

10 Feb '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1096072 Bug ID: 1096072 Summary: systemd hangs on initrd-switch-root.service for 1.5 minutes when booting Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.0 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: alarrosa(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 772558 --> http://bugzilla.opensuse.org/attachment.cgi?id=772558&action=edit journalctl --system --since "1 hour ago" After upgrading my Leap 42.3 system to Leap 15.0 it takes very long to boot up. Of that time, around 1.5 minutes (1:34) is spent on initrd-switch-root.service while it seems the system is doing nothing (at least the hard disk light stops blinking for all that time). The system stops just after: Jun 05 18:32:41 geeko systemd[1]: Switching root. Jun 05 18:32:41 geeko systemd-journald[154]: Journal stopped And then continues with: Jun 05 18:34:16 geeko systemd-journald[154]: Received SIGTERM from PID 1 (systemd). Jun 05 18:34:16 geeko kernel: systemd: 20 output lines suppressed due to ratelimiting Jun 05 18:34:16 geeko kernel: EXT4-fs (sda6): re-mounted. Opts: acl,user_xattr Jun 05 18:34:16 geeko systemd-journald[414]: Journal started Jun 05 18:34:16 geeko systemd-journald[414]: Runtime journal (/run/log/journal/f7cb102c5d6c079fd36e51615215ef87) is 8.0M, max 383.4M, 375.4M free. Jun 05 18:32:43 geeko systemd[1]: systemd 234 running in system mode. (+PAM -AUDIT +SELINUX -IMA +APPARMOR -SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT -GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD -IDN2 -IDN default-hierarchy=hybrid) Jun 05 18:32:43 geeko systemd[1]: Detected architecture x86-64. Jun 05 18:32:43 geeko systemd[1]: Set hostname to <geeko>. Jun 05 18:34:13 geeko systemd[1]: system-generators terminated by signal ALRM. Jun 05 18:34:16 geeko apparmor.systemd[420]: Restarting AppArmor Jun 05 18:34:13 geeko systemd[1]: Execution failed: Protocol error Note the systemd log from 18:32:43 being written after other logs from 18:34:16 and the "Execution failed: Protocol error" message which might be related. I tried enabling debug-shell.service, but that is started after systemd unfreezes. I attach the full output of journalctl --system --since "1 hour ago". Btw, for some reason, in this system, journalctl only shows the journal logs from the current boot, never showing logs from previous boots. Also, just in case it rings a bell, I also have this problem on the same system: https://bugzilla.opensuse.org/show_bug.cgi?id=1096050 -- You are receiving this mail because: You are on the CC list for the bug.

2 35

[Bug 980313] New: /usr/lib/zypp/plugins/commit/susemanager should be moved to susemanager related package and not be part of base salt-minion
by bugzilla_noreply＠novell.com 08 Feb '21

08 Feb '21

http://bugzilla.suse.com/show_bug.cgi?id=980313 Bug ID: 980313 Summary: /usr/lib/zypp/plugins/commit/susemanager should be moved to susemanager related package and not be part of base salt-minion Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: mrueckert(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- seen with salt-minion-2015.8.8-68.1.x86_64 from systemsmanagement:saltstack the salt setup on the machine was turned off atm and this noticably slows down all zypp operations. if this plugin is mostly for susemanager it shouldnt be part of the normal salt-minion package. if it is meant to be used with normal salt, i would recommend renaming it. -- You are receiving this mail because: You are on the CC list for the bug.

2 25

[Bug 978833] New: systemsmanagement:saltstack/salt broken pkgrepo.managed priority atribute
by bugzilla_noreply＠novell.com 08 Feb '21

08 Feb '21

http://bugzilla.suse.com/show_bug.cgi?id=978833 Bug ID: 978833 Summary: systemsmanagement:saltstack/salt broken pkgrepo.managed priority atribute Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bmaryniuk(a)suse.com Reporter: tchatzimichos(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- pkgrepo.managed priority attribute shows the following error: Failed to configure repo 'NON_Public:Infrastructure': zypper command failed: Invalid priority ''102''. Use a positive integer number. The greater the number, the lower the priority. -- You are receiving this mail because: You are on the CC list for the bug.

2 10