February 2022 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1176566] New: Installing ignition leads to unbootable system
by bugzilla_noreply＠suse.com 13 Mar '23

13 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1176566 Bug ID: 1176566 Summary: Installing ignition leads to unbootable system Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Critical Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: rombert(a)apache.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I've installed ignition locally on Tumbleweed, to be able to validate ignition files locally. After a reboot I was presented with an emergency shell, leading down a wild goose chase for disabling ignition permanently. It all went away after setting up a chroot and removing all traces of ignition, but it would be much much better if installing it would not lead to a broken system by default. I saw some errors related to the ignition generator, and the systemd unit file was broken, but could not save any logs unfortunately. But it should be easy enough to reproduce if anyone cares: # zypper in ignition # reboot (Might be related to #1172592) -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1189826] New: Severe screen flickering with kernel 5.13.12-1-default and i915
by bugzilla_noreply＠suse.com 12 Mar '23

12 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1189826 Bug ID: 1189826 Summary: Severe screen flickering with kernel 5.13.12-1-default and i915 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Major Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: javier(a)opensuse.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- My laptop's screen flickers so much with 5.13.12 that it renders my laptop unusable. One workaround is to close and open the lid. After resuming, it works fine - there is no flickering. Booting up from the KDE Live image works fine. I have used the same Tumbleweed version (20210820) as the one I have installed on my laptop. The only difference is that I have an encrypted /home partition on my laptop's SSD. Tested kernels: 5.10.16-1.3: OK 5.11.4-1.3: NON-OK 5.12.12-1: NON-OK 5.13.12-1: NON-OK KDE Plasma 5.22.4 KDE Frameworks 5.85.0 Qt 5.15.2 See the attachments for more details. -- You are receiving this mail because: You are on the CC list for the bug.

1 18

[Bug 1084017] New: YaST in Leap 15 fails to set boot flags correctly
by bugzilla_noreply＠novell.com 10 Mar '23

10 Mar '23

http://bugzilla.suse.com/show_bug.cgi?id=1084017 Bug ID: 1084017 Summary: YaST in Leap 15 fails to set boot flags correctly Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.0 Hardware: x86-64 OS: Other Status: NEW Severity: Major Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers(a)suse.de Reporter: Larry.Finger(a)lwfinger.net QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- Created attachment 762755 --> http://bugzilla.suse.com/attachment.cgi?id=762755&action=edit Compressed YaST2 logs My system has a GPT partitioning scheme and does not use EFI. I also put the boot block at the start of the active partition, and have generic boot code in the MBR. The active partition is indicated with the legacy_boot flag. A partial df for the system is: Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda3 60213124 9954072 47170668 18% / /dev/sda6 53826316 32795236 20576144 62% /var/tmp /dev/sda7 51255784 20631016 28050216 43% /TW /dev/sda4 60344404 22760752 36522788 39% /Leap42.3 /dev/sda5 711705020 393141448 282387980 59% /home tmpfs 809360 20 809340 1% /run/user/1000 Looking at the partitions with parted: GNU Parted 3.2 Using /dev/sda Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) print Model: ATA Samsung SSD 850 (scsi) Disk /dev/sda: 1024GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: pmbr_boot Number Start End Size File system Name Flags 1 1049kB 9437kB 8389kB bios_grub 2 9437kB 16.8GB 16.8GB linux-swap(v1) swap 3 16.8GB 79.7GB 62.9GB ext4 4 79.7GB 143GB 62.9GB ext4 msftdata 5 143GB 883GB 741GB ext4 msftdata 6 883GB 939GB 56.1GB ext4 msftdata 8 939GB 971GB 31.5GB ext4 7 971GB 1024GB 53.5GB ext4 legacy_boot, msftdata (parted) quit In this case, partition number 7 will be booted. Running YaST => System => Boot Loader changes nothing. If I want the automatic boot to choose Leap 15.0, I need to manually toggle the legacy_boot flag on partitions 7 and 3. Attached is a compressed copy of the /var/log/YaST2/ directory. -- You are receiving this mail because: You are on the CC list for the bug.

2 15

[Bug 1027519] New: Xen: Missing upstream bug fixes
by bugzilla_noreply＠novell.com 09 Mar '23

09 Mar '23

http://bugzilla.suse.com/show_bug.cgi?id=1027519 Bug ID: 1027519 Summary: Xen: Missing upstream bug fixes Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Xen Assignee: xen-bugs(a)suse.de Reporter: carnold(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- There are upstream patches fixing bugs needed for this version of Xen. -- You are receiving this mail because: You are on the CC list for the bug.

