- openSUSE Kernel

Future of reiserfs in Tumbleweed (and beyond)
by Jeff Mahoney 05 Aug '22

05 Aug '22

Hi folks - When we introduced reiserfs in SUSE products over 20 years ago, it was a cutting edge file system that brought the protection of journaling to Linux for the first time. In 2006, I proposed moving away from it in openSUSE as the default file system, citing a small and shrinking developer community. These days, while I am technically the maintainer of the reiserfs userspace project upstream. Practically, it's abandoned and I haven't touched it in over 5 years. The kernel implementation gets attention only when updating a common subsystem requires it. It has none of the resiliency features that we've come to expect from modern file systems, and that includes the ability to craft file system images that could result in system crash or possibly compromise. It's time to let reiserfs go from openSUSE entirely. So, I propose: - Removing the reiserfs package from Tumbleweed immediately (and fixing any fallout caused by removing libreiserfscore), - Disable the kernel implementation immediately. I recognize that there may be people out there with disks containing reiserfs file systems. If these are in active use, I would seriously encourage migrating to something actively maintained. If these are sitting on a shelf for archival purposes, GRUB ships with a fuse frontend for all of its file system drivers, including reiserfs. It's not fast but it's enough for data access. -Jeff -- Jeff Mahoney Director, SUSE Labs Data & Performance

2 2

Re: Future of reiserfs in Tumbleweed (and beyond)
by Jeff Mahoney 05 Aug '22

05 Aug '22

On 8/5/22 13:27, Neal Gompa wrote: > On Fri, Aug 5, 2022 at 1:00 PM Jeff Mahoney <jeffm(a)suse.com> wrote: >> >> If these are >> sitting on a shelf for archival purposes, GRUB ships with a fuse >> frontend for all of its file system drivers, including reiserfs. It's >> not fast but it's enough for data access. >> > > Wait, what? It does? Yep. # grub2-mount <dev> /mnt -Jeff -- Jeff Mahoney Director, SUSE Labs Data & Performance

1 0

[kernel][TW] zypper dup to 20220714 + rpm -i kernel-default-5.18.9-2 x86_64 removed all other kernels
by Felix Miata 19 Jul '22

19 Jul '22

Is $SUBJECT what was supposed to happen? Prior TW version was 20220630. Newest kernel installed prior to 5.18.9-2 was 5.17.9-1. June/July portion of /var/log/zypp/history: https://paste.opensuse.org/74203728 -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata

5 11

Does kernel-5.18.9 boot for anyone?
by Manfred Hollstein 05 Jul '22

05 Jul '22

Hi there, I usually install each new stable kernel from Kernel:stable (on Tumbleweed) or from Kernel:stable:Backport (on Leap). It very rarely happens that problems arise, but starting with version 5.18.9 all my systems hang after the initrd has been loaded. This happens both on Tumbleweed and Leap 15.4. Before I create a bug report I wanted to check if this particular kernel works for anyone, or if others see such hangs, too. TIA, cheers. l8er manfred

4 5

drbd maintenance
by Hans-Peter Jansen 27 Jun '22

27 Jun '22

Hi Guys, looks like Nick Wang (drbd maintainer) isn't active anymore. Do we have a plan, how to maintain the drbd stuff, specifically the kernel module. Before I wrote this, I looked into it of course, but failed (wouldn't write this mail otherwise..). This coccinelle stuff scares me to death. Needless to say, drbd-kmod doesn't build anymore since the release of kernel 5.18. Best, Pete -- Life without chameleons is possible, but pointless.

5 10

[PATCH] config: Enable MLX90614
by Matwey V. Kornilov 24 Jun '22

24 Jun '22

MLX90614 is I2C (SMBus) remote temperature sensor. The boards are available for SBCs: https://www.waveshare.com/product/modules/sensors/temperature-humidity-baro… Enable the driver for potential users. Signed-off-by: Matwey V. Kornilov <matwey.kornilov(a)gmail.com> --- config/arm64/default | 2 +- config/armv7hl/default | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/config/arm64/default b/config/arm64/default index 9c28c2ac8ed..cf280b4e8a1 100644 --- a/config/arm64/default +++ b/config/arm64/default @@ -10820,7 +10820,7 @@ CONFIG_IQS620AT_TEMP=m CONFIG_LTC2983=m CONFIG_MAXIM_THERMOCOUPLE=m CONFIG_HID_SENSOR_TEMP=m -# CONFIG_MLX90614 is not set +CONFIG_MLX90614=m CONFIG_MLX90632=m # CONFIG_TMP006 is not set CONFIG_TMP007=m diff --git a/config/armv7hl/default b/config/armv7hl/default index a9607accd0e..823da06962a 100644 --- a/config/armv7hl/default +++ b/config/armv7hl/default @@ -10660,7 +10660,7 @@ CONFIG_IQS620AT_TEMP=m CONFIG_LTC2983=m CONFIG_MAXIM_THERMOCOUPLE=m CONFIG_HID_SENSOR_TEMP=m -# CONFIG_MLX90614 is not set +CONFIG_MLX90614=m CONFIG_MLX90632=m CONFIG_TMP006=m CONFIG_TMP007=m -- 2.35.3

