January 2024 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1218697] New: OpenSUSE installation on Renesas RZ platform broken
by bugzilla_noreply＠suse.com 07 Feb '24

07 Feb '24

https://bugzilla.suse.com/show_bug.cgi?id=1218697 Bug ID: 1218697 Summary: OpenSUSE installation on Renesas RZ platform broken Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: aarch64 OS: Other Status: NEW Severity: Critical Priority: P5 - None Component: Kernel:Drivers Assignee: kernel-bugs(a)suse.de Reporter: john.vincent.xa(a)bp.renesas.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 871747 --> https://bugzilla.suse.com/attachment.cgi?id=871747&action=edit Kernel log failed with "openSUSE-Tumbleweed-DVD-aarch64-Snapshot20240107-Media.iso" Hi For Renesas RZ platforms we were able to install Tumbleweed OpenSUSE until 2023-11-29, but it is failing on the latest installer on 2024-01-07 openSUSE-Tumbleweed-DVD-aarch64-Snapshot20231129-Media.iso : working ok openSUSE-Tumbleweed-DVD-aarch64-Snapshot20240107-Media.iso : Failed due to "Loading Installation System (4/6) to (6/6)" switched to network. I've added the boot logs for these 2 versions. The key difference between these two is, on the newer installer (2024-01-07), the loading install Systems 4 to 6 are missing and the error message saying the installation files are expected to be downloaded. But previously we were able to install all the requires files from the USB itself and no network connection was required. Is something changed in the newer installers? Best Regards John -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1219300] New: VUL-0: CVE-2021-33829: otrs: ckeditor: cross-site scripting allows remote attackers to inject executable JavaScript code
by bugzilla_noreply＠suse.com 07 Feb '24

07 Feb '24

https://bugzilla.suse.com/show_bug.cgi?id=1219300 Bug ID: 1219300 Summary: VUL-0: CVE-2021-33829: otrs: ckeditor: cross-site scripting allows remote attackers to inject executable JavaScript code Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.6 Hardware: Other URL: https://smash.suse.de/issue/301642/ OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: chris(a)computersalat.de Reporter: smash_bz(a)suse.de QA Contact: security-team(a)suse.de CC: abergmann(a)suse.com Target Milestone: --- Found By: Security Response Team Blocker: --- OTRS Security Advisory 2024-04 OSA-2024-04 A cross-site scripting (XSS) vulnerability in the HTML Data Processor in CKEditor A cross-site scripting (XSS) vulnerability in the HTML Data Processor in CKEditor 4 4.14.0 through 4.16.x before 4.16.1 allows remote attackers to inject executable JavaScript code through a crafted comment because –!> is mishandled. PRODUCT AFFECTED: This issue affects OTRS: from 7.0.X through 7.0.48, from 8.0.X through 8.0.37, from 2023.X through 2023.1.1; OTRSAdvancedEditor: from 6.0.X through 6.0.30, from 7.0.X through 7.0.32, from 8.0.X through 8.0.15, from 2023.X through 2023.1.1. ((OTRS)) Community Edition: from 6.0.1 through 6.0.34 --------------------------- A cross-site scripting (XSS) vulnerability in the HTML Data Processor in CKEditor 4 4.14.0 through 4.16.x before 4.16.1 allows remote attackers to inject executable JavaScript code through a crafted comment because --!> is mishandled. References: https://otrs.com/release-notes/otrs-security-advisory-2024-04/ http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-33829 https://www.cve.org/CVERecord?id=CVE-2021-33829 https://ckeditor.com/blog/ckeditor-4.16.1-with-accessibility-enhancements/#… https://bugzilla.redhat.com/show_bug.cgi?id=1974728 https://lists.fedoraproject.org/archives/list/package-announce@lists.fedora… https://www.drupal.org/sa-core-2021-003 https://lists.debian.org/debian-lts-announce/2021/11/msg00007.html https://lists.fedoraproject.org/archives/list/package-announce@lists.fedora… https://lists.fedoraproject.org/archives/list/package-announce@lists.fedora… -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1219358] New: AUDIT-0: pam: new module: pam_canonicalize_user to canonicalize user name
by bugzilla_noreply＠suse.com 07 Feb '24

07 Feb '24

