December 2019 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1047218] New: trackerbug: packages do not build reproducibly from including build time
by bugzilla_noreply＠novell.com 07 Apr '23

07 Apr '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1047218 Bug ID: 1047218 Summary: trackerbug: packages do not build reproducibly from including build time Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: All OS: SUSE Other Status: CONFIRMED Severity: Normal Priority: P5 - None Component: Development Assignee: bwiedemann(a)suse.com Reporter: bwiedemann(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: Development Blocker: --- See also https://reproducible-builds.org/ and https://reproducible-builds.org/specs/source-date-epoch/ When packages include the current time of build it results in binaries that differ on every build and thus trigger rebuilds of depending packages and are published to mirrors and users when actually nothing really changed. -- You are receiving this mail because: You are on the CC list for the bug.

2 30

[Bug 1131931] New: OCFS2: Defragmentation error: No space left on device
by bugzilla_noreply＠novell.com 07 Apr '23

07 Apr '23

http://bugzilla.suse.com/show_bug.cgi?id=1131931 Bug ID: 1131931 Summary: OCFS2: Defragmentation error: No space left on device Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: High Availability Assignee: ha-bugs(a)suse.de Reporter: weikai.wang(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 802412 --> http://bugzilla.suse.com/attachment.cgi?id=802412&action=edit this script is used to generate disk framentation when I used the defragfs.ocfs2 to clean up disk fragmentation that generated by the attached shell script. you could execute the scrip by command "./defragfs_test.sh -d DEVICE -m MOUNT_POINT -n CLUSTER_NAME -s pcmk -o /tmp" You should use the device on your cluster replace DEVICE, use the same way replace MOUNT_POINT and CLUSTER_NAME. Then use the command defragfs.ocfs2 MOUNT_POINT. And if no accident, you will see some message like this: “ defragfs.ocfs2 1.8.5 [1/201]/mnt/ocfs2/tmp_file:Success [ERROR]Move extent failed:"/mnt/ocfs2/test_from_dd1" - No space left on device [2/201]/mnt/ocfs2/test_from_dd1:Failed [ERROR]Move extent failed:"/mnt/ocfs2/test_from_dd2" - No space left on device [3/201]/mnt/ocfs2/test_from_dd2:Failed [ERROR]Move extent failed:"/mnt/ocfs2/test_from_dd3" - No space left on device ” but if you execute defragfs.ocfs2 MOUNT_POINT again, the error message will not show again. and all the defragmentation will pass. please make sure your device's capacity is more tha 1G. Some times this error can make mount, unmount, and mkfs crushed. -- You are receiving this mail because: You are on the CC list for the bug.

2 3

[Bug 1155207] New: systemctl command line completion is very slow
by bugzilla_noreply＠novell.com 06 Apr '23

06 Apr '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1155207 Bug ID: 1155207 Summary: systemctl command line completion is very slow Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: carlos.e.r(a)opensuse.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- systemctl command line completion is very slow Suppose I type: systemctl status smart[tab][tab] and I get nothing. One second, two seconds... so I insist and hit tab several times, and after several seconds I get (one line per second): Isengard:~ # systemctl status smart smartcard.target smartd.service smartd_generate_opts.path smartd_generate_opts.service Isengard:~ # systemctl status smart smartcard.target smartd.service smartd_generate_opts.path smartd_generate_opts.service Isengard:~ # systemctl status smart smartcard.target smartd.service smartd_generate_opts.path smartd_generate_opts.service Isengard:~ # systemctl status smart and then I can type "d" and enter. Why is it that slow? It is an M2 disk. ie, SSD technology. It responds instantly when completing a normal command: Isengard:~ # smart smart_agetty smartctl smartd Isengard:~ # smart And that system is not busy at all, load 0.20. I can replicate the issue on other machines, and has been so probably for a year or so. Google "systemctl completion slow" finds reports on other distributions and several media. <https://bugzilla.redhat.com/show_bug.cgi?id=1491668> <https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1471723> and: <https://github.com/systemd/systemd/issues/7185> -- You are receiving this mail because: You are on the CC list for the bug.

2 2

