October 2024 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1179536] URL of "crash" package needs updating
by bugzilla_noreply＠suse.com 22 Oct '24

22 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1179536 https://bugzilla.suse.com/show_bug.cgi?id=1179536#c18 Giovanni Gherdovich <giovanni.gherdovich(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|IN_PROGRESS |RESOLVED --- Comment #18 from Giovanni Gherdovich <giovanni.gherdovich(a)suse.com> --- Closing as resolved. On the latest Tumbleweed the url is correctly listed as "https://crash-utility.github.io". Thanks David Mair for pushing the change. # cat /etc/os-release NAME="openSUSE Tumbleweed" # VERSION="20241018" ID="opensuse-tumbleweed" ID_LIKE="opensuse suse" VERSION_ID="20241018" ... # zypper info crash Information for package crash: ------------------------------ Repository : Main Repository (OSS) Name : crash Version : 8.0.5-1.7 Arch : x86_64 Vendor : openSUSE Installed Size : 11.7 MiB Installed : No Status : not installed Source package : crash-8.0.5-1.7.src Upstream URL : https://crash-utility.github.io/ ... -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1231710] New: VUL-0: CVE-2024-49195: godot: mbedtls: buffer underrun in pkwrite when writing an opaque key pair
by bugzilla_noreply＠suse.com 22 Oct '24

22 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1231710 Bug ID: 1231710 Summary: VUL-0: CVE-2024-49195: godot: mbedtls: buffer underrun in pkwrite when writing an opaque key pair Classification: openSUSE Product: openSUSE Distribution Version: Leap 16.0 Hardware: Other URL: https://smash.suse.de/issue/424184/ OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: security-team(a)suse.de Reporter: andrea.mattiazzo(a)suse.com QA Contact: qa-bugs(a)suse.de CC: andrea.mattiazzo(a)suse.com, security-team(a)suse.de, smash_bz(a)suse.de Depends on: 1231707, 1231708, 1231709 Target Milestone: --- Found By: Security Response Team Blocker: --- Mbed TLS 3.5.x through 3.6.x before 3.6.2 has a buffer underrun in pkwrite when writing an opaque key pair References: https://mbed-tls.readthedocs.io/en/latest/tech-updates/security-advisories/ http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-49195 https://www.cve.org/CVERecord?id=CVE-2024-49195 https://mbed-tls.readthedocs.io/en/latest/security-advisories/mbedtls-secur… Patch: https://github.com/Mbed-TLS/mbedtls/commit/5f1c8a720fdcc62cb9854da7b3a64a77… -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1231756] xe driver oopses with Arc A750 (56a1) on aarch64
by bugzilla_noreply＠suse.com 22 Oct '24

22 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1231756 https://bugzilla.suse.com/show_bug.cgi?id=1231756#c5 --- Comment #5 from Patrik Jakobsson <patrik.jakobsson(a)suse.com> --- (In reply to Andreas Färber from comment #3) > I've verified that i915 is indeed limited to X86: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/ > drivers/gpu/drm/i915/Kconfig > > So at a minimum we could set CONFIG_DRM_XE_FORCE_PROBE="*" on riscv64 and > arm64. > > Even better would be if upstream would conditionalize .force_probe = 1 for > !X86 or rather !CONFIG_DRM_I915, so that no distro workarounds become > necessary. > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/ > drivers/gpu/drm/xe/xe_pci.c I'm not sure that's a good idea. We would enable experimental support for all current and future GPUs by default. The purpose of the force_probe flag is to have the user explicitly saying that they want to run an experimental driver. Another option could be to make the i915 driver build and run on non-x86 architectures but I'm not sure how much work that would require. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1231482] [Build 20241008-SELinux] openQA test fails in boot_into_snapshot: root: no shell: Permission denied
by bugzilla_noreply＠suse.com 22 Oct '24

22 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1231482 https://bugzilla.suse.com/show_bug.cgi?id=1231482#c7 Fabian Vogt <fvogt(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|cathy.hu(a)suse.com |yast2-maintainers(a)suse.de Status|NEW |CONFIRMED --- Comment #7 from Fabian Vogt <fvogt(a)suse.com> --- (In reply to Arvin Schnell from comment #6) > I have done a test installation and AFAIS the filesystem is labeled > during the first boot of the system - not during installation. So > the first snapshot is made before the filesystem is labeled. I think > that is wrong - the labeling must happen before the snapshot is made. Yes, which is why this needs to be fixed in the installer. Kiwi does it properly: https://github.com/OSInside/kiwi/blob/5416ae8f602fbf0a0466528f9a1be47368b4f… -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1231595] Encrypted root file system fsck error is difficult to recover
by bugzilla_noreply＠suse.com 22 Oct '24