https://bugzilla.suse.com/show_bug.cgi?id=1219358 Bug ID: 1219358 Summary: AUDIT-0: pam: new module: pam_canonicalize_user to canonicalize user name Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: security-team(a)suse.de Reporter: kukuk(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Linux-PAM comes with a new trivial PAM module (~15 lines of code), which needs to be whitelisted. PR for the module: https://github.com/linux-pam/linux-pam/pull/617 -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1215548] New: new coreutils-systemd breaks "uptime"
by bugzilla_noreply＠suse.com 07 Feb '24

07 Feb '24

https://bugzilla.suse.com/show_bug.cgi?id=1215548 Bug ID: 1215548 Summary: new coreutils-systemd breaks "uptime" Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: aarch64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: seife(a)novell.slipkontur.de QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- The new coreutils-systemd's "uptime" command reports wrong values: wrong, newer system: raspi4c:~ # grep VERSION_ID /etc/os-release VERSION_ID="20230910" raspi4c:~ # rpm -qf `which uptime` coreutils-systemd-9.4-1.1.aarch64 raspi4c:~ # uptime 06:28:33 up 4 days 21:40, 1 user, load average: 0.16, 0.16, 0.11 raspi4c:~ # cat /proc/uptime 136079.24 225710.69 correct, older system: raspi4a:~ # grep VERSION_ID /etc/os-release VERSION_ID="20230904" raspi4a:~ # rpm -qf `which uptime` coreutils-9.3-1.2.aarch64 raspi4a:~ # uptime 06:28:51 up 1 day 13:48, 1 user, load average: 0.09, 0.16, 0.12 raspi4a:~ # cat /proc/uptime 136093.86 92370.61 These are raspberry pi4's which don't have a realtime clock, so the system clock is wrong on boot. The broken version does not consult the kernel: raspi4c:~ # strace -e file uptime execve("/usr/bin/uptime", ["uptime"], 0xffffe61bb560 /* 48 vars */) = 0 faccessat(AT_FDCWD, "/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=26215, ...}, AT_EMPTY_PATH) = 0 openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 newfstatat(3, "", {st_mode=S_IFREG|0755, st_size=2515928, ...}, AT_EMPTY_PATH) = 0 openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=2940, ...}, AT_EMPTY_PATH) = 0 openat(AT_FDCWD, "/usr/lib/locale/de_DE.utf8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = 3 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=357744, ...}, AT_EMPTY_PATH) = 0 openat(AT_FDCWD, "/usr/lib64/gconv/gconv-modules.cache", O_RDONLY|O_CLOEXEC) = 3 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=27012, ...}, AT_EMPTY_PATH) = 0 faccessat(AT_FDCWD, "/var/run/utmpx", F_OK) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/var/run/utmp", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/etc/localtime", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) newfstatat(1, "", {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x1), ...}, AT_EMPTY_PATH) = 0 06:30:05 up 4 days 21:41, 1 user, load average: 0.20, 0.18, 0.11 +++ exited with 0 +++ The working version does: raspi4a:~ # strace -e file uptime execve("/usr/bin/uptime", ["uptime"], 0xffffe5952d00 /* 48 vars */) = 0 faccessat(AT_FDCWD, "/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=23327, ...}, AT_EMPTY_PATH) = 0 openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 newfstatat(3, "", {st_mode=S_IFREG|0755, st_size=2515928, ...}, AT_EMPTY_PATH) = 0 openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=2940, ...}, AT_EMPTY_PATH) = 0 openat(AT_FDCWD, "/usr/lib/locale/de_DE.utf8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = 3 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=357744, ...}, AT_EMPTY_PATH) = 0 openat(AT_FDCWD, "/usr/lib64/gconv/gconv-modules.cache", O_RDONLY|O_CLOEXEC) = 3 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=27012, ...}, AT_EMPTY_PATH) = 0 faccessat(AT_FDCWD, "/var/run/utmpx", F_OK) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/var/run/utmp", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/proc/uptime", O_RDONLY) = 3 newfstatat(3, "", {st_mode=S_IFREG|0444, st_size=0, ...}, AT_EMPTY_PATH) = 0 openat(AT_FDCWD, "/etc/localtime", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) newfstatat(1, "", {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x2), ...}, AT_EMPTY_PATH) = 0 06:30:40 up 1 day 13:49, 1 user, load average: 0.10, 0.15, 0.12 +++ exited with 0 +++ -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1218231] New: Hw virtualization enabled in BIOS of Intel Skylake i5-6200U, but lscpu says "VMX" disabled
by bugzilla_noreply＠suse.com 06 Feb '24

06 Feb '24