5 7

(Leap 15.4) KMP key auto enrollment?
by Andrei Borzenkov 10 Jun '22

10 Jun '22

KMP signature key is provided as /etc/uefi/certs/BDD31A9E-kmp.crt, but apparently nothing enrolls this key automatically. It is missing after update to Leap 15.4: bor@10:~> mokutil --list-enrolled | grep 'SHA1 Finger' SHA1 Fingerprint: bc:a4:e3:8e:d1:84:2b:c8:6f:f7:6d:4d:a7:49:51:f1:62:88:59:f8 SHA1 Fingerprint: 4a:aa:0b:54:67:76:1e:cf:c0:0a:42:32:b1:7a:b4:8b:3e:09:a3:bf bor@10:~> And there is no enrollment request after installation of KMP: bor@10:~> sudo zypper in bbswitch-kmp-default ... bor@10:~> mokutil --list-new bor@10:~> Looking at kernel-scriptlets, certificate is handled by inkpm-script, but (at least, this KMP) calls kmp-script. Is it a bug, missing feature or what? KMP was built for 15.4: bor@10:~> zypper se -s bbswitch-kmp-default Loading repository data... Reading installed packages... S | Name | Type | Version | Arch | Repository ---+----------------------+---------+------------------------------------+--------+---------------- i+ | bbswitch-kmp-default | package | 0.8_k5.14.21_150400.22-lp154.1.187 | x86_64 | Main Repository bor@10:~>

2 2

[kernel] RT
by Felix Miata 24 May '22

24 May '22

# zypper info kernel-rt Retrieving repository... ...[done] Loading repository data... Reading installed packages... Information for package kernel-rt: ---------------------------------- Repository : OSS Name : kernel-rt Version : 5.3.18-8.13.1 Arch : x86_64 Vendor : SUSE LLC <https://www.suse.com/> Installed Size : 279.3 MiB Installed : No Status : not installed Source package : kernel-rt-5.3.18-8.13.1.nosrc Upstream URL : http://www.kernel.org/ Summary : The Linux Kernel Description : The Linux Kernel. Source Timestamp: 2021-06-01 16:17:05 +0000 GIT Revision: ebc4f0cb715d533804b3e9d66899a0470ba951f2 GIT Branch: SLE15-SP2-RT # How does a mere mortal user find out if this package provides a real-time kernel? -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata

1 0

VirtualBox fails under kernel 5.18
by Larry Finger 23 May '22

23 May '22

VirtualBox fails to run correctly under kernel 5.18.0. I noticed a problem in the 5.18-rcX cycle and bisected the problem to commit 6e8ec2552c7d ("random: use computational hash for entropy extraction"). That commit has been confirmed as the one causing the problem. We now know the cause. The changes in the random number generator employ the SSSE3 instructions. which in turn affects the FPU. The current belief is that the VirtualBox vcpu is not saving the state of the FPU when a hard IRQ occurs. If any code using SSSE3 runs in the host during that interrupt, the state of the FPU in the guest is incorrect, and the guest gets a kernel exception. Thus far, the only kernel code using that instruction set is the random number generator. It is easy to test for this condition. In the guest start a multi-cpu build of the kernel, or some other large project. Within a few seconds, gcc will get an error. The attached patch will cause rng not to use SSSE3 instructions, thereby bypassing the problem. Generation of random numbers may be a bit slower, but have no loss of robustness. If possible, I would like the patch applied to 5.18.X kernels until Oracle fixes the problem. Finding the fault is beyond my understanding of the implementation of virtual CPUs. Larry Finger - openSUSE VirtualBox Maintainer

1 0

[kernel] TW amdgpu firmware regression?
by Felix Miata 19 May '22

19 May '22

As of kernel-firmware-amdgpu-20220411 (first bad), and sometime after kernel-firmware-amdgpu-20211123 (last available good to revert to), and after TW20220311 (last working), using TW20220517 on: AMD Oland [Radeon HD 8570 / R5 430 OEM R7 240/340 Radeon 520 OEM] vendor: Dell driver: amdgpu v: kernel active: DP-1,DVI-I-1 bus-ID: 01:00.0 chip-ID: 1002:6611 aka Southern Islands GCN 1st gen microarchitecture Display and keyboard lockup around the time KMS should init. Other than reverting the firmware, or the crippling nomodeset option, the only workaround I have found is installing kernel-firmware-radeon, which this PC/GPU combination has never before needed. With kernel-firmware-radeon installed, X nevertheless runs using the amdgpu kernel module and the amdgpu DDX or the modesetting DIX. Before I report a bug, I would like to know if anyone here on the kernel mailing list knows if perchance GCN1 support has been purposely removed somehow from kernel-firmware-amdgpu, thus negating any point for a bug report. dmesg using 20211123 kernel-firmware-amdgpu: https://susepaste.org/6218560 dmesg using 20220411 kernel-firmware-amdgpu: https://susepaste.org/2000260 -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata

1 0