October 2024 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1229427] New: VUL-0: CVE-2024-39338: python-nbdime: axios: server-side request forgery due to requests for path relative URLs being processed as protocol relative URLs
by bugzilla_noreply＠suse.com 04 Oct '24

04 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1229427 Bug ID: 1229427 Summary: VUL-0: CVE-2024-39338: python-nbdime: axios: server-side request forgery due to requests for path relative URLs being processed as protocol relative URLs Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.6 Hardware: Other URL: https://smash.suse.de/issue/417034/ OS: Other Status: NEW Severity: Critical Priority: P5 - None Component: Security Assignee: python-maintainers(a)suse.com Reporter: camila.matos(a)suse.com QA Contact: security-team(a)suse.de CC: camila.matos(a)suse.com, security-team(a)suse.de, smash_bz(a)suse.de Blocks: 1229421 Target Milestone: --- Found By: Security Response Team Blocker: --- +++ This bug was initially created as a clone of Bug #1229421 +++ axios 1.7.2 allows SSRF via unexpected behavior where requests for path relative URLs get processed as protocol relative URLs. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-39338 https://www.cve.org/CVERecord?id=CVE-2024-39338 https://github.com/axios/axios/releases https://jeffhacks.com/advisories/2024/06/24/CVE-2024-39338.html https://bugzilla.redhat.com/show_bug.cgi?id=2304369 -- You are receiving this mail because: You are on the CC list for the bug.

1 11

[Bug 1222859] New: VUL-0: CVE-2024-32019: netdata: local privilege escalation and command execution via untrusted search path
by bugzilla_noreply＠suse.com 04 Oct '24

04 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1222859 Bug ID: 1222859 Summary: VUL-0: CVE-2024-32019: netdata: local privilege escalation and command execution via untrusted search path Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.6 Hardware: Other URL: https://smash.suse.de/issue/401694/ OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Security Assignee: mia(a)0x0.st Reporter: smash_bz(a)suse.de QA Contact: security-team(a)suse.de CC: camila.matos(a)suse.com Target Milestone: --- Found By: Security Response Team Blocker: --- Netdata is an open source observability tool. In affected versions the `ndsudo` tool shipped with affected versions of the Netdata Agent allows an attacker to run arbitrary programs with root permissions. The `ndsudo` tool is packaged as a `root`-owned executable with the SUID bit set. It only runs a restricted set of external commands, but its search paths are supplied by the `PATH` environment variable. This allows an attacker to control where `ndsudo` looks for these commands, which may be a path the attacker has write access to. This may lead to local privilege escalation. This vulnerability has been addressed in versions 1.45.3 and 1.45.2-169. Users are advised to upgrade. There are no known workarounds for this vulnerability. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-32019 https://www.cve.org/CVERecord?id=CVE-2024-32019 https://github.com/netdata/netdata/pull/17377 https://github.com/netdata/netdata/security/advisories/GHSA-pmhq-4cxq-wj93 https://bugzilla.redhat.com/show_bug.cgi?id=2274984 -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1230631] New: zypper update called from ansible hangs with ZYPP_SINGLE_RPMTRANS
by bugzilla_noreply＠suse.com 04 Oct '24