https://bugzilla.suse.com/show_bug.cgi?id=1218231 Bug ID: 1218231 Summary: Hw virtualization enabled in BIOS of Intel Skylake i5-6200U, but lscpu says "VMX" disabled Classification: openSUSE Product: openSUSE Distribution Version: Leap 16.0 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: el(a)horse64.org QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- I boot with these kernel options for CPU security: "mitigations=auto,nosmt mds=full,nosmt", on a laptop with Skylake i5-6200U. However, in the BIOS/UEFI options I enabled all virtualization features of this CPU. This means VT-x/VMX should be available, since Skylake supports this according to product pages. The kernel's iTLB multihit mitigation documentation does NOT suggest that any mitigation option will ever disable VT-x/VMX fully. Therefore, I would strongly expect it to be enabled on this system with this configuration. Now here comes the problem: $ lscpu | grep VMX Vulnerability Itlb multihit: KVM: Mitigation: VMX disabled Vulnerability L1tf: Mitigation; PTE Inversion; VMX conditional cache flushes, SMT disabled $ cat /sys/devices/system/cpu/vulnerabilities/itlb_multihit KVM: Mitigation: VMX disabled Something seems to be wrong here. As a semi naive uninformed user, I am guessing the following possible options for what happened: Option A: VMX is actually disabled by the kernel through some mitigation option. In this case this is a documentation issue, since the kernel help explaining this "KVM: Mitigation: VMX disabled" text ( https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/multihit.html ) is written like no mitigation would actively disable it, suggesting "VMX disabled" is only meant to show when the BIOS/UEFI turned it off. So the help page should then say what may mess with VMX on a kernel level beyond BIOS/UEFI. Option B: VMX is actually enabled, and the iTLB mitigation is set to "Split huge pages" (this would as far as I can tell be the "correct" option for this system). In this case, there seems to be some mostly benign iTLB info output bug. Option C: VMS is actually enabled, and the iTLB mitigation is NOT active and the device is vulnerable. This potential outcome is why I marked this as SECURITY ISSUE until it can be ruled out, since if that is true then lscpu clearly tells me I'm safe while I'm actually not. So this outcome could trick admins into making expensive hardening missteps. Option D: Maybe I'm just not smart enough to use my BIOS/UEFI, lol, or I misunderstand VMX/VT-x fundamentally. I'm not a kernel developer, after all. Vaguely related, this server fault post suggests this may also happen on many distributions: https://serverfault.com/questions/1073247/if-kvm-is-working-why-does-vmx-sh… (Not entirely sure though if it's the same cause) First seen with Fedora's 5.13.15-200.fc34.x86_64, still present with OpenSUSE slowroll's 6.5.9-1-default. Steps to reproduce: 1. Boot an Intel Skylake computer with Fedora installed. Ensure all virtualization features are enabled in the UEFI/BIOS options. 2. Once Linux has booted, change /etc/default/grub to add in "mitigations=auto,nosmt mds=full,nosmt" and update your generated grub2 files, and reboot. 3. Once inside Linux again, check "lscpu" output and /sys/devices/system/cpu/vulnerabilities/itlb_multihit output. Expected output would be something else than "VMX disabled". -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1219376] New: texlive-latex: LaTeX extremely slow for many small files (fixed in upstream latex2e)
by bugzilla_noreply＠suse.com 06 Feb '24

06 Feb '24

https://bugzilla.suse.com/show_bug.cgi?id=1219376 Bug ID: 1219376 Summary: texlive-latex: LaTeX extremely slow for many small files (fixed in upstream latex2e) Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: burnus(a)gmx.de QA Contact: qa-bugs(a)suse.de CC: werner(a)suse.com Target Milestone: --- Found By: --- Blocker: --- LaTeX is extremely slow if many small files are processed – the problem seems to be that it keeps searching up files without caching them. I think the fix is the following (merged): https://github.com/latex3/latex2e/pull/1063 Please consider applying. For the news file, included in the commit: ---------------------------------------------- \section{Code improvements} \subsection{Performance in checking file existence} The additon of hooks, etc., to file operations had a side-effect in that multiple checks were made that the file existed. In larger documents using lots of files, these filesystem operations caused non-trivial performance impact. We now cache the existence of files, such that these repeated filesystem calls are avoided. ---------------------------------------------- -- You are receiving this mail because: You are on the CC list for the bug.

1 9

[Bug 1219335] New: [AppArmor] AVC denials for zgrep
by bugzilla_noreply＠suse.com 06 Feb '24

