March 2024 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1220541] kexec does a full reboot with kernel 6.7.6-1.1
by bugzilla_noreply＠suse.com 01 Mar '24

01 Mar '24

https://bugzilla.suse.com/show_bug.cgi?id=1220541 https://bugzilla.suse.com/show_bug.cgi?id=1220541#c4 --- Comment #4 from Takashi Iwai <tiwai(a)suse.com> --- OK, thanks. Since this is a regression in the upstream kernel, at best you can report it to the upstream. https://docs.kernel.org/admin-guide/reporting-regressions.html https://docs.kernel.org/process/handling-regressions.html Care to report your problem? They'll likely ask you to perform git bisection. A hint for building your test kernel quickly is found at https://docs.kernel.org/admin-guide/quickly-build-trimmed-linux.html -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1220290] Powersave governor puts CPU near max mhz
by bugzilla_noreply＠suse.com 01 Mar '24

01 Mar '24

https://bugzilla.suse.com/show_bug.cgi?id=1220290 https://bugzilla.suse.com/show_bug.cgi?id=1220290#c19 --- Comment #19 from Rory A <rory.ashton(a)gmail.com> --- > I did a full install of openSUSE Tumbleweed and the CPU is scaling very > well I dont want to get too off topic but what specifically works well is if I switch to the 'conservative' gov. It scales up and down very well in Tumbleweed. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1220727] New: VUL-0: CVE-2023-51774: rubygem-json-jwt: JWE can sometimes be used to bypass JSON:JWT.decode
by bugzilla_noreply＠suse.com 01 Mar '24

01 Mar '24

https://bugzilla.suse.com/show_bug.cgi?id=1220727 Bug ID: 1220727 Summary: VUL-0: CVE-2023-51774: rubygem-json-jwt: JWE can sometimes be used to bypass JSON:JWT.decode Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.6 Hardware: Other URL: https://smash.suse.de/issue/395627/ OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: security-team(a)suse.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: --- The json-jwt (aka JSON::JWT) gem 1.16.3 for Ruby sometimes allows bypass of identity checks via a sign/encryption confusion attack. For example, JWE can sometimes be used to bypass JSON::JWT.decode. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-51774 https://www.cve.org/CVERecord?id=CVE-2023-51774 https://github.com/P3ngu1nW/CVE_Request/blob/main/novjson-jwt.md -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1220290] Powersave governor puts CPU near max mhz
by bugzilla_noreply＠suse.com 01 Mar '24

01 Mar '24

https://bugzilla.suse.com/show_bug.cgi?id=1220290 https://bugzilla.suse.com/show_bug.cgi?id=1220290#c18 --- Comment #18 from Rory A <rory.ashton(a)gmail.com> --- Hi Giovanni, I did a full install of openSUSE Tumbleweed and the CPU is scaling very well, but I am happy to keep testing on this issue off the Live USB. Just wanted to note this is working well. Sorry for so many comments! Kind regards Kernel : 6.7.6-1-default #1 SMP PREEMPT_DYNAMIC -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1218241] OBS: package update-bootloader-rpm-macros not updated?
by bugzilla_noreply＠suse.com 01 Mar '24

01 Mar '24

https://bugzilla.suse.com/show_bug.cgi?id=1218241 https://bugzilla.suse.com/show_bug.cgi?id=1218241#c9 Michael Chang <mchang(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|dimstar(a)opensuse.org |mchang(a)suse.com --- Comment #9 from Michael Chang <mchang(a)suse.com> --- Set assignee back to myself before we can find proper resolution. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1218241] OBS: package update-bootloader-rpm-macros not updated?
by bugzilla_noreply＠suse.com 01 Mar '24

01 Mar '24