[Bug 1159528] New: keybase client package is extremely outdated, plus lacks all gui elements
by bugzilla_noreply＠novell.com 06 Apr '23

06 Apr '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1159528 Bug ID: 1159528 Summary: keybase client package is extremely outdated, plus lacks all gui elements Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: Mathias.Homann(a)opensuse.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- the keybase package that comes packaged in openSUSE Leap 15.1 is outdated... to the ponit of being a prehistoric artefact: bundled comes version 2.11 - current from keybase.io is 5.1.1.... also, it lacks all gui elements - probably because it is such an old version. please update to the latest version. -- You are receiving this mail because: You are on the CC list for the bug.

2 2

[Bug 1126900] New: health-checker: grub2-editenv: error: cannot open `/boot/grub2/grubenv': Read-only file system.
by bugzilla_noreply＠novell.com 06 Apr '23

06 Apr '23

http://bugzilla.suse.com/show_bug.cgi?id=1126900 Bug ID: 1126900 Summary: health-checker: grub2-editenv: error: cannot open `/boot/grub2/grubenv': Read-only file system. Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kubic Assignee: iforster(a)suse.com Reporter: kukuk(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- >From a health-checker run: Clearing GRUB flag + grub2-editenv - set health_checker_flag=0 grub2-editenv: error: cannot open `/boot/grub2/grubenv': Read-only file system. Starting health check -- You are receiving this mail because: You are on the CC list for the bug.

2 12

[Bug 1159595] New: Installed vms use a path-id for suspend instead of uuid.
by bugzilla_noreply＠novell.com 05 Apr '23

05 Apr '23

http://bugzilla.suse.com/show_bug.cgi?id=1159595 Bug ID: 1159595 Summary: Installed vms use a path-id for suspend instead of uuid. Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers(a)suse.de Reporter: william.brown(a)suse.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- When the system is installed with default partitioning (no changes), which should use UUID's, suspend to disk in /etc/default/grub is configured with swap by a path-id instead. This can lead to VM's that are unable to boot when their swap partition changes location (IE changing from virtio to scsi) or a hardware machine that changes pci paths in some way (relocation of a disk controller or disk controller replacement due to RMA etc). This causes machines to be unbootable because the resume=/dev/disk/path-id can never be resolved and has an infinite timeout. The machine then must be forced off and the resolution steps are unclear Work around is to add noresume at boot, and to edit /etc/default/grub post install to remove the resume option. See also: https://bugzilla.suse.com/show_bug.cgi?id=1159236 -- You are receiving this mail because: You are on the CC list for the bug.

2 7

[Bug 1146936] New: nmcli-examples: add examples of bonding + vlan + bridge
by bugzilla_noreply＠novell.com 04 Apr '23

04 Apr '23

http://bugzilla.suse.com/show_bug.cgi?id=1146936 Bug ID: 1146936 Summary: nmcli-examples: add examples of bonding + vlan + bridge Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Network Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: william.brown(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Configuring a bond + vlan + bridge is not completely straightforward or clear with nmcli. An example should be added such as: nmcli conn add type bond con-name bond0 ifname bond0 mode 802.3ad ipv4.method disabled ipv6.method ignore nmcli connection add type ethernet con-name bond0-eth1 ifname eth1 master bond0 slave-type bond nmcli connection add type ethernet con-name bond0-eth2 ifname eth2 master bond0 slave-type bond nmcli connection add type bridge con-name net_18 ifname net_18 ipv4.method disabled ipv6.method ignore nmcli connection add type vlan con-name bond0.18 ifname bond0.18 dev bond0 id 18 master net_18 slave-type bridge This is suitable for libvirt/vms to use the bridges. -- You are receiving this mail because: You are on the CC list for the bug.

2 2

[Bug 1088738] New: xhost setting fails to have affect in /etc/gdm/Xsession --- "no protocol specified"
by bugzilla_noreply＠novell.com 31 Mar '23