06 Feb '24

https://bugzilla.suse.com/show_bug.cgi?id=1219335 Bug ID: 1219335 Summary: [AppArmor] AVC denials for zgrep Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: AppArmor Assignee: suse-beta(a)cboltz.de Reporter: antonio.feijoo(a)suse.com QA Contact: qa-bugs(a)suse.de CC: ddiss(a)suse.com Target Milestone: --- Found By: --- Blocker: --- Default Tumbleweed installation with AppArmor and kernel 6.8-rc1 from https://build.opensuse.org/package/show/Kernel:HEAD/kernel-default, getting AVC denials using `zgrep`. It does not happen with kernel 6.6.9-1-default. > localhost:/home/dev # uname -r > 6.8.0-rc1-4.gc619505-default > localhost:/home/dev # dracut -f --stdlog 3 test.img > /usr/bin/zgrep: line 210: /usr/bin/grep: Permission denied > /usr/bin/zgrep: line 280: /usr/bin/gzip: Permission denied > /usr/bin/zgrep: line 295: /usr/bin/grep: Permission denied > /usr/bin/zgrep: line 210: /usr/bin/grep: Permission denied > /usr/bin/zgrep: line 280: /usr/bin/gzip: Permission denied > /usr/bin/zgrep: line 295: /usr/bin/grep: Permission denied > localhost:/home/dev # zgrep CONFIG_BTRFS /proc/config.gz > /bin/zgrep: line 210: /usr/bin/grep: Permission denied > /bin/zgrep: line 280: /bin/gzip: Permission denied > /bin/zgrep: line 295: /usr/bin/grep: Permission denied > localhost:/home/dev # grep zgrep /var/log/audit/audit.log > ... > type=AVC msg=audit(1706603114.661:248): apparmor="DENIED" operation="open" class="file" profile="zgrep" name="/usr/bin/grep" pid=7356 comm="zgrep" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 > type=AVC msg=audit(1706603114.661:249): apparmor="DENIED" operation="open" class="file" profile="zgrep" name="/usr/bin/grep" pid=7356 comm="zgrep" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 > type=AVC msg=audit(1706603114.664:250): apparmor="DENIED" operation="open" class="file" profile="zgrep" name="/usr/bin/gzip" pid=7360 comm="zgrep" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 > type=AVC msg=audit(1706603114.664:251): apparmor="DENIED" operation="open" class="file" profile="zgrep" name="/usr/bin/gzip" pid=7360 comm="zgrep" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 > type=AVC msg=audit(1706603114.664:252): apparmor="DENIED" operation="open" class="file" profile="zgrep" name="/usr/bin/grep" pid=7361 comm="zgrep" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 > type=AVC msg=audit(1706603114.664:253): apparmor="DENIED" operation="open" class="file" profile="zgrep" name="/usr/bin/grep" pid=7361 comm="zgrep" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 > type=AVC msg=audit(1706603114.674:254): apparmor="DENIED" operation="open" class="file" profile="zgrep" name="/usr/bin/grep" pid=7368 comm="zgrep" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 > type=AVC msg=audit(1706603114.674:255): apparmor="DENIED" operation="open" class="file" profile="zgrep" name="/usr/bin/grep" pid=7368 comm="zgrep" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 > type=AVC msg=audit(1706603114.678:256): apparmor="DENIED" operation="open" class="file" profile="zgrep" name="/usr/bin/gzip" pid=7372 comm="zgrep" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 > type=AVC msg=audit(1706603114.678:257): apparmor="DENIED" operation="open" class="file" profile="zgrep" name="/usr/bin/gzip" pid=7372 comm="zgrep" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 > type=AVC msg=audit(1706603114.678:258): apparmor="DENIED" operation="open" class="file" profile="zgrep" name="/usr/bin/grep" pid=7373 comm="zgrep" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 > type=AVC msg=audit(1706603114.678:259): apparmor="DENIED" operation="open" class="file" profile="zgrep" name="/usr/bin/grep" pid=7373 comm="zgrep" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 > type=AVC msg=audit(1706603135.285:260): apparmor="DENIED" operation="open" class="file" profile="zgrep" name="/usr/bin/grep" pid=10315 comm="zgrep" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 > type=AVC msg=audit(1706603135.285:261): apparmor="DENIED" operation="open" class="file" profile="zgrep" name="/usr/bin/grep" pid=10315 comm="zgrep" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 > type=AVC msg=audit(1706603135.291:262): apparmor="DENIED" operation="capable" class="cap" profile="zgrep" pid=10317 comm="zgrep" capability=2 capname="dac_read_search" > type=AVC msg=audit(1706603135.291:263): apparmor="DENIED" operation="capable" class="cap" profile="zgrep" pid=10317 comm="zgrep" capability=1 capname="dac_override" > type=AVC msg=audit(1706603135.291:264): apparmor="DENIED" operation="open" class="file" profile="zgrep" name="/usr/bin/gzip" pid=10319 comm="zgrep" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 > type=AVC msg=audit(1706603135.291:265): apparmor="DENIED" operation="open" class="file" profile="zgrep" name="/usr/bin/gzip" pid=10319 comm="zgrep" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 > type=AVC msg=audit(1706603135.291:266): apparmor="DENIED" operation="open" class="file" profile="zgrep" name="/usr/bin/grep" pid=10320 comm="zgrep" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 > type=AVC msg=audit(1706603135.291:267): apparmor="DENIED" operation="open" class="file" profile="zgrep" name="/usr/bin/grep" pid=10320 comm="zgrep" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1217520] New: qemu: add support for canokeys
by bugzilla_noreply＠suse.com 06 Feb '24