2 293

[Bug 1192409] New: /usr/lib/systemd/system/lircd.service may not have ProtectClock=true
by bugzilla_noreply＠suse.com 08 Mar '23

08 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1192409 Bug ID: 1192409 Summary: /usr/lib/systemd/system/lircd.service may not have ProtectClock=true Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: opensuse(a)mike.franken.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- With one of the last Tumbleweed snapshots some (all?) systemd service files got new options according to https://en.opensuse.org/openSUSE:Security_Features#Systemd_hardening_effort. But /usr/lib/systemd/system/lircd.service may not have set ProtectClock=true, because otherwise the daemon is not able to open the remote device: lircd-0.10.1[852]: Info: initializing '/dev/input/imon_remote' lircd-0.10.1[852]: Info: Using device: /dev/input/imon_remote lircd-0.10.1[852]: Error: unable to open '/dev/input/imon_remote' lircd-0.10.1[852]: Warning: Failed to initialize hardware lircd[852]: lircd-0.10.1[852]: Error: unable to open '/dev/input/imon_remote' lircd-0.10.1[852]: Error: unable to open '/dev/input/imon_remote' Without ProtectClock=true lircd works as expected. -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1048337] New: yast2-slide-show need to adjust the install path for new product builder
by bugzilla_noreply＠novell.com 08 Mar '23

08 Mar '23

http://bugzilla.suse.com/show_bug.cgi?id=1048337 Bug ID: 1048337 Summary: yast2-slide-show need to adjust the install path for new product builder Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers(a)suse.de Reporter: mlin(a)suse.com QA Contact: jsrain(a)suse.com CC: adrian(a)suse.com Found By: --- Blocker: --- I've tested this in the staging project, I hot-patched yast2-slide-show then all files are located at /usr/lib/skelcd/CD1 for new product builder, since DATADIR is obsoleted already then new product builder doesn't have process those files. you can find testdvd build log at https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:… so the main question: is product builder still support slideshow? if so where is the right path it should be? -- You are receiving this mail because: You are on the CC list for the bug.

2 8

[Bug 980292] New: Yast shouldn't allow running two instances of module at once
by bugzilla_noreply＠novell.com 08 Mar '23

08 Mar '23

http://bugzilla.suse.com/show_bug.cgi?id=980292 Bug ID: 980292 Summary: Yast shouldn't allow running two instances of module at once Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers(a)suse.de Reporter: hguo(a)suse.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- It's very easy to mistakenly double click on a module icon in Yast2, causing two instances of the module to be started, and there's absolutely no point in using more than one instance of any yast module. Please disallow double click on yast2, and prevent more than one instance of module to be started. -- You are receiving this mail because: You are on the CC list for the bug.

2 8

[opensuse-bugs] [Bug 1179248] New: Bluetooth speaker: KDE widget and bluetoothcl it paired and connected, but PulseAudio does not see it at all
by bugzilla_noreply＠suse.com 08 Mar '23