https://bugzilla.suse.com/show_bug.cgi?id=1218241 https://bugzilla.suse.com/show_bug.cgi?id=1218241#c8 Michael Chang <mchang(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(yast2-maintainers | |(a)suse.de), | |needinfo?(comes(a)naic.edu) CC| |comes(a)naic.edu, | |yast2-maintainers(a)suse.de --- Comment #8 from Michael Chang <mchang(a)suse.com> --- (In reply to Giacomo Comes from comment #6) > (In reply to Fabian Vogt from comment #5) > > This is caused by the openSUSE:Factory prjconf: > > > > # from update-bootloader-rpm-macros - impacts build deps > > %update_bootloader_requires %nil > > This probably was added when %update_bootloader_requires > was defined as: Requires(posttrans): perl-Bootloader > causing problems. Very much likely, but with this change that _prjconf redefinition seemed to be unnecessary. https://build.opensuse.org/package/rdiff/Base:System/update-bootloader-rpm-… > > Actually I'm not sure how useful is %update_bootloader_requires any more. It was used/useful in the past, but the attempt to getting rid of perl-Bootloader dependency making it useless by design. > There are only few packages the uses it and almost all use this construct: > %if 0%{?update_bootloader_requires:1} > %update_bootloader_requires > %else > <some other value> > %endif I didn't answer for other packages, but indeed grub has this construct: > %if 0%{?update_bootloader_requires:1} > %update_bootloader_requires > %else > Requires: perl-Bootloader > Requires(post): perl-Bootloader > %endif The %else was added back then to bailout old SLE release without update-bootloader-rpm-macros, you can notice similar %if .. %else ... in the %post section that update-bootloader has invoked directly without taking these macros. I think those fallback %else can be removed given all SLE distribution has update-bootloader-rpm-macros. By doing so, it also makes the attempt to getting rid of perl-Bootloader dependency from grub packages really to work as expect. > And since in openSUSE:Factory's prjconf the macro gets undefined, > it means that no packages is really using the macro right now. I'll try to make a new update-bootloader-rpm-macros submission to silence those `mkdir' and `touch' failure to align with the plan of not adding up dependencies. It is fine doing so given perl-Bootloader must not being used by the system given it has dependency to coreutils as well. Is that work for you ? Also we need to check with YaST how they handle the dependency during the installation so the potential breakage if grub stops requiring perl-Bootloader can be addressed. We probably don't want this movement to surprise them. Thanks. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1218241] OBS: package update-bootloader-rpm-macros not updated?
by bugzilla_noreply＠suse.com 01 Mar '24

01 Mar '24

https://bugzilla.suse.com/show_bug.cgi?id=1218241 https://bugzilla.suse.com/show_bug.cgi?id=1218241#c7 Michael Chang <mchang(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mchang(a)suse.com --- Comment #7 from Michael Chang <mchang(a)suse.com> --- (In reply to Fabian Vogt from comment #5) > This is caused by the openSUSE:Factory prjconf: > > # from update-bootloader-rpm-macros - impacts build deps > %update_bootloader_requires %nil Thanks for your help and pointing this out. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1220290] Powersave governor puts CPU near max mhz
by bugzilla_noreply＠suse.com 01 Mar '24

01 Mar '24

https://bugzilla.suse.com/show_bug.cgi?id=1220290 https://bugzilla.suse.com/show_bug.cgi?id=1220290#c17 --- Comment #17 from Rory A <rory.ashton(a)gmail.com> --- (In reply to Rory A from comment #16) > As a side note I am able to make the system 'more usable' by booting into > the working powersave move then adjusting the min CPU MHz values thus > speeding up the CPU. > > echo 1200000 | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_min_freq > > Then when I'm done with whatever CPU intensive task I slow it back down. > > echo 800000 | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_min_freq Sidenote to others trying to make their system usable while trouble shooting this - booting with intel_pstate=disable gives driver acpi-cpufreq, and it does not respect any limits I manually set like this echo 1400000 | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq But if I boot with intel_pstate=passive I still get the driver intel_cpufreq which will respect these limits AND let me use 'powersave' to idle the cpu. Sorry if this is too offtopic for the bug report. Trying to help other people coming from Google. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1220290] Powersave governor puts CPU near max mhz
by bugzilla_noreply＠suse.com 01 Mar '24

01 Mar '24