06 Feb '24

https://bugzilla.suse.com/show_bug.cgi?id=1217520 Bug ID: 1217520 Summary: qemu: add support for canokeys Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Virtualization:Tools Assignee: kvm-bugs(a)suse.de Reporter: lnussel(a)suse.com QA Contact: qa-bugs(a)suse.de CC: fvogt(a)suse.com Target Milestone: --- Found By: --- Blocker: --- Looks like there's software FIDO2 support in qemu: https://www.qemu.org/docs/master/system/devices/canokey.html It needs https://github.com/canokeys/canokey-qemu. Could we have that in Factory please? As we are adding FIDO2 integration with disk encryption this would help both developing as well as later testing in openQA. -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1215361] New: "uptime" is dumping core
by bugzilla_noreply＠suse.com 06 Feb '24

06 Feb '24

https://bugzilla.suse.com/show_bug.cgi?id=1215361 Bug ID: 1215361 Summary: "uptime" is dumping core Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: nwr10cst-oslnx(a)yahoo.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0 Build Identifier: I just updated to 20230913. This was an update from 20230910. From before the update: twleap:support 1% uname -a Linux twleap 6.4.12-1-default #1 SMP PREEMPT_DYNAMIC Fri Aug 25 08:26:31 UTC 2023 (f5aa89b) x86_64 x86_64 x86_64 GNU/Linux twleap:support 2% uptime 16:23:44 up 0:01, 5 users, load average: 0.67, 0.43, 0.17 twleap:support 3% exit Script done on 2023-09-14 16:23:46-05:00 [COMMAND_EXIT_CODE="0"] From after the update (and a reboot): wleap:rickert 1% uname -a Linux twleap 6.5.2-1-default #1 SMP PREEMPT_DYNAMIC Fri Sep 8 07:32:27 UTC 2023 (fdde566) x86_64 x86_64 x86_64 GNU/Linux twleap:rickert 2% uptime Segmentation fault (core dumped) twleap:rickert 3% exit Script done on 2023-09-14 16:44:50-05:00 [COMMAND_EXIT_CODE="139"] This was in a KVM virtual machine. However, I had already seen the problem on another system (a bare metal install), which is why I knew to get the output before the update on the VM. Apologies if this is a duplicate. The search in bugzilla did not give me anything, and is possibly broken. Reproducible: Always -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 1216812] New: package request_ nyxt on armv7l
by bugzilla_noreply＠suse.com 05 Feb '24

05 Feb '24

https://bugzilla.suse.com/show_bug.cgi?id=1216812 Bug ID: 1216812 Summary: package request_ nyxt on armv7l Classification: openSUSE Product: openSUSE.org Version: unspecified Hardware: armv7 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: 3rd party software Assignee: screening-team-bugs(a)suse.de Reporter: jindam.vani(a)disroot.org QA Contact: screening-team-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- * right now nyxt is available for x86_64 on openSUSE:Factory [ 1 ] * however, there is derived package for aarch64 only [ 2 ] * if possible, please enable for armv7l [ 1 ] https://build.opensuse.org/package/show/openSUSE:Factory/nyxt [ 2 ] https://build.opensuse.org/package/show/network/nyxt -- You are receiving this mail because: You are on the CC list for the bug.

1 1