04 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1230631 Bug ID: 1230631 Summary: zypper update called from ansible hangs with ZYPP_SINGLE_RPMTRANS Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.6 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: libzypp Assignee: zypp-maintainers(a)suse.de Reporter: martin.wilck(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- A zypper update process is hanging for more than an hour. I'm using the ansible zypper module to update a system. The playbook is as simple as it gets: --- - name: Update and reboot hosts: home become: yes gather_facts: yes tasks: - name: update all packages community.general.zypper: name: '*' state: latest update_cache: yes The update task is hanging for one of the hosts. Note: ZYPP_SINGLE_RPMTRANS is set on this host. libzypp 17.34.1-150600.3.4.6 zypper 1.14.71-150600.10.2.7 Last lines in /var/log/zypp/history: 2024-09-17 10:26:53|command|root@ares|'/usr/bin/zypper' '--quiet' '--non-interactive' '--xmlout' 'update' '--type' 'package' '--auto-agree-with-licenses' '--no-recommends'| 2024-09-17 10:26:55|install|glibc-extra|2.38-150600.14.8.2|x86_64||repo-sle-update|9b79c4b8215408fadb96713529ba340b8e32e6331210a3d6bde79740df5c39ab| # 2024-09-17 10:26:55 glibc-extra installed ok 2024-09-17 10:26:55|install|glibc|2.38-150600.14.8.2|x86_64||repo-sle-update|b48788acf37cf950c73ce0f6b9ef49cabe372841045d773e0d18eac312a7b298| # 2024-09-17 10:26:55 glibc installed ok 2024-09-17 10:26:55|install|glibc-32bit|2.38-150600.14.8.2|x86_64||repo-sle-update|7ee6524dfb18e81854e1b4ccbec16f1bddc6a787d305f9028e5c13ff78a0cb63| # 2024-09-17 10:26:55 glibc-32bit installed ok 2024-09-17 10:26:55|install|libexpat1|2.4.4-150400.3.22.1|x86_64||repo-sle-update|372db388086c3f4dc9057b876272f8e6f5ecfb4ecaf80719fe2dcc1b738815e9| # 2024-09-17 10:26:55 libexpat1 installed ok 2024-09-17 10:26:55|install|libuuid1|2.39.3-150600.4.12.2|x86_64||repo-sle-update|3b3fbdcb9e25068fcf0129723f5a8636d4463a7b16b5d75ea54f7c00d3eb7878| # 2024-09-17 10:26:55 libuuid1 installed ok 2024-09-17 10:26:55|install|libopenssl3|3.1.4-150600.5.15.1|x86_64||repo-sle-update|a00145c1de9f3875b2d43d7df9488727fcd3f7821793bdddd3628d6297b9cba3| # 2024-09-17 10:26:55 libopenssl3 installed ok 2024-09-17 10:26:55|install|libblkid1|2.39.3-150600.4.12.2|x86_64||repo-sle-update|7c099998d5c5652dfd019a08e0bb3505ce13d645d33bc4fa23fa7d8b17501236| # 2024-09-17 10:26:55 libblkid1 installed ok 2024-09-17 10:26:55|install|libjpeg8|8.3.2-lp156.236.1|x86_64||graphics|474e415043a57881528e7e7494c5423cea5de82f5bd25cb0ce0685469110fac2| # 2024-09-17 10:26:55 libjpeg8 installed ok Last lines in zypper.log: 2024-09-17 10:26:53 <1> ares(22706) [zypp] TargetImpl.cc(commitInSingleTransaction):1966 TargetImpl::commit(<list>CommitPolicy( DownloadInHeaps ))586 2024-09-17 10:26:54 <1> ares(22706) [zypp::exec++] forkspawnengine.cc(start):274 Executing '/usr/lib/zypp/zypp-rpm' 2024-09-17 10:26:54 <1> ares(22706) [zypp::exec++] forkspawnengine.cc(start):427 pid 23678 launched 2024-09-17 10:26:54 <1> ares(22706) [Progress++] progressdata.cc(report):75 {#1|Executing pretrans script for: ImageMagick-config-7-SUSE-7.1.1.38-lp156.757.1.x86_64} START 2024-09-17 10:26:54 <1> ares(22706) [Progress++] progressdata.cc(report):95 {#1|Executing pretrans script for: ImageMagick-config-7-SUSE-7.1.1.38-lp156.757.1.x86_64} END 2024-09-17 10:26:54 <1> ares(22706) [Progress++] progressdata.cc(report):75 {#2|Preparing} START 2024-09-17 10:26:54 <1> ares(22706) [Progress++] progressdata.cc(report):95 {#2|Preparing} END 2024-09-17 10:26:54 <1> ares(22706) [Progress++] progressdata.cc(report):75 {#3|Installing: glibc-extra-2.38-150600.14.8.2.x86_64} START 2024-09-17 10:26:55 <1> ares(22706) [Progress++] progressdata.cc(report):95 {#3|Installing: glibc-extra-2.38-150600.14.8.2.x86_64} END 2024-09-17 10:26:55 <1> ares(22706) [zypp-core] PathInfo.cc(unlink):711 unlink /var/cache/zypp/packages/repo-sle-update/x86_64/glibc-extra-2.38-150600.14.8.2.x86_64.rpm 2024-09-17 10:26:55 <1> ares(22706) [Progress++] progressdata.cc(report):75 {#4|Installing: glibc-2.38-150600.14.8.2.x86_64} START 2024-09-17 10:26:55 <1> ares(22706) [Progress++] progressdata.cc(report):95 {#4|Installing: glibc-2.38-150600.14.8.2.x86_64} END 2024-09-17 10:26:55 <1> ares(22706) [zypp-core] PathInfo.cc(unlink):711 unlink /var/cache/zypp/packages/repo-sle-update/x86_64/glibc-2.38-150600.14.8.2.x86_64.rpm [ ... some more packages ... ] 2024-09-17 10:26:55 <1> ares(22706) [zypp-core] PathInfo.cc(unlink):711 unlink /var/cache/zypp/packages/repo-sle-update/x86_64/libblkid1-2.39.3-150600.4.12.2.x86_64.rpm 2024-09-17 10:26:55 <1> ares(22706) [Progress++] progressdata.cc(report):75 {#15|Executing postin script for: libblkid1-2.39.3-150600.4.12.2.x86_64} START 2024-09-17 10:26:55 <1> ares(22706) [Progress++] progressdata.cc(report):95 {#15|Executing postin script for: libblkid1-2.39.3-150600.4.12.2.x86_64} END 2024-09-17 10:26:55 <1> ares(22706) [Progress++] progressdata.cc(report):75 {#16|Installing: libjpeg8-8.3.2-lp156.236.1.x86_64} START 2024-09-17 10:26:55 <1> ares(22706) [Progress++] progressdata.cc(report):95 {#16|Installing: libjpeg8-8.3.2-lp156.236.1.x86_64} END 2024-09-17 10:26:55 <1> ares(22706) [zypp-core] PathInfo.cc(unlink):711 unlink /var/cache/zypp/packages/graphics/x86_64/libjpeg8-8.3.2-lp156.236.1.x86_64.rpm Local process tree: |-sshd,2493 | `-sshd,21676 | `-sshd,21714 | `-sh,22336 -c su root -c '/bin/sh -c '"'"'echo BECOME-SUCCESS-nitvvgwxsoijrshepjskqvafwibxpvha ; /usr/bin/python3 /home/martin/.ansible/tmp/ansible-tmp-1726561374.1568432-22131-10361590113718/AnsiballZ_zypper.py'"'"'' && sleep 0 | `-su,22380 root -c /bin/sh -c 'echo BECOME-SUCCESS-nitvvgwxsoijrshepjskqvafwibxpvha ; /usr/bin/python3 /home/martin/.ansible/tmp/ansible-tmp-1726561374.1568432-22131-10361590113718/AnsiballZ_zypper.py' | `-sh,22381 -c echo BECOME-SUCCESS-nitvvgwxsoijrshepjskqvafwibxpvha ; /usr/bin/python3 /home/martin/.ansible/tmp/ansible-tmp-1726561374.1568432-22131-10361590113718/AnsiballZ_zypper.py | `-python3,22382 /home/martin/.ansible/tmp/ansible-tmp-1726561374.1568432-22131-10361590113718/AnsiballZ_zypper.py | `-Zypp-main,22706 --quiet --non-interactive --xmlout update --type package --auto-agree-with-licenses --no-recommends | |-Zypp-main,23678 | | |-systemd-inhibit,23680 --what=sleep:shutdown:idle --who=zypp-rpm --mode=block --why=Zypp commit running. /usr/bin/cat | | | `-cat,23681 | | `-{Zypp-main},23679 | |-btrfs-defrag-pl,22770 /usr/lib/zypp/plugins/commit/btrfs-defrag-plugin.sh | |-snapper-zypp-pl,22776 | |-systemd-inhibit,22768 --what=sleep:shutdown:idle --who=zypp --mode=block --why=Zypp commit running. /usr/bin/cat | | `-cat,22769 | |-{Zypp-main},22712 | |-{Zypp-main},22753 | |-{Zypp-main},22754 | `-{Zypp-main},22755 strace over ID 22706 and all children shows that only 22706 is active: [pid 22706] clock_gettime(CLOCK_MONOTONIC, {tv_sec=1293344, tv_nsec=222637363}) = 0 [pid 22706] clock_gettime(CLOCK_MONOTONIC, {tv_sec=1293344, tv_nsec=222779630}) = 0 [pid 22706] poll([{fd=53, events=POLLIN|POLLERR|POLLHUP}], 1, 100) = 0 (Timeout) [pid 22706] clock_gettime(CLOCK_MONOTONIC, {tv_sec=1293344, tv_nsec=323566963}) = 0 [pid 22706] clock_gettime(CLOCK_MONOTONIC, {tv_sec=1293344, tv_nsec=323697986}) = 0 [pid 22706] poll([{fd=53, events=POLLIN|POLLERR|POLLHUP}], 1, 100) = 0 (Timeout) [pid 22706] clock_gettime(CLOCK_MONOTONIC, {tv_sec=1293344, tv_nsec=424317979}) [pid 22706] clock_gettime(CLOCK_MONOTONIC, {tv_sec=1293344, tv_nsec=424476310}) = 0 [pid 22706] poll([{fd=53, events=POLLIN|POLLERR|POLLHUP}], 1, 100) = 0 (Timeout) [pid 22706] clock_gettime(CLOCK_MONOTONIC, {tv_sec=1293344, tv_nsec=525107967}) = 0 22706 is polling on fd 53, the other end of which is owned by PID 23678: /proc/22706/fd lr-x------ 1 root root 64 Sep 17 11:05 53 -> pipe:[6204057] /proc/23678/fd l-wx------ 1 root root 64 Sep 17 11:05 13 -> pipe:[6204057] l-wx------ 1 root root 64 Sep 17 11:05 4 -> pipe:[6204057] PID 23678 is writing to a different pipe: root@ares:~ # strace -s 512 -p 23678 strace: Process 23678 attached write(3, "\n!zypp.proto.target.PackageProgress\22\4\10k\20'", 41 /proc/22706 lr-x------ 1 root root 64 Sep 17 11:05 49 -> pipe:[6204056] /proc/23678 l-wx------ 1 root root 64 Sep 17 11:05 3 -> pipe:[6204056] cat /proc/23678/stack [<0>] pipe_write+0x2c3/0x630 [<0>] vfs_write+0x2e4/0x380 [<0>] ksys_write+0x50/0xe0 [<0>] do_syscall_64+0x5b/0x80 [<0>] entry_SYSCALL_64_after_hwframe+0x7c/0xe6 Apparently PID 23678 hangs because the other end of the pipe doesn't read it. PID 22706, which is the process supposed to read the pipe, doesn't poll it's fd. -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 1181950] Firefox can't save file name with double quotes
by bugzilla_noreply＠suse.com 04 Oct '24

04 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1181950 https://bugzilla.suse.com/show_bug.cgi?id=1181950#c7 hui <sturm-fr(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |FIXED --- Comment #7 from hui <sturm-fr(a)web.de> --- Problem fixed with Plasma 6 and actual Firefox -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1231040] [Build 20240926] kdump_and_crash: mkdumprd reports 'Kernel not found' with 6.11
by bugzilla_noreply＠suse.com 04 Oct '24

04 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1231040 https://bugzilla.suse.com/show_bug.cgi?id=1231040#c10 --- Comment #10 from Michal Suchanek <msuchanek(a)suse.com> --- The requires are copied to kernel-default-base https://github.com/SUSE/kernel-source/blob/master/rpm/kernel-subpackage-spec -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1231244] Installing udev in a chroot or non booted container is not creating the system users it provides
by bugzilla_noreply＠suse.com 04 Oct '24

04 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1231244 https://bugzilla.suse.com/show_bug.cgi?id=1231244#c2 --- Comment #2 from David Cassany <dcassany(a)suse.com> --- (In reply to Franck Bui from comment #1) > (In reply to David Cassany from comment #0) > > Udev package provides the setup of systemd-timesync user in > > `/usr/lib/sysusers.d/systemd-timesync.conf`, however this user is not > > created as part of the installation. > > Any changes in /etc are delayed until the first boot. > > One goal behind it is to support for stateless systems. Another reason is > that it also matches the behavior you would face on transactional systems > during package installations at runtime. In this case changes in /etc are > not available until the system reboots. I see your point, however the purpose if it is lost when other packages are calling `systemd-sysusers` in their scriptlets. > > Not sure why `system-user-*` packages don't do the same though. Well, IMHO in chroot and containers make sense to create these users, I'd expect to have wwwrun user created in a container after installing `system-user-wwwrun` as the container purpose could easily be running an HTTPS server. > > Is the consistency of system user creation your only concern or do see other > issues ? The consistency is a concern, yes, however by biggest concern is noticing these users are mostly always created by the installation of another unrelated package and this is misleading. Just to give another example, in all images built with KIWI udev users are created in a chroot env because other system-user-* were installed in the same transaction, so these are causally created, to me it looks like just a coincidence they were created. Just pull a fresh image and boot it and check the `/var/log/zypp/history` and grep for 'systemd-timesync', something like that will be the result: # 2024-09-27 07:39:12 systemd-status-mail.rpm installed ok # Additional rpm output: # /usr/bin/systemd-sysusers --replace=/usr/lib/sysusers.d/systemd-status-mail.conf - # Creating group 'systemd-status-mail' with GID 484. # Creating user 'systemd-status-mail' (systemd-status-mail user) with UID 484 and GID 484. # Creating group 'systemd-timesync' with GID 483. # Creating user 'systemd-timesync' (systemd Time Synchronization) with UID 483 and GID 483. So systemd-timesync got installed as a side effect of the installation of `systemd-status-mail`. In our images (Elemental team) we are seeing the `systemd-timesync` being created as part of the installation of `system-user-nobody` which is was pretty puzzling. The actual reason this issue popped up now is because we are building an OS tree inside a container and our current transaction with latest TW image does not longer include `system-user-nobody` because this is already part of the image. So suddenly the installation of udev (and some other packages) did not pull any `system-user-*` package neither it pulled any other package triggering the users creation. So all in all, I don't know if there is an established mechanism udev uses to create those users on reboot, but to my eyes this is mostly unused, because udev is such a fundamental system package that usually the first time is installed happens in chroot like environment together with other essential packages to bootstrap a system and in this process the users a created on behalf of other user packages. For all that I think the safest would be udev being consistent with other `system-user-*` package or even splitting the users in devoted `system-user-*` packages. To my eyes it could also be considered to change `system-user-*` behavior to not create any other user than what they are providing, but this feel risky and with potential unexpected side effects to my understanding. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1231301] New: updates qemu and transactional-update cannot be installed because of conflicts
by bugzilla_noreply＠suse.com 04 Oct '24

04 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1231301 Bug ID: 1231301 Summary: updates qemu and transactional-update cannot be installed because of conflicts Classification: openSUSE Product: openSUSE Leap Micro Version: 6.0 Hardware: x86-64 OS: openSUSE Leap 15.5 Status: NEW Severity: Normal Priority: P5 - None Component: Base Assignee: screening-team-bugs(a)suse.de Reporter: zluo(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 877743 --> https://bugzilla.suse.com/attachment.cgi?id=877743&action=edit yast logs I downloaded openSUSE-Leap-Micro.x86_64-Default-qcow.qcow2 from opensuse.org and installed it and enabled cockpit for testing. after login to cockpit webUI, I found that updates are available. There are about 90 packages. I triggered 'Update and Reboot'. After reboot I found 2 packages are still available for update. I thought maybe there is not installed for some reason. I did it again and it shows again that update of 2 packages(qemu, transactional-update) are available. I check this then by using transactional-update shell and found out that there some conflict issue with these packages. -- transactional update # zypper lp Refreshing service 'openSUSE'. Loading repository data... Reading installed packages... Repository | Name | Category | Severity | Interactive | Status | Since | Summary ----------------+------+-------------+----------+-------------+--------+-------+-------------------------------------------- repo-main (6.0) | 10 | security | critical | --- | needed | - | Security update for qemu repo-main (6.0) | 38 | recommended | moderate | --- | needed | - | Recommended update for transactional-update Found 2 applicable patches: 2 patches needed (1 security patch) transactional update # zypper patch Refreshing service 'openSUSE'. Loading repository data... Reading installed packages... Resolving package dependencies... 2 Problems: Problem: the installed cockpit-machines-305-1.1.noarch requires 'qemu-hw-usb-redirect', but this requirement cannot be provided Problem: This request will break your system! Problem: the installed cockpit-machines-305-1.1.noarch requires 'qemu-hw-usb-redirect', but this requirement cannot be provided not installable providers: qemu-hw-usb-redirect-8.2.5-1.1.x86_64[openSUSE:repo-main] Solution 1: Following actions will be done: deinstallation of cockpit-machines-305-1.1.noarch deinstallation of qemu-hw-usb-redirect-8.2.1-2.8.x86_64 deinstallation of qemu-hw-display-virtio-vga-8.2.1-2.8.x86_64 deinstallation of qemu-hw-display-virtio-gpu-pci-8.2.1-2.8.x86_64 deinstallation of patterns-base-kvm_host-6.0-1.2.x86_64 deinstallation of qemu-hw-display-virtio-gpu-8.2.1-2.8.x86_64 deinstallation of qemu-guest-agent-8.2.1-2.8.x86_64 Solution 2: do not install patch:10-1.noarch Solution 3: break cockpit-machines-305-1.1.noarch by ignoring some of its dependencies Choose from above solutions by number or skip, retry or cancel [1/2/3/s/r/c/d/?] (c): 1 Problem: This request will break your system! the installed tukit-4.6.6-1.1.x86_64 requires 'libtukit4 = 4.6.6-1.1', but this requirement cannot be provided Solution 1: Following actions will be done: ignore the warning of a broken system (requires:transactional-update) deinstallation of tukit-4.6.6-1.1.x86_64 deinstallation of dracut-transactional-update-4.6.6-1.1.noarch deinstallation of transactional-update-4.6.6-1.1.x86_64 deinstallation of patterns-base-transactional-6.0-1.2.x86_64 deinstallation of transactional-update-zypp-config-4.6.6-1.1.noarch Solution 2: do not install patch:38-1.noarch Solution 3: break tukit-4.6.6-1.1.x86_64 by ignoring some of its dependencies Choose from above solutions by number or skip, retry or cancel [1/2/3/s/r/c/d/?] (c): 1 Resolving dependencies... Resolving package dependencies... 2 Problems: Problem: This request will break your system! Problem: the installed patterns-base-cockpit-6.0-1.2.x86_64 requires '(cockpit-machines if libvirt-daemon-qemu)', but this requirement cannot be provided Problem: This request will break your system! conflicting requests Solution 1: Following actions will be done: keep transactional-update-4.6.6-1.1.x86_64 keep tukit-4.6.6-1.1.x86_64 Solution 2: ignore the warning of a broken system (requires:transactional-update) Choose from above solutions by number or skip, retry or cancel [1/2/3/4/s/r/c/d/?] (c): 1 Resolving dependencies... Resolving package dependencies... 2 Problems: Problem: This request will break your system! the installed transactional-update-4.6.6-1.1.x86_64 requires 'dracut-transactional-update = 4.6.6-1.1', but this requirement cannot be provided deleted providers: dracut-transactional-update-4.6.6-1.1.noarch Solution 1: Following actions will be done: ignore the warning of a broken system (requires:transactional-update) deinstallation of transactional-update-4.6.6-1.1.x86_64 Solution 2: keep dracut-transactional-update-4.6.6-1.1.noarch Solution 3: break transactional-update-4.6.6-1.1.x86_64 by ignoring some of its dependencies Choose from above solutions by number or skip, retry or cancel [1/2/3/s/r/c/d/?] (c): -- see yast2 logs. -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1231300] New: cockpit cannot handle available updates if packages have conflict with dependency issues
by bugzilla_noreply＠suse.com 04 Oct '24

04 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1231300 Bug ID: 1231300 Summary: cockpit cannot handle available updates if packages have conflict with dependency issues Classification: openSUSE Product: openSUSE Leap Micro Version: 6.0 Hardware: Other OS: openSUSE Leap 15.5 Status: NEW Severity: Normal Priority: P5 - None Component: Cockpit Assignee: Cockpit-bugs(a)suse.de Reporter: zluo(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 877739 --> https://bugzilla.suse.com/attachment.cgi?id=877739&action=edit screen shot 1 I downloaded openSUSE-Leap-Micro.x86_64-Default-qcow.qcow2 from opensuse.org and installed it and enabled cockpit for testing. after login to cockpit webUI, I found that updates are available. There are about 90 packages. I triggered 'Update and Reboot'. After reboot I found 2 packages are still available for update. I thought maybe there is not installed for some reason. I did it again and it shows again that update of 2 packages(qemu, transactional-update) are available. Well I check this then by using transactional-update shell and found out that there some conflict issue with these packages. For this issue I will open another report. Because this behavior is misleading and it doesn't tell potential issue with update workflow, I would ask for an improvement or at least show here possible conflicts of packages dependency. see screen shot. -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1230596] Wifi not working with Qualcomm WCN785x on current version of kernel-firmware-ath12k
by bugzilla_noreply＠suse.com 04 Oct '24

04 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1230596 https://bugzilla.suse.com/show_bug.cgi?id=1230596#c6 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Takashi Iwai <tiwai(a)suse.com> --- I took the fixed firmware from Qualcomm's git tree now. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1231040] [Build 20240926] kdump_and_crash: mkdumprd reports 'Kernel not found' with 6.11
by bugzilla_noreply＠suse.com 04 Oct '24

04 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1231040 https://bugzilla.suse.com/show_bug.cgi?id=1231040#c9 --- Comment #9 from Martin Wilck <martin.wilck(a)suse.com> --- (In reply to Jiri Slaby from comment #3) > Might be that kernel-default-base is installed before > suse-module-tools-scriptlets, so that the post-install is not called (as per > `run_if_exists`)? We have these: kernel-binary.spec.in:Requires(pre): suse-kernel-rpm-scriptlets kernel-binary.spec.in:Requires(post): suse-kernel-rpm-scriptlets kernel-binary.spec.in:Requires: suse-kernel-rpm-scriptlets kernel-binary.spec.in:Requires(preun): suse-kernel-rpm-scriptlets kernel-binary.spec.in:Requires(postun): suse-kernel-rpm-scriptlets so AFAICS, no, unless the deps of kernel-default-base are different from those of kernel-default itself. -- You are receiving this mail because: You are on the CC list for the bug.

1 0