kernel-obs-build failure

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

On Apr 19 2021, Hans-Peter Jansen wrote:
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)
kernel-obs-build needs to be built as root. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."

Am Montag, 19. April 2021, 21:57:31 CEST schrieb Andreas Schwab:
On Apr 19 2021, Hans-Peter Jansen wrote:
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) kernel-obs-build needs to be built as root.
Thanks. I thought so too. Let me rephrase my question, how are such root builds managed in OBS? I cannot find anything the project config, nor some magic comments in the spec. Cheers, Pete

On Apr 19 2021, Hans-Peter Jansen wrote:
I cannot find anything the project config, nor some magic comments in the spec.
$ grep needs kernel-obs-build.spec # needsrootforbuild Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."

Am Montag, 19. April 2021, 23:37:42 CEST schrieb Andreas Schwab:
On Apr 19 2021, Hans-Peter Jansen wrote:
I cannot find anything the project config, nor some magic comments in the spec.
$ grep needs kernel-obs-build.spec # needsrootforbuild
Well apart from, what you already provided, the solution for building such packages in a local OBS was adding something similar to: our $norootexceptions = { "Kernel.*/kernel-obs-build" => 1 }; to /usr/lib/obs/server/BSConfig.pm and restarting obsservice. I understand that this is quite a sensitive setting, so it is better to think carefully about what you are doing here. Thanks, Pete
participants (2)
-
Andreas Schwab
-
Hans-Peter Jansen