Rocky Linux 10.1 Kernel SRC RPM spec sed Statements "Breaking" Custom Builds

Rocky Linux Help & Support
1

I currently build a custom Rocky Linux 10 kernel rpm using rpmbuild. It’s broken up into three main steps:

  1. I run rmbuild -bp to run %prep
  2. Apply some kernel patches to kernel.spec.
  3. I run rpmbuild --with baseonly --without debug --without debuginfo --without kabichk -bb to build the kernel rpms.

I try to keep the modifications to kernel.spec to a minimum, but a recent addition in 10.1 (6.12.0-124.8.1.el10.x86_64) is messing with my process. In particular these five lines:

# SBAT data
%if 0%{?rocky}
sed -i '2a kernel-uki-virt.rocky,1,RESF,kernel-uki-virt,@KVER,mailto:security@rockylinux.org' %{SOURCE83}
sed -i '2a kernel-uki-virt-addons.rocky,1,RESF,kernel-uki-virt-addons,@KVER,mailto:security@rockylinux.org' %{SOURCE84}
%endif

The problem is that this is updating both source templates (SOURCE83==uki.sbat.template and SOURCE84==uki-addons.sbat.template) twice, once in step 1 and a second time in step 3. This then causes ukify to bomb out when building the rpms:

# ukify build --linux /root/rpmbuild/BUILD/kernel-6.12.0-124.8.1.el10_1/linux-6.12.0-124.8.1.ath_hack.el10.x86_64/arch/x86/boot/bzImage --initrd /root/rpmbuild/BUILDROOT/kernel-6.12.0-124.8.1.ath_hack.el10.x86_64/lib/modules/6.12.0-124.8.1.ath_hack.el10.x86_64/vmlinuz-virt.img --sbat @sbat --os-release @/etc/os-release --uname 6.12.0-124.8.1.ath_hack.el10.x86_64 --cmdline 'console=tty0 console=ttyS0' --output /root/rpmbuild/BUILDROOT/kernel-6.12.0-124.8.1.ath_hack.el10.x86_64/lib/modules/6.12.0-124.8.1.ath_hack.el10.x86_64/vmlinuz-virt.efi
Traceback (most recent call last):
  File "/bin/ukify", line 2198, in <module>
    main()
  File "/bin/ukify", line 2187, in main
    make_uki(opts)
  File "/bin/ukify", line 1274, in make_uki
    pe_add_sections(uki, unsigned_output)
  File "/bin/ukify", line 953, in pe_add_sections
    raise PEError(f'Not enough space in existing section {section.name} to append new data.')

