Bug 1182224 - kernel-default-devel/kernel-syms from kernel:stable will not install
kernel-default-devel/kernel-syms from kernel:stable will not install
Status: CONFIRMED
: 1182338 (view as bug list)
Classification: openSUSE
Product: openSUSE Distribution
Classification: openSUSE
Component: Kernel
Leap 15.2
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: openSUSE Kernel Bugs
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2021-02-13 20:15 UTC by Stephan Hemeier
Modified: 2021-05-17 14:20 UTC (History)
9 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stephan Hemeier 2021-02-13 20:15:41 UTC
Kernel-syms and kernel-default-devel will not install on openSUSE Leap 15.2:

LANG=C zypper in -f kernel-syms
Loading repository data...
Reading installed packages...
Forcing installation of 'kernel-syms-5.10.16-1.1.g11381f3.x86_64' from repository 'kernel-stable'.
Resolving package dependencies...

Problem: nothing provides libc.so.6(GLIBC_2.33)(64bit) needed by kernel-default-devel-5.10.16-1.1.g11381f3.x86_64
 Solution 1: do not install kernel-syms-5.10.16-1.1.g11381f3.x86_64
 Solution 2: break kernel-default-devel-5.10.16-1.1.g11381f3.x86_64 by ignoring some of its dependencies

Choose from above solutions by number or cancel [1/2/c/d/?] (c): c