22 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1231595 https://bugzilla.suse.com/show_bug.cgi?id=1231595#c2 Antonio Feijoo <antonio.feijoo(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |antonio.feijoo(a)suse.com --- Comment #2 from Antonio Feijoo <antonio.feijoo(a)suse.com> --- (In reply to Andi Kleen from comment #0) > On a system with encrypted root file system I had a corruption in the ext4 > orphan list that dropped the initrd into the recovery shell when trying to > mount sysroot. > > I had to recover by > > cat /proc/cmdline > e2fsck UUID=<copy root uuid from cmdline> > > While I was able to do that it was a very cumbersome procedure to copy the > UUID exactly and was non obvious and difficult for the user. AFAIK e2fsck also works with the device file (i.e. /dev/xxx) > It would be good if the initrd detected such a case and offers to run fsck > by itself. That is already done by the systemd-fsck@.service, which should be present and run in the initrd (check `journalctl -b | grep -e "Switching root" -e fsck`). E.g. on one of my test systems: > # journalctl -b -o short-monotonic | grep -e "Switching root" -e fsck > [ 9.581526] localhost systemd[1]: Starting systemd-fsck-root.service... > [ 9.618736] localhost systemd[1]: Finished systemd-fsck-root.service. > [ 9.774147] localhost systemd[1]: Switching root. > [ 10.565853] localhost systemd[1]: Created slice system-systemd\x2dfsck.slice. > [ 10.566330] localhost systemd[1]: systemd-fsck-root.service: Deactivated successfully. > [ 10.566341] localhost systemd[1]: Stopped systemd-fsck-root.service. > [ 10.850086] localhost systemd[1]: Starting systemd-fsck(a)dev-disk-by\x2duuid-96D6\x2d4309.service... > [ 10.889881] localhost systemd-fsck[874]: fsck.fat 4.2 (2021-01-31) > [ 10.889881] localhost systemd-fsck[874]: /dev/vda1: 12 files, 1513/130811 clusters > [ 10.894121] localhost systemd[1]: Finished systemd-fsck(a)dev-disk-by\x2duuid-96D6\x2d4309.service. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 855173] NetworkManager / nm-applet fails to set the configured DNS
by bugzilla_noreply＠suse.com 22 Oct '24

22 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=855173 https://bugzilla.suse.com/show_bug.cgi?id=855173#c6 Jonathan Kang <songchuan.kang(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(forgotten_BvSZatp | |Mk2(a)user.net) CC| |songchuan.kang(a)suse.com --- Comment #6 from Jonathan Kang <songchuan.kang(a)suse.com> --- Can this still be reproduced in latest Tumbleweed? It's been quite a few years and a lot has been changed. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1231482] [Build 20241008-SELinux] openQA test fails in boot_into_snapshot: root: no shell: Permission denied
by bugzilla_noreply＠suse.com 22 Oct '24

22 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1231482 https://bugzilla.suse.com/show_bug.cgi?id=1231482#c6 Arvin Schnell <aschnell(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(cathy.hu(a)suse.com | |) | Assignee|aschnell(a)suse.com |cathy.hu(a)suse.com --- Comment #6 from Arvin Schnell <aschnell(a)suse.com> --- I have done a test installation and AFAIS the filesystem is labeled during the first boot of the system - not during installation. So the first snapshot is made before the filesystem is labeled. I think that is wrong - the labeling must happen before the snapshot is made. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1231773] dracut cannot create initrd & initramfs on initrd-6.11.2-1-default
by bugzilla_noreply＠suse.com 22 Oct '24

22 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1231773 https://bugzilla.suse.com/show_bug.cgi?id=1231773#c34 Thomas Blume <thomas.blume(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(declanseeley@iclo | |ud.com) | --- Comment #34 from Thomas Blume <thomas.blume(a)suse.com> --- (In reply to 40476 WebDev from comment #33) > see this post for where i got my solution > https://forums.opensuse.org/t/unable-to-create-initial-ram-filesystem-canno… > boot/179392/44 Interesting case, not sure what could empty an important binary like that. Would be good if you would report it when you find the reason. However, if there are no objections, I will close the bug therewith. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1231662] [Build 20241014] openQA test of JeOS-extra fails in kdump_and_crash - Error updating initrd while calling 'mkdumprd'
by bugzilla_noreply＠suse.com 22 Oct '24

22 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1231662 https://bugzilla.suse.com/show_bug.cgi?id=1231662#c1 Santiago Zarate <santiago.zarate(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |santiago.zarate(a)suse.com --- Comment #1 from Santiago Zarate <santiago.zarate(a)suse.com> --- looking at the logs: > 2024-10-15 08:45:39 <3> localhost.localdomain(53696) [Ruby] modules/Kdump.rb(update_initrd_with):419 Error updating initrd, see /var/log/YaST2/y2logmkinitrd or call mkdumprd manually > 2024-10-15 08:45:39 <3> localhost.localdomain(53696) [Ruby] modules/Kdump.rb(update_initrd_with):420 Error updating initrd while calling 'mkdumprd'. See /var/log/YaST2/y2logmkinitrd for details. # cat /var/log/YaST2/y2logmkinitrd > Kernel not found. Though looking at the logs, system is running: 6.11.2-1-default > 2024-10-15T08:36:15.591952+00:00 localhost [RPM][53586]: Transaction ID 670e297e started > 2024-10-15T08:36:51.228311+00:00 localhost [RPM][53586]: install kernel-default-debugsource-6.11.2-1.2.aarch64: success > 2024-10-15T08:36:51.296736+00:00 localhost [RPM][53586]: install kernel-default-debugsource-6.11.2-1.2.aarch64: success > 2024-10-15T08:36:51.296875+00:00 localhost [RPM][53586]: Transaction ID 670e297e finished: 0 > 2024-10-15T08:37:11.544524+00:00 localhost [RPM][53593]: Transaction ID 670e29aa started > 2024-10-15T08:44:53.779988+00:00 localhost [RPM][53593]: install kernel-default-debuginfo-6.11.2-1.2.aarch64: success > 2024-10-15T08:44:53.825653+00:00 localhost [RPM][53593]: install kernel-default-debuginfo-6.11.2-1.2.aarch64: success > 2024-10-15T08:44:53.835874+00:00 localhost [RPM][53593]: Transaction ID 670e29aa finished: 0 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1215653] patterns-microos-cockpit/microos_cockpit does not include cockpit-ws
by bugzilla_noreply＠suse.com 22 Oct '24

22 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1215653 https://bugzilla.suse.com/show_bug.cgi?id=1215653#c1 Luna D Dragon <luna.dragon(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Luna D Dragon <luna.dragon(a)suse.com> --- This has been resolved -- You are receiving this mail because: You are on the CC list for the bug.

1 0