Now this is a relatively easy fix (I can remove the sed statements after step 1, but it strikes me as going against the spirit of a deterministic %prep% section. Shouldn’t those lines already exist in the template files without needing to be added or alternatively shouldn’t the spec file check to verify the lines don’t already exist in the templates before adding them? I’m not sure where to report this, maybe a github issue somewhere?

edit: Adding the --noprep argument to step 3 isn’t an option. Doing so causes the rpmbuild to fail entirely.

2

Without additional details on your changes or what you’re doing, it’s hard to know what’s actually going on. Whether or not that we are using sed or we’re modifying upstream’s sbat source files directly, the result is the same: ukify passes and works for us.

You can report what you believe is a bug to https://bugs.rockylinux.org, but please note:

  • Our builds succeed - Otherwise we would not have released 10.1 earlier this week
  • You are making modifications to the stock kernel we build which treads into unsupported territory
  • We will require additional details as to your modifications

The third point above is critical. Without this information, on the surface, the issue will be within your modifications or your build environment.

1 Like
3

Is the stuff that runs twice is located in the %prep section of the spec, you should be able to skip %prep during your second rpmbuild invocation by using --short-circuit -bc See rpmbuild(8)

Cheers
-Fritz

4

And like Louis already mentioned: You are doing it wrong.

When I want to modify/customize an “upstream” rpm, I usually do the following steps:

  1. Run rpmbuild -bp --nodeps whatever.spec
  2. rename ~/rpmbuild/BUILD/<ThePackagesBuilddir> to ~/rpmbuild/BUILD/<ThePackagesBuilddir>.orig
  3. Run rpmbuild -bp --nodeps whatever.spec again.
  4. Make changes in ~/rpmbuild/BUILD/<ThePackagesBuilddir>
  5. cd ~/rpmbuild/BUILD/
  6. diff -urwN <ThePackagesBuilddir>.orig <ThePackagesBuilddir> > ../SOURCES/some-unique-name.patch
  7. Copy and Edit the spec file and add that patch to the spec file
  8. Run rpmbuild -bs modified.spec
  9. Run mock --rebuild the-new-src.rpm (from step 8)
5

This doesn’t work, unfortunately:

error: File not found: /root/rpmbuild/BUILDROOT/kernel-6.12.0-124.8.1.ath_hack.el10.x86_64/usr/include/*
warning: File not found: /root/rpmbuild/BUILDROOT/kernel-6.12.0-124.8.1.ath_hack.el10.x86_64/usr/include/cpufreq.h
warning: File not found: /root/rpmbuild/BUILDROOT/kernel-6.12.0-124.8.1.ath_hack.el10.x86_64/usr/include/ynl
    File not found: /root/rpmbuild/BUILDROOT/kernel-6.12.0-124.8.1.ath_hack.el10.x86_64/usr/include/cpufreq.h
    File not found: /root/rpmbuild/BUILDROOT/kernel-6.12.0-124.8.1.ath_hack.el10.x86_64/usr/include/ynl
    File not found: /root/rpmbuild/BUILDROOT/kernel-6.12.0-124.8.1.ath_hack.el10.x86_64/usr/include/*

I get a different error when trying to use --noprep:

+ mkdir -p /root/rpmbuild/BUILDROOT/kernel-6.12.0-124.8.1.ath_hack.el10.x86_64/boot
+ mkdir -p /root/rpmbuild/BUILDROOT/kernel-6.12.0-124.8.1.ath_hack.el10.x86_64/usr/libexec
+ cd linux-6.12.0-124.8.1.ath_hack.el10.x86_64
/var/tmp/rpm-tmp.vum7qS: line 918: cd: linux-6.12.0-124.8.1.ath_hack.el10.x86_64: No such file or directory
error: Bad exit status from /var/tmp/rpm-tmp.vum7qS (%build)
    Bad exit status from /var/tmp/rpm-tmp.vum7qS (%build)

I appreciate the support, but I do want to point out that it works just fine once I’ve removed the sed statements after step 1 (running up-to the %prep section); so don’t spend too much time trying to find a workaround on my account :grinning_face:

6

If this is the preferred approach I can see why this would work as the %prep section for the modified rpm would only be executed only once for the original (step 1) and only once for the modified (step 3) environments. Regarding @label’s comment, it’s no shocker that builds are successful if rpmbuild is only being called once for the package build.

I am definitely no rpmspec expert, but my assumption is that running rpmbuild -bp over-and-over would result in the exact same build environment being created/prepped regardless of whether it exists on-disk or not–as a best practice. The sed statements break that assumption: each time I run rpmbuild -bp the following line is added to the uki.sbat.template file regardless of whether it already exists in the file or not:

kernel-uki-virt.rocky,1,RESF,kernel-uki-virt,@KVER,mailto:security@rockylinux.org

So before I file a bug, is my assumption incorrect? If so, then no worries and I’ll close the topic.

7

Re-reading everything, I realize that you’re not using mock and it makes sense that running -bp would eventually create this issue you’re seeing. Part of the reason why our builds are consistent and work with how they operate is we use mock to build (and I believe most packagers in the Fedora and EL arena use mock, so they don’t see something like this crop up). As @felfert mentioned, he shows using mock to build a package for himself. This eliminates having to do manual work over and over (and it also ensures you are building your packages in a clean room, so to speak).

Our build system relies on mock all the way through the process: for building the source RPM (from git + sources) and then sending that source package to builders. You could look at this build as an example and see the logs of what takes place. rpmbuild is only ran a couple of times, but very specific invocations of it (check the build.log on any arch for an example). Same goes for the source rpm logs too. So yes, you are correct, it’s only being called a couple of times, just with very specific invocations.

I don’t think this will be a problem with your modifications, rather it will be a problem in the methodology in which the package is being built. My team (among many others) will recommend the use of mock for building packages.

1 Like
8

Thanks! I’ll look into adding mock into my custom build process and see if I can come up with something cleaner then.