Same with kernel-default-devel, but kernel-devel will install.
Comment 2 Jiri Slaby 2021-02-15 08:19:29 UTC
Right, the kernel now requires the latest glibc from factory (which didn't even hit tumbleweed): 
$ rpm -q --requires kernel-default-devel-5.10.16-1.1.g11381f3.x86_64.rpm|grep GLIBC_2.33
libc.so.6(GLIBC_2.33)(64bit)

Not sure how we can fix this...
Comment 3 Michal Suchanek 2021-02-15 08:28:18 UTC
This sounds like the new glibc added a feature that is used by all binaries (eg new memcpy helper) so all binaries linked with it require the new version.
Comment 4 Takashi Iwai 2021-02-15 08:32:44 UTC
Indeed it's a tricky problem.  We may overlay some packages from Leap or SLE, but then it looses the meaning as a devel project for TW.

Maybe we need to set up two repositories for this project, one for TW and one for Leap?  It would consume double resources, but better than breaking the installation on Leap, IMO.  The remaining problem is the gcc version, and we need to forcibly use gcc10 Leap repo setup.
Comment 5 Nikolai Nikolaevskii 2021-02-16 17:47:17 UTC
(In reply to Michal Suchanek from comment #3)
> This sounds like the new glibc added a feature that is used by all binaries
> (eg new memcpy helper) so all binaries linked with it require the new
> version.

GNU C Library 2.33 Released With HWCAPS To Load Optimized Libraries For Modern CPUs
https://www.phoronix.com/scan.php?page=news_item&px=GNU-C-Library-2.33
Comment 6 Nikolai Nikolaevskii 2021-02-16 18:00:46 UTC
(In reply to Takashi Iwai from comment #4)
> Indeed it's a tricky problem.  We may overlay some packages from Leap or
> SLE, but then it looses the meaning as a devel project for TW.
> 
> Maybe we need to set up two repositories for this project, one for TW and
> one for Leap?  It would consume double resources, but better than breaking
> the installation on Leap, IMO.  The remaining problem is the gcc version,
> and we need to forcibly use gcc10 Leap repo setup.

Possible solution:

1. Preserve the last working kernel for Leap 15.2 from kernel:stable in a dedicated repository.
2. Update Leap 15.3 glibc from 2.31 to 2.33 or newer.

I filed a request about Leap 15.2 + glibc 2.33: https://bugzilla.opensuse.org/show_bug.cgi?id=1182338
Comment 7 Takashi Iwai 2021-03-04 15:48:41 UTC
*** Bug 1182338 has been marked as a duplicate of this bug. ***
Comment 8 Bernhard Wiedemann 2021-03-05 04:13:05 UTC
The -devel package depends on glibc-2.33 because it contains these ELF binaries compiled with it:
tools/objtool/objtool
tools/objtool/fixdep
tools/bpf/resolve_btfids/fixdep
tools/bpf/resolve_btfids/feature/test-libelf.bin
tools/bpf/resolve_btfids/feature/test-zlib.bin
tools/bpf/resolve_btfids/feature/test-bpf.bin
tools/bpf/resolve_btfids/resolve_btfids
scripts/selinux/mdp/mdp
scripts/selinux/genheaders/genheaders
scripts/sign-file
scripts/basic/fixdep
scripts/recordmcount
scripts/extract-cert
scripts/genksyms/genksyms
scripts/kallsyms
scripts/bin2c
scripts/sorttable
scripts/kconfig/conf
scripts/mod/modpost
scripts/mod/mk_elfconfig
scripts/mod/ksym-provides
scripts/asn1_compiler

If any those is needed to build a kmp, one nice option would be to 
add a build target for Leap with
osc meta -e prj Kernel:stable
  <repository name="openSUSE_Leap" rebuild="local" block="local">
    <path project="openSUSE:Leap:15.3" repository="standard"/>
    <arch>x86_64</arch>
    <arch>i586</arch>
    <arch>aarch64</arch>
    <arch>ppc64le</arch>
    <arch>s390x</arch>
  </repository>


a less clean option would be
osc linkpac openSUSE:Leap:15.2/glibc Kernel:stable
Comment 9 Takashi Iwai 2021-03-05 08:32:32 UTC
(In reply to Bernhard Wiedemann from comment #8)
> If any those is needed to build a kmp, one nice option would be to 
> add a build target for Leap with
> osc meta -e prj Kernel:stable
>   <repository name="openSUSE_Leap" rebuild="local" block="local">
>     <path project="openSUSE:Leap:15.3" repository="standard"/>
>     <arch>x86_64</arch>
>     <arch>i586</arch>
>     <arch>aarch64</arch>
>     <arch>ppc64le</arch>
>     <arch>s390x</arch>
>   </repository>

This alone won't work because it also changes the gcc version.

> a less clean option would be
> osc linkpac openSUSE:Leap:15.2/glibc Kernel:stable

This works, but then we'll lose the purpose as a TW devel project here.

And, the project setup is done by a script in the kernel package, hence we'd have to adjust it if we need to create multiple repos (standard and openSUSE_Leap_15.x) in the same project, I'm afraid.

Another alternative would be to set up yet another Kernel:* project with links.  Then it can set up manually and no need to adjust the common scripts.
Comment 10 Michal Suchanek 2021-03-05 11:19:16 UTC
Uploaded the stable kernel with
--- rpm/config.sh
+++ rpm/config.sh
@@ -10,12 +10,7 @@ BUILD_DTBS="Yes"
 # Use new style livepatch package names
 LIVEPATCH=livepatch
 # buildservice projects to build the kernel against
-OBS_PROJECT=openSUSE:Factory
-OBS_PROJECT_ARM=openSUSE:Factory:ARM
-OBS_PROJECT_PPC=openSUSE:Factory:PowerPC
-OBS_PROJECT_RISCV=openSUSE:Factory:RISCV
-IBS_PROJECT=SUSE:Factory:Head
-IBS_PROJECT_ARM=Devel:ARM:Factory
+OBS_PROJECT=openSUSE:Leap:15.2:Update
 # Bugzilla info
 BUGZILLA_SERVER="apibugzilla.suse.com"
 BUGZILLA_PRODUCT="openSUSE Tumbleweed"

to Kernel:Backport:stable and Kernel:Backport:HEAD and then replaced kernel-source with a link to the Kernel:stable and Kernel:HEAD repo.

Requires minimal manual intervention.
Comment 11 Bernhard Wiedemann 2021-03-05 23:43:07 UTC
https://build.opensuse.org/package/live_build_log/Kernel:Backport:stable/kernel-default/standard/x86_64
failed build because of

Changes after running `make oldconfig':
+# CONFIG_CC_HAS_WORKING_NOSANITIZE_ADDRESS is not set
-CONFIG_CC_HAS_WORKING_NOSANITIZE_ADDRESS=y

Probably because compilation runs with Leap's gcc-7
Comment 12 Jiri Slaby 2021-03-08 05:17:59 UTC
(In reply to Bernhard Wiedemann from comment #11)
> Changes after running `make oldconfig':
> +# CONFIG_CC_HAS_WORKING_NOSANITIZE_ADDRESS is not set
> -CONFIG_CC_HAS_WORKING_NOSANITIZE_ADDRESS=y
> 
> Probably because compilation runs with Leap's gcc-7

Then we are blocked by bug 1181862 here too.
Comment 13 Michal Kubeček 2021-03-09 00:26:22 UTC
An idea (based on how I worked around the issue on my systems): we could split
the binaries (fixdep, objtool and modpost are those I already ran into) into
a separate subpackage for which we could then build a replacement for older
distributions quickly and easily. For these, there would be no difference if
they are built with gcc7 or any other. (We wouldn't even have to care about
version and repository priorities too much as the original package built on
Tumbleweed would be uninstallable.)
Comment 14 Michal Suchanek 2021-03-09 15:23:07 UTC
With the gcc meta-package from Factory the kernel builds:

https://build.opensuse.org/project/monitor/Kernel:stable:Backport
https://build.opensuse.org/project/monitor/Kernel:HEAD:Backport
Comment 15 Jimmie Mayfield 2021-05-17 14:20:51 UTC
Hi.  Sorry to revive an old bug but it looks like these backport Kernel builds are broken:

https://build.opensuse.org/project/monitor/Kernel:stable:Backport shows that Dwarves >= 1.21 is now needed.