June 2018 - openSUSE Bugs - openSUSE Mailing Lists

[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

[Bug 1032452] New: salt-cloud package misses deployment scripts
by bugzilla_noreply＠novell.com 08 Feb '21

08 Feb '21

http://bugzilla.suse.com/show_bug.cgi?id=1032452 Bug ID: 1032452 Summary: salt-cloud package misses deployment scripts 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: dkarakasilis(a)suse.com 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: There is a number of scripts that salt-cloud uses in order to "saltify" (aka bootstrap) the minions: https://github.com/saltstack/salt/tree/develop/salt/cloud/deploy One of them (bootstrap-salt.sh) is the default when no specific (or custom) script is specified in configuration. None of our packages (salt, salt-cloud) provide that script. As a result, when a machine is started on some public cloud (only tried ec2 driver), the machine doesn't get salt-master or salt-minion services installed or run. The bootstrap process is completely ignored. After copying the bootstrap-salt.sh script from the github repo in "/usr/lib/python2.7/site-packages/salt/cloud/deploy" directory, the machines gets saltified. One thing to keep in mind though, if we are going to package those files, is that there is a "salt-cloud -u" command that fetches the latest versions from i-dont-know-where. That might mean, our users will use versions of those scripts that weren't packaged (or tested) by us. The 'salt-cloud -u' command doesn't fetch anything in my case, I don't know if this is because of the files missing in the first place or some other problem. Reproducible: Always Steps to Reproduce: 1. In OpenSUSE LEAP 42.2 install the packages salt-cloud and salt 2. Create ec2 provider and profile configuration 3. Try to create a saltified machine. E.g. "salt-cloud -p my_ec2_profile my_machine_name" Actual Results: The machine is created but there is no salt related package installed and no salt service running. We should get at least salt-minion running. Expected Results: Depending on configuration we should get "salt-minion" services installed and running. If we set "make_master: True" in our configuration we should also get salt-master service installed and running. below are an ec2 provider and profile examples. Replace placeholders with something working. > cat /etc/salt/cloud.providers.d/my-ec2.provider.conf my-ec2-provider: id: your_id_here key: 'your_key_here' keyname: your_key_name_as_it_appears_in_aws_console subnetid: comment_out_if_no_subnet_is_used private_key: your_pem_key_path # Make sure it is owned by whatever user salt is run as driver: ec2 ssh_interface: public_ips > cat /etc/salt/cloud.profiles.d/base_ec2.conf base_ec2: provider: my-ec2-provider # Opensuse image image: ami-eada30fc size: t2.micro make_master: True ssh_username: ec2-user -- You are receiving this mail because: You are on the CC list for the bug.

2 28

[Bug 1020831] New: All salt commands hang and cause salt-master to crash soon after
by bugzilla_noreply＠novell.com 08 Feb '21

08 Feb '21

http://bugzilla.suse.com/show_bug.cgi?id=1020831 Bug ID: 1020831 Summary: All salt commands hang and cause salt-master to crash soon after Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: hguo(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 710818 --> http://bugzilla.suse.com/attachment.cgi?id=710818&action=edit master journal I started 3 fresh instances of Leap 42.2 on EC2, then proceed to install all updates and salt. Two minions can successfully join the master, but then all salt commands issued by master hang and cause salt-master to crash soon after a python error is raised. See attached log files. -- You are receiving this mail because: You are on the CC list for the bug.

2 41

[Bug 1058115] New: ORC tracker
by bugzilla_noreply＠novell.com 05 Feb '21

05 Feb '21

http://bugzilla.suse.com/show_bug.cgi?id=1058115 Bug ID: 1058115 Summary: ORC tracker Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: jslaby(a)suse.com Reporter: jslaby(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- This is a tracker for ORC patches. -- You are receiving this mail because: You are on the CC list for the bug.

2 102

[Bug 1046104] New: Monospaced font SourceCodePro is bold by default after update to texlive 2017
by bugzilla_noreply＠novell.com 02 Feb '21

02 Feb '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1046104 Bug ID: 1046104 Summary: Monospaced font SourceCodePro is bold by default after update to texlive 2017 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: mail(a)philipp-wagner.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 730330 --> http://bugzilla.opensuse.org/attachment.cgi?id=730330&action=edit Screenshot with texlive-sourcecodepro installed Since the last update including the new texlive 2017 packages, the default monospace font (SourceCodePro) on my system was overwritten with a bold one. Things are better explained in a picture as seen in the attached screenshots. I got things back to normal by deinstalling the texlive versions of the font with > sudo zypper remove texlive-sourcecodepro* Now the following packets are installed: > LANG=C sudo zypper search sourcecodepro Loading repository data... Reading installed packages... S | Name | Summary | Type ---+-----------------------------+----------------------------------------------------------+-------- i+ | adobe-sourcecodepro-fonts | A set of OpenType fonts designed for coding environments | package | texlive-sourcecodepro | Use SourceCodePro with TeX(-alike) systems | package | texlive-sourcecodepro-doc | Documentation for texlive-sourcecodepro | package | texlive-sourcecodepro-fonts | Severed fonts for texlive-sourcecodepro | package I've confirmed with fc-match that if the texlive packages are installed, the texlive version of SourceCodePro is used. Otherwise, it's the version from the adobe-sourcecodepro-fonts package. I've also attached the output of "fc-match -v monospace" before and after deinstalling the texlive package. My system information: > cat /etc/os-release NAME="openSUSE Tumbleweed" # VERSION="20170625" ID=opensuse ID_LIKE="suse" VERSION_ID="20170625" PRETTY_NAME="openSUSE Tumbleweed" ANSI_COLOR="0;32" CPE_NAME="cpe:/o:opensuse:tumbleweed:20170625" BUG_REPORT_URL="https://bugs.opensuse.org" HOME_URL="https://www.opensuse.org/" -- You are receiving this mail because: You are on the CC list for the bug.

2 8