08 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1179248 Bug ID: 1179248 Summary: Bluetooth speaker: KDE widget and bluetoothcl it paired and connected, but PulseAudio does not see it at all Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: KDE Workspace (Plasma) Assignee: opensuse-kde-bugs(a)opensuse.org Reporter: ncutler(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- In Leap 15.1 with KDE and PulseAudio, I had no problem playing sound through speakers connected via bluetooth. It "just worked". After upgrading to Leap 15.2, it does not work. I go through the normal drill of pairing with and connecting to the device. I can see the device in both KDE's bluetooth widget and in bluetoothctl. It is connected. In Leap 15.1, after connection the device would appear in pavucontrol and I could direct an audio stream to it, and it would play. Now the device does not appear in pavucontrol. After a lot of googling I did figure out how to get log messages out of pulseaudio, but the procedure for doing so is bizarre and might actually deserve a separate bug report. Pulseaudio is run by systemd, but AFAICT the log messages just go to /dev/null (journalctl shows nothing). In order to see the log messages, I have to prevent systemd from starting pulseaudio, and then start it myself in an interactive session, while capturing its output to a file. -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1190681] New: Zig fails to build because of "Could NOT find lld (missing: LLD_LIBRARIES LLD_INCLUDE_DIRS) "
by bugzilla_noreply＠suse.com 07 Mar '23

07 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1190681 Bug ID: 1190681 Summary: Zig fails to build because of "Could NOT find lld (missing: LLD_LIBRARIES LLD_INCLUDE_DIRS) " Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Development Assignee: screening-team-bugs(a)suse.de Reporter: socvirnyl.estela(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Greetings! I have a few problems building zig in openSUSE Tumbleweed. **What I want to do** I want to successfully build zig in openSUSE Tumbleweed with llvm, clang, and lld provided by the distro's repositories. **Expected Outcome** Builds successfully **Actual Outcome** Failed to build **What I did** In `~/local/zig-0.8.1`, I use the following commands based on how others build zig: ```sh cmake -G Ninja -B build \ -DCMAKE_BUILD_TYPE=None \ -DCMAKE_INSTALL_PREFIX=$(llvm-config --prefix) \ -DZIG_PREFER_CLANG_CPP_DYLIB=ON . ``` ```sh ninja -C build ninja: Entering directory `build' [19/164] Building CXX object CMakeFiles/zigcpp.dir/src/zig_llvm.cpp.o FAILED: CMakeFiles/zigcpp.dir/src/zig_llvm.cpp.o /usr/bin/c++ -I/home/uncomfy/local/zig-0.8.1/deps/SoftFloat-3e/source/include -I/home/uncomfy/local/zig-0.8.1 -I/home/uncomfy/local/zig-0.8.1/build -I/home/uncomfy/local/zig-0.8.1/src -I/home/uncomfy/local/zig-0.8.1/src/stage1 -std=c++14 -DZIG_LINK_MODE=Dynamic -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D_GNU_SOURCE -fvisibility-inlines-hidden -fno-exceptions -fno-rtti -Werror=type-limits -Wno-missing-braces -Wno-comment -MD -MT CMakeFiles/zigcpp.dir/src/zig_llvm.cpp.o -MF CMakeFiles/zigcpp.dir/src/zig_llvm.cpp.o.d -o CMakeFiles/zigcpp.dir/src/zig_llvm.cpp.o -c /home/uncomfy/local/zig-0.8.1/src/zig_llvm.cpp /home/uncomfy/local/zig-0.8.1/src/zig_llvm.cpp:67:10: fatal error: lld/Common/Driver.h: No such file or directory 67 | #include <lld/Common/Driver.h> | ^~~~~~~~~~~~~~~~~~~~~ compilation terminated. [28/164] Building CXX object CMakeFiles/zigcpp.dir/src/zig_clang_cc1_main.cpp.o ninja: build stopped: subcommand failed. ``` **What I found out** Someone in Discord assisted me and gave me the link of the build logs. We found out that the reason it fails might be because of this line: ``` # These are only available as static libraries, which we don't ship. rm -rf %{buildroot}%{_includedir}/{clang-tidy,lld} ``` It means `/usr/include/lld` does not exist in llvm-devel. Thus, zig won't be able to build. **Why do I want to include those static libraries** Because some distributions already ship zig in their respective repositories, I want to also build zig succesfully and propose that it should be added in openSUSE's repos in the future. **What could be changed to remove the problem** Including the static libraries in the llvm-devel packages and the respective headers so that applications can build against these. -- You are receiving this mail because: You are on the CC list for the bug.

1 13

[Bug 1114673] New: New UI for firewalld: interface not assigned to the right zone when changed to public in first run
by bugzilla_noreply＠novell.com 07 Mar '23

07 Mar '23

http://bugzilla.suse.com/show_bug.cgi?id=1114673 Bug ID: 1114673 Summary: New UI for firewalld: interface not assigned to the right zone when changed to public in first run Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers(a)suse.de Reporter: jeriveramoya(a)suse.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- Interface is not assigned to the right zone after following steps: - Open new UI for firewalld: yast2 firewall - Assign interface to different zone (for example public) - In Zones, set different zone (for example trusted) as default. - Accept - Check with firewall-cmd interface assignation: firewall-cmd --list-interfaces --zone=public | grep ens4 (is not there) but firewall-cmd --list-interfaces --zone=trusted | grep ens4 (it succeeds and it is pointing to the default zone not the one that was assigned) (same result also after trying a firewall-cmd --reload) Assignation works in general, but in this combination and just when the user enters first to this screen and set previous steps, does not work (perhaps some wrong initialization). Expected result: Point to the interface that is assigned in the UI (in the example, to public) -- You are receiving this mail because: You are on the CC list for the bug.

2 33