# Rocky Linux 10.1 Kernel SRC RPM spec sed Statements "Breaking" Custom Builds **URL:** \ **Category:** Rocky Linux Help & Support\ **Tags:** rocky-linux-10\ **Created:** [November 29, 2025, 3:13am UTC](https://forums.rockylinux.org/t/rocky-linux-10-1-kernel-src-rpm-spec-sed-statements-breaking-custom-builds/19971 "2025-11-29T03:13:43Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![bnerickson](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/bnerickson/32/4861_2.png) [@bnerickson](https://forums.rockylinux.org/u/bnerickson)\ **Post date:** [November 29, 2025, 3:13am UTC](https://forums.rockylinux.org/t/rocky-linux-10-1-kernel-src-rpm-spec-sed-statements-breaking-custom-builds/19971/1 "2025-11-29T03:13:43Z")
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: ```auto # 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: ```auto # 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 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. ---
**Author:** ![label](https://avatars.discourse-cdn.com/v4/letter/l/c5a1d2/32.png) [@label](https://forums.rockylinux.org/u/label)\ **Post date:** [November 29, 2025, 6:01am UTC](https://forums.rockylinux.org/t/rocky-linux-10-1-kernel-src-rpm-spec-sed-statements-breaking-custom-builds/19971/2 "2025-11-29T06:01:11Z")
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](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. ---
**Author:** ![felfert](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/felfert/32/2259_2.png) [@felfert](https://forums.rockylinux.org/u/felfert)\ **Post date:** [November 29, 2025, 11:28am UTC](https://forums.rockylinux.org/t/rocky-linux-10-1-kernel-src-rpm-spec-sed-statements-breaking-custom-builds/19971/3 "2025-11-29T11:28:08Z")
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)](https://man7.org/linux/man-pages/man8/rpmbuild.8.html) Cheers -Fritz ---
**Author:** ![felfert](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/felfert/32/2259_2.png) [@felfert](https://forums.rockylinux.org/u/felfert)\ **Post date:** [November 29, 2025, 11:55am UTC](https://forums.rockylinux.org/t/rocky-linux-10-1-kernel-src-rpm-spec-sed-statements-breaking-custom-builds/19971/4 "2025-11-29T11:55:03Z")
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/ to ~/rpmbuild/BUILD/.orig` 3. Run `rpmbuild -bp --nodeps whatever.spec` again. 4. Make changes in `~/rpmbuild/BUILD/` 5. `cd ~/rpmbuild/BUILD/` 6. `diff -urwN .orig > ../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) ---
**Author:** ![bnerickson](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/bnerickson/32/4861_2.png) [@bnerickson](https://forums.rockylinux.org/u/bnerickson)\ **Post date:** [November 29, 2025, 6:13pm UTC](https://forums.rockylinux.org/t/rocky-linux-10-1-kernel-src-rpm-spec-sed-statements-breaking-custom-builds/19971/5 "2025-11-29T18:13:55Z")
> [@felfert](#): > > –short-circuit -bc This doesn’t work, unfortunately: ```auto 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`: ```auto + 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 😀 ---
**Author:** ![bnerickson](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/bnerickson/32/4861_2.png) [@bnerickson](https://forums.rockylinux.org/u/bnerickson)\ **Post date:** [November 29, 2025, 6:28pm UTC](https://forums.rockylinux.org/t/rocky-linux-10-1-kernel-src-rpm-spec-sed-statements-breaking-custom-builds/19971/6 "2025-11-29T18:28:58Z")
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: ```auto 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. ---
**Author:** ![label](https://avatars.discourse-cdn.com/v4/letter/l/c5a1d2/32.png) [@label](https://forums.rockylinux.org/u/label)\ **Post date:** [November 29, 2025, 7:36pm UTC](https://forums.rockylinux.org/t/rocky-linux-10-1-kernel-src-rpm-spec-sed-statements-breaking-custom-builds/19971/7 "2025-11-29T19:36:47Z")
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](https://kojidev.rockylinux.org/koji/buildinfo?buildID=98178) 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](https://kojidev.rockylinux.org/koji/taskinfo?taskID=543653) 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. ---
**Author:** ![bnerickson](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/bnerickson/32/4861_2.png) [@bnerickson](https://forums.rockylinux.org/u/bnerickson)\ **Post date:** [November 29, 2025, 7:40pm UTC](https://forums.rockylinux.org/t/rocky-linux-10-1-kernel-src-rpm-spec-sed-statements-breaking-custom-builds/19971/8 "2025-11-29T19:40:08Z")
Thanks! I’ll look into adding mock into my custom build process and see if I can come up with something cleaner then. ---
**Author:** ![bnerickson](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/bnerickson/32/4861_2.png) [@bnerickson](https://forums.rockylinux.org/u/bnerickson)\ **Post date:** [December 5, 2025, 6:20pm UTC](https://forums.rockylinux.org/t/rocky-linux-10-1-kernel-src-rpm-spec-sed-statements-breaking-custom-builds/19971/9 "2025-12-05T18:20:41Z")
Looks like someone heard me and fixed this in the latest kernel spec file (6.12.0-124.13.1). The custom rocky definitions are now in the uki templates without the sed statements 🙂 ---
**Author:** ![system](https://us1.discourse-cdn.com/flex020/uploads/rockylinux/original/1X/91b7219eec10e30013422e4df76c1d898711a5d5.svg) [@system](https://forums.rockylinux.org/u/system)\ **Post date:** [February 3, 2026, 6:21pm UTC](https://forums.rockylinux.org/t/rocky-linux-10-1-kernel-src-rpm-spec-sed-statements-breaking-custom-builds/19971/10 "2026-02-03T18:21:31Z")
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.