https://bugzilla.suse.com/show_bug.cgi?id=1220290 https://bugzilla.suse.com/show_bug.cgi?id=1220290#c16 --- Comment #16 from Rory A <rory.ashton(a)gmail.com> --- As a side note I am able to make the system 'more usable' by booting into the working powersave move then adjusting the min CPU MHz values thus speeding up the CPU. echo 1200000 | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_min_freq Then when I'm done with whatever CPU intensive task I slow it back down. echo 800000 | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_min_freq Or I can change to the performance scaling_governor for a minute or two while I open firefox, or do an update, then change back to powersave. For other users here is a bash script that makes 'manually governing' the CPU a bit easier. But you'll want to adjust the min/max based on your CPU. And presently 'E' for edit runs leafpad. Replace that with whatever your editor is. I hope posting this script here is not outside the rules! Apologies if so. This script refreshes every 2 seconds. while : do clear sgov=$(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor) echo "scaling_governor : " $sgov echo -e "" cat /proc/cpuinfo | grep "MHz" echo -e "" sdriver=$(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver) echo "scaling_driver : " $sdriver echo -e "" echo -e "1) Powersave \n2) Conservative \n3) Schedutil \n4) Performance \n5) Ondemand \n\n6) Max 1.4 GHz \n7) Max 2.5 GHz \n\n9) Min 900 MHz \n0) Min 1.2 GHz \n\nD) Defaults \nE) Edit \nQ) Quit" echo "" sminf=$(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq) smaxf=$(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq) echo "scaling_min_freq : " $sminf echo "scaling_max_freq : " $smaxf read -rsn1 -t 1 input if [ "$input" = "1" ]; then echo powersave | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor fi if [ "$input" = "2" ]; then echo conservative | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor fi if [ "$input" = "3" ]; then echo schedutil | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor fi if [ "$input" = "4" ]; then echo performance | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor fi if [ "$input" = "5" ]; then echo ondemand | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor fi if [ "$input" = "6" ]; then echo 1400000 | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq fi if [ "$input" = "7" ]; then echo 2500000 | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq fi if [ "$input" = "9" ]; then echo 900000 | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_min_freq fi if [ "$input" = "0" ]; then echo 1200000 | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_min_freq fi if [ "$input" = "d" ]; then echo 800000 | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_min_freq echo 2700000 | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq fi if [ "$input" = "q" ]; then exit fi if [ "$input" = "e" ]; then leafpad mon.sh exit fi sleep 2 done -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1220290] Powersave governor puts CPU near max mhz
by bugzilla_noreply＠suse.com 01 Mar '24

01 Mar '24

https://bugzilla.suse.com/show_bug.cgi?id=1220290 https://bugzilla.suse.com/show_bug.cgi?id=1220290#c15 --- Comment #15 from Rory A <rory.ashton(a)gmail.com> --- > * The "powersave" you get with intel_pstate=passive (labeled #1 in the > diagram) always run at the minimum clock (like you say, doesn't scale with > load -- it always runs at the minimum clock). Thanks for the diagram and info - very appreciated. It's interesting that driver intel_cpufreq has 2 different 'powersave' modes, the normal one and the intel_pstate=passive one. When I use kernel option intel_pstate=passive I still seem to get the driver intel_cpufreq Commands : # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver intel_cpufreq # cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-5.14.21-150500.55.49-default root=UUID=9cd4eb94-ecc9-4e0e-bf60-e157df2ecb16 splash=silent resume=/dev/disk/by-uuid/bb0bb873-36e0-4cf5-ae7a-1c5fcc7d6514 preempt=full mitigations=auto intel_pstate=passive quiet security=apparmor Whereas if I boot with intel_pstate=disable I do end up with acpi-cpufreq https://bugzilla.suse.com/attachment.cgi?bugid=1220290&action=enter # cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-5.14.21-150500.55.49-default root=UUID=9cd4eb94-ecc9-4e0e-bf60-e157df2ecb16 splash=silent resume=/dev/disk/by-uuid/bb0bb873-36e0-4cf5-ae7a-1c5fcc7d6514 preempt=full mitigations=auto intel_pstate=disable quiet security=apparmor # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver acpi-cpufreq -- You are receiving this mail because: You are on the CC list for the bug.

1 0