31 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1088738 Bug ID: 1088738 Summary: xhost setting fails to have affect in /etc/gdm/Xsession --- "no protocol specified" Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Major Priority: P5 - None Component: GNOME Assignee: bnc-team-gnome(a)forge.provo.novell.com Reporter: noah(a)chromakey.io QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- line 154 xhost+ si:localuser ... needs to be in /etc/X11/xinit/xinitrc.d/what-ever.sh ... ... or maybe somewhere else all I know is that in Xsession it fails to have any affect ... effectively breaking the X11 gnome access for remote logins/ssh/etc. I'd expect a lot of bug reports of people angry, confused .. and complaining about "no protocol specified" errors. Thanks! -noah -- You are receiving this mail because: You are on the CC list for the bug.

2 3

[Bug 1157881] New: mount.nfs improve error reporting: "Connection *WHERE*TO* timed out"
by bugzilla_noreply＠novell.com 28 Mar '23

28 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1157881 Bug ID: 1157881 Summary: mount.nfs improve error reporting: "Connection *WHERE*TO* timed out" Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: All OS: Other Status: NEW Severity: Minor Priority: P5 - None Component: Network Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: 7eggert(a)gmx.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- When one of the nfs mounts times out, it gets reported as "Connection timed out". This is semi-helpful and thus semi-qualifies as a bug as well as a feature request. Please forward this to upstream. (Also not being able to mount triggers a bug in systemd to unmount unrelated mounts. One of my nfs servers is currently unresponsive but the other servers do work, yet systemd unmounts several other mounts. mount.nfs not reporting the cause didn't help me to find the cause.) -- You are receiving this mail because: You are on the CC list for the bug.

2 1

[Bug 1127591] New: zypper option "ssl_capath" not working for mirror URLs from metalink file
by bugzilla_noreply＠novell.com 28 Mar '23

28 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1127591 Bug ID: 1127591 Summary: zypper option "ssl_capath" not working for mirror URLs from metalink file Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.0 Hardware: x86-64 OS: SUSE Other Status: NEW Severity: Normal Priority: P5 - None Component: libzypp Assignee: zypp-maintainers(a)forge.provo.novell.com Reporter: cunix(a)bitmessage.ch QA Contact: qa-bugs(a)suse.de CC: security-team(a)suse.de Found By: --- Blocker: --- Using zypper (version: 1.14.12) for the update repository of openSUSE Leap 15.0 with the option baseurl=https://download.opensuse.org/update/leap/15.0/oss/?proxy=127.0.0.1… does not use the here configured trusted root certificates for mirror URLs, probably retrieved from a metalink file. The configured path is used for the initial connection to download.opensuse.org but following requests to mirrors seem to fallback to the system trusted certs from /etc/ssl/certs. If the mirrors' root CA is trusted in "ssl_capath=/path/to/directory/with/c_rehash/rootCAs" but not in /etc/ssl/certs, zypper,libzypp, multi-curl or something else aborts the TLS-Handshake with failure "Unknown CA (48)" and falls futher back to http (without transport layer encryption). Question for cc'ed security-team to answer: If using clear text is considered a security flaw where zypper is configured to use (https-)encryption, this might have security implications. Some Scenarios: Assume download.opensuse.org is signed by CA A and the mirror by CA B Assume further, ssl_capath=/path/to/directory/with/c_rehash/rootCAs is directory C and directory D is /etc/ssl/certs 1. If C includes A and B and in D at least B is not available, I would expect zypper to encrypt both connection, but the request to the mirror is not. 2. If A is not in C, no data (meta link file) is retrieved and therefore no mirror is connected - Good! No fallback of looking for A in D occurs. 3. If A is in C and B in D, both connections are encrypted. 4. If A is in C and B not in C and not in D, the mirror is contacted unencrypted - here I'm unsure if using plain text in this scenario is correct or if it should fail. So, in my opinion, 1. is the bug, 3. a workaround and 4. perhaps needs a zypper option to configure, if clear text fallback should be allowed. Another question is, if /etc/ssl/certs should actually be consulted when the option "ssl_capath" is used and pointing to a different directory. https://bugzilla.opensuse.org/show_bug.cgi?id=933839 might be related (similar setup). Problem and solution might be similar, too. By the way, is there a debugging option to dump the traffic from inside the encrypted connection? Especially being able to read the metalink file with the listed mirrors is of interest. -- You are receiving this mail because: You are on the CC list for the bug.

2 7