- openSUSE Kernel

KMP builds fail with current factory kernels
by Hans-Peter Jansen 06 Jun '21

06 Jun '21

[Just FYI: https://bugzilla.suse.com/show_bug.cgi?id=1186900] Hi, some changes to the packaging infra not too long ago result in failed builds of certain kernel module packages, eg: https://build.opensuse.org/package/live_build_log/security:forensics/lime-k… Here's a typical failing sequence: [ 45s] + for flavor in default [ 45s] + cp -a src obj-default [ 45s] + pushd obj-default [ 45s] ~/rpmbuild/BUILD/lime-1.9+git.20200809T155235.fa37b69/obj-default ~/rpmbuild/BUILD/lime-1.9+git.20200809T155235.fa37b69 [ 45s] ++ make -si -C /usr/src/linux-obj/x86_64/default ARCH=x86 kernelrelease [ 46s] + kver=5.12.9-1-default [ 46s] + make -j4 KVER=5.12.9-1-default KDIR=/usr/src/linux-obj/x86_64/default modules [ 46s] make -C /lib/modules/5.12.9-1-default/build M="/home/abuild/rpmbuild/BUILD/lime-1.9+git.20200809T155235.fa37b69/obj-default" modules [ 46s] make[1]: *** /lib/modules/5.12.9-1-default/build: No such file or directory. Stop. The reason is some wrong (packaged) symlinks in the kernel-$flavor-devel package. After co/building the package, chroot into the build env_ abuild@xrated:~> cd /lib/modules/5.12.9-1-default/ abuild@host:/lib/modules/5.12.9-1-default> l total 0 drwxr-xr-x 2 root root 33 Jun 5 16:01 ./ drwxr-xr-x 3 root root 30 Jun 5 16:01 ../ lrwxrwxrwx 1 root root 50 Jun 3 23:57 build -> ../../../usr/src/linux-5.12.9-1-obj/x86_64/default lrwxrwxrwx 1 root root 31 Jun 3 23:57 source -> ../../../usr/src/linux-5.12.9-1 abuild@xrated:/lib/modules/5.12.9-1-default> abuild@xrated:/lib/modules/5.12.9-1-default> l ../../.. total 68 drwxr-xr-x 14 root root 169 Jun 5 16:01 ./ drwxr-xr-x 21 root root 4096 Jun 5 16:01 ../ drwxr-xr-x 3 root root 21 Jun 5 16:01 X11R6/ dr-xr-xr-x 2 root root 12288 Jun 5 16:01 bin/ drwxr-xr-x 8 root root 175 Jun 5 16:01 etc/ dr-xr-xr-x 34 root root 8192 Jun 5 16:01 include/ dr-xr-xr-x 24 root root 4096 Jun 5 16:01 lib/ dr-xr-xr-x 18 root root 16384 Jun 5 16:01 lib64/ drwxr-xr-x 9 root root 136 Jun 5 16:01 libexec/ drwxr-xr-x 11 root root 118 May 25 07:58 local/ dr-xr-xr-x 2 root root 4096 Jun 5 16:01 sbin/ dr-xr-xr-x 43 root root 4096 Jun 5 16:01 share/ drwxr-xr-x 6 root root 100 Jun 5 16:01 src/ drwxr-xr-x 5 root root 43 May 25 07:58 x86_64-suse-linux/ The build and source symlinks either miss another ../ or usr/ needs to go. Best regards, Pete

3 2

Leap 15.3 kernel 5.3.18-57 missing yenta module?
by David Mace 21 May '21

21 May '21

Hi, I have a vintage (2007) laptop, upgraded to openSUSE Leap 15.3. When using 15.3 kernel 5.3.18-57 there is no yenta module, so my PCMCIA cards are not working (a legacy Creative Soundblaster Audigy for example). If I boot into my Leap 15.2 kernel then it is working fine (with boot option "pci=cbmemsize=8M" workaround) Is openSUSE removing support for legacy PCMCIA? Cheers

6 12

HDMI connected monitors fail to sleep
by Malcolm 21 May '21

21 May '21

Hi All Is there a way to determine if/when this fix will appear in the kernel? Or is it possible for the patch to be added? https://gitlab.freedesktop.org/drm/amd/-/issues/662 I'm on the GNOME DE and have an AMD RX550, the only way for me at present is adding amdgpu.dc=0 and loose hdmi sound support :( -- Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890) Tumbleweed 20210517 | GNOME Shell 40.0 | 5.12.3-1-default HP Z440 | Xeon E5-2690 V3 X24 @ 2.60GHz | AMD RX550/Nvidia GT1030 up 18:11, 2 users, load average: 0.79, 0.40, 0.30

2 1

Fwd: Heads up: sunsetting mkinitrd
by Daniel Molkentin 18 May '21

18 May '21

Forwarding, per Takashi's suggestion. Let's keep the discussion here. -------- Forwarded Message -------- Subject: Re: Heads up: sunsetting mkinitrd Date: Tue, 18 May 2021 17:46:03 +0200 From: Takashi Iwai <tiwai(a)suse.de> To: Daniel Molkentin <dmolkentin(a)suse.de> CC: factory(a)lists.opensuse.org, packaging(a)lists.opensuse.org On Tue, 18 May 2021 17:21:20 +0200, Daniel Molkentin wrote: > > Hi, > > with the pending submission of Dracut 054, which removes mkinitrd from > the upstream sources, it's time to finally remove mkinitrd in Factory, > too: > > Changes starting with 054 > ------------------------- > > - mkinitrd will temporarily live in its own dracut-mkinitrd-deprecated > package. It will still be installed when requiring "mkinitrd" and > requires dracut, so nothing changes here. > - If you only required dracut, but meant to require mkinitrd, you need > to change this temporarily or change your scripts to directly call dracut. > > Rationale > --------- > > mkinitrd has always been a rather mediocre wrapper that claimed to keep > compatibility with the SLES 11 implementation. However: > > - it has a lot of bugs, quite some documented (!) flags have never > worked, others are marked unimplemented or will say so only if invoked. > I see little point in doing that given > - it adds little value over just using plain Dracut > > Differences in calling dracut over calling mkinitrd: > ---------------------------------------------------- > > - Dracut only updates the initrd for the currently running kernel, > unless either a kernel version or --regenerate-all is called > - mkinitrd updates the bootloader by default. Dracut has no such option. > Then again, those are two different concerns that are only merged into a > single command for convenience. Usually this should be invoked from the > kernel install script. > - mkinitrd parses the no longer existing /etc/sysconfig/kernel file. > - mkinitrd handles xen-specific modules. I have not enough understanding > of the state of Xen in Factory to judge whether this is still required. > If so, it should be handled in a dracut module. However, judging by the > fact that the default is sourced from the defunc'ed kernel sysconfig > file, this is probably also dead. > - mkinitrd has slightly different semantics on how to specify a boot > device for NFS & Co. > > > Point of Contact > ---------------- > > If you have concerns how this affects your package, please let us (me, > Thomas Blume or Neil) know. For the Kernel and other packages that are > definitely impacted once mkinitrd would go away (e.g. YaST), we will > reach out separately and / or file bugzilla issues. I believe that the more suitable place to post would have been kernel@opensuse... In anyway, two biggest breakages would be the kernel packages themselves and suse-module-tools package. There can be a few KMP packages that have dependency on mkinitrd, but they could be fixed since the dependency should be superfluous. For the kernel packages, at least two things, AFAIK: * kernel-* binary packages have dependency on mkinitrd * kernel-obs-build explicitly creates the initrd with mkinitrd. Both are relatively easy to fix, I suppose. However, the major pains would be rather for the scripts in suse-module-tools package. Better to ask Martin Wilck about that. thanks, Takashi

2 2

kernel-obs-build failure
by Hans-Peter Jansen 20 Apr '21

20 Apr '21

Hi, in a local obs, I face some kernel-obs-build related issues, but let's start from the beginning. virtualbox:kmp build with a current kernel on 15.2 fails with some strange issue: [ 609s] /home/abuild/rpmbuild/BUILD/VirtualBox-6.1.18/modules_build_dir/default/vboxvideo/vbox_drv.c:320:3: error: 'struct drm_driver' has no member named 'dev_priv_size' [ 609s] 320 | .dev_priv_size = 0, This is most probably due to: [ 6s] [1/10] preinstalling kernel-obs-build... [ 40s] [3/183] cumulate kernel-obs-build-5.3.18-lp152.69.1 [ 40s] [102/183] cumulate kernel-macros-5.11.15-lp152.8.1 [ 40s] [124/183] cumulate kernel-devel-5.11.15-lp152.8.1 [ 40s] [181/183] cumulate kernel-default-5.11.15-lp152.8.1 [ 40s] [182/183] cumulate kernel-default-devel-5.11.15-lp152.8.1 [ 40s] [183/183] cumulate kernel-syms-5.11.15-lp152.8.1 [ 46s] kernel-macros-5.11.15-lp152.8.1 ######################################## [ 51s] kernel-devel-5.11.15-lp152.8.1 ######################################## [ 85s] kernel-default-5.11.15-lp152.8.1 ######################################## [ 87s] kernel-default-devel-5.11.15-lp152.8.1######################################## [ 88s] kernel-syms-5.11.15-lp152.8.1 ######################################## [ 89s] kernel-obs-build-5.3.18-lp152.69.1 ######################################## [ 137s] kmk_builtin_append '/home/abuild/rpmbuild/BUILD/VirtualBox-6.1.18/out/linux.amd64/release/DynamicConfig.kmk' '# Host version: 5.3.18; full: 5.3.18.0' Despite of installing all the good stuff, VB thinks, it builds a 5.3.18.0 version. While other kernel modules don't suffer from this, I thought, it might be a good idea to build a current kernel-obs-build as well, but that fails horribly: [ 78s] Executing(%build): /bin/bash -e /var/tmp/rpm-tmp.NPaiTO [ 78s] + umask 022 [ 78s] + cd /home/abuild/rpmbuild/BUILD [ 78s] + /usr/bin/rm -rf /home/abuild/rpmbuild/BUILDROOT/kernel-obs-build-5.11.15-lp152.8.1.x86_64 [ 78s] ++ dirname /home/abuild/rpmbuild/BUILDROOT/kernel-obs-build-5.11.15-lp152.8.1.x86_64 [ 78s] + /usr/bin/mkdir -p /home/abuild/rpmbuild/BUILDROOT [ 78s] + /usr/bin/mkdir /home/abuild/rpmbuild/BUILDROOT/kernel-obs-build-5.11.15-lp152.8.1.x86_64 [ 79s] + mkdir -p /usr/lib/dracut/modules.d/80obs [ 79s] mkdir: cannot create directory '/usr/lib/dracut/modules.d/80obs': Permission denied [ 79s] error: Bad exit status from /var/tmp/rpm-tmp.NPaiTO (%build) So while the source of this issue is most probably some VB build issue, that appeared lately only, I ask, how kernel-obs-build is supposed to be build, given the whole build creates items outside of %buildroot: %build mkdir -p /usr/lib/dracut/modules.d/80obs cat > /usr/lib/dracut/modules.d/80obs/module-setup.sh <<EOF #!/bin/bash # called by dracut check() { return 0 } # called by dracut installkernel() { hostonly='' instmods obs } # called by dracut install() { inst_hook pre-udev 10 "\$moddir"/setup_obs.sh } EOF chmod a+rx /usr/lib/dracut/modules.d/80obs/module-setup.sh Could some kind soul enlight me, please? Pete

2 4

Data corruption in kernel 5.12-rc1
by Michal Kubecek 06 Mar '21

06 Mar '21

Hello, if you are testing 5.12-rc1 kernel, please be aware of a known regression. Due to a bug in swapfile code, writes to a swapfile may end up on wrong offset and corrupt data in the partition the swapfile resides on. Our master branch already has the fix, commit caf6912f3f4a ("swap: fix swapfile read/write offset"), and updated KotD packages with it are building in BuildService projects (version 5.12.rc1-3.1.gbdb065a). Michal

2 1

In-kernel MTE (heap) tagging - CONFIG_KASAN_HW_TAGS
by Guillaume Gardet 03 Mar '21

03 Mar '21

Hi, With kernel 5.11 we can enable MTE (heap) tagging, in-kernel support, with the following arm64 config update: ************************************************** @@ -11577,7 +11577,11 @@ CONFIG_CC_HAS_KASAN_GENERIC=y # CONFIG_CC_HAS_KASAN_SW_TAGS is not set CONFIG_CC_HAS_WORKING_NOSANITIZE_ADDRESS=y # CONFIG_KASAN is not set CONFIG_KASAN=y # CONFIG_KASAN_GENERIC is not set CONFIG_KASAN_HW_TAGS=y CONFIG_KASAN_STACK=1 # CONFIG_TEST_KASAN_MODULE is not set # end of Memory Debugging # CONFIG_DEBUG_SHIRQ is not set ************************************************** KASAN seems to be a good candidate for a debug kernel. But I noticed that KASAN is not enabled at all for kernels built in openSUSE Tumbleweed. Is it on purpose? I plan some testing of CONFIG_KASAN_HW_TAGS soon. Cheers, Guillaume

3 3

KMP for openSUSE Leap on OBS may need to include openSUSE key
by joeyli 24 Feb '21

24 Feb '21

Hi all, In a discussion with Max Lin, he has mentioned that the KMP on OBS (e.g. virtual box) can not be loaded by closing-gap kernel. That makes sense because the kernel binary is from SLE. For those KMP from SLE repo, the driver be signed by SLE key. It doesn't have problem to work with closing-gap kernel. But for those drivers from openSUSE Leap repo, they are signed by openSUSE key. The closing-gap kernel doesn't embed Leap kernel. Maybe the openSUSE Leap pubic key must be included in all KMPs in Leap repo? or at least all KMPs in Leap repo must depend on a openSUSE Leap sign key RPM. After KMP be installed and reboot, user can follow MOK manager's UI to enroll openSUSE Leap key. Any idea? Thanks a lot! Joey Lee

3 8

[PATCH] config: arm64: Use y for CLK_RK3399
by Matwey V. Kornilov 15 Feb '21

15 Feb '21

This is to fix booting on RK3399 systems (JeOS-rockpi4) When compiled as 'm' there are lots of errors related to clk and no host mmc controler initialized. Signed-off-by: Matwey V. Kornilov <matwey.kornilov(a)gmail.com> --- config/arm64/default | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/config/arm64/default b/config/arm64/default index 9c4181e1ad8..64c3c05e424 100644 --- a/config/arm64/default +++ b/config/arm64/default @@ -9281,7 +9281,7 @@ CONFIG_CLK_PX30=y CONFIG_CLK_RK3308=y CONFIG_CLK_RK3328=y CONFIG_CLK_RK3368=y -CONFIG_CLK_RK3399=m +CONFIG_CLK_RK3399=y CONFIG_COMMON_CLK_SAMSUNG=y CONFIG_EXYNOS_ARM64_COMMON_CLK=y CONFIG_EXYNOS_AUDSS_CLK_CON=m -- 2.26.2

5 4

Leap 15.2 kernel-default-5.3.18-lp152.60.1.x86_64 problem with AMD Turks graphics
by Andreas Vetter 21 Jan '21

21 Jan '21

Hi, the update from kernel-default-5.3.18-lp152.57.1.x86_64 to kernel-default-5.3.18-lp152.60.1.x86_64 results in dark screens after smooth tock-tock-sound when I would expect switch of resolution on my 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Turks PRO [Radeon HD 6570/7570/8550] The system is running fine, so I can ssh to it and reboot and start with the old kernel where everything is fine. Is this a known problem (I had this already in 2019 or 2020, where it was solved by the next kernel update before I was able to report)? If not, I'll open a bug report. What information is needed for debugging this problem? -- Mit freundlichen Gruessen, Andreas Vetter

2 2