Centos-kernel-stream-9/redhat/kernel.spec.template

3743 lines
134 KiB
Plaintext
Raw Normal View History

Fix LTO issues with kernel-tools There are two parts to this fix. One is using the recommended way to disable LTO. The other is to make it work for the kernel.spec file. Various kernel-tool programs (like perf) can not handle LTO yet, so they are disabled. This is done with '%define _lto_cflags {nil}'. However that doesn't quite work for the kernel for the %install section. It works for the %build section. Oddly, back at the birth of dist-git, the initial kernel.spec file was imported with a line at the top %global __spec_install_pre %{___build_pre} For whatever reason, the kernel was deemed special and that line pre-built the %install scripts _before_ the lto_cflags could dynamically be disabled. Moving the _lto_cflags line above the _pre line disables LTO for both the %build and %install sections of the spec file successfully. However, because that _pre line is unintiutive and caused hours of debugging headache, I hacked up the output to see what the %__spec_install_pre and ___build_pre looked like at the beginning of the %install section. The idea was __build_pre is what we want going forward. Unfortunately, after examining the results, I learned the %install section expects a clean RPM_BUILD_ROOT. But the kernel %build section puts each compiled variant into the RPM_BUILD_ROOT as it completes. Thus is gets removed on %install setup. So the %__spec_install_pre line has to stay. Instead I add a bunch of comments explaining why it is necessary and where to add changes like _lto_cflags. This hopefully reduces headaches in the future. V2: restore __spec_install_pre line and add comments. Cc: Jeff Law <law@redhat.com> Signed-off-by: Don Zickus <dzickus@redhat.com>
2020-10-28 03:06:59 +00:00
# All Global changes to build and install go here.
# Per the below section about __spec_install_pre, any rpm
# environment changes that affect %%install need to go
# here before the %%install macro is pre-built.
# Disable LTO in userspace packages.
%global _lto_cflags %{nil}
# Option to enable compiling with clang instead of gcc.
%bcond_with toolchain_clang
%if %{with toolchain_clang}
%global toolchain clang
%endif
Fix LTO issues with kernel-tools There are two parts to this fix. One is using the recommended way to disable LTO. The other is to make it work for the kernel.spec file. Various kernel-tool programs (like perf) can not handle LTO yet, so they are disabled. This is done with '%define _lto_cflags {nil}'. However that doesn't quite work for the kernel for the %install section. It works for the %build section. Oddly, back at the birth of dist-git, the initial kernel.spec file was imported with a line at the top %global __spec_install_pre %{___build_pre} For whatever reason, the kernel was deemed special and that line pre-built the %install scripts _before_ the lto_cflags could dynamically be disabled. Moving the _lto_cflags line above the _pre line disables LTO for both the %build and %install sections of the spec file successfully. However, because that _pre line is unintiutive and caused hours of debugging headache, I hacked up the output to see what the %__spec_install_pre and ___build_pre looked like at the beginning of the %install section. The idea was __build_pre is what we want going forward. Unfortunately, after examining the results, I learned the %install section expects a clean RPM_BUILD_ROOT. But the kernel %build section puts each compiled variant into the RPM_BUILD_ROOT as it completes. Thus is gets removed on %install setup. So the %__spec_install_pre line has to stay. Instead I add a bunch of comments explaining why it is necessary and where to add changes like _lto_cflags. This hopefully reduces headaches in the future. V2: restore __spec_install_pre line and add comments. Cc: Jeff Law <law@redhat.com> Signed-off-by: Don Zickus <dzickus@redhat.com>
2020-10-28 03:06:59 +00:00
# Compile the kernel with LTO (only supported when building with clang).
%bcond_with clang_lto
%if %{with clang_lto} && %{without toolchain_clang}
{error:clang_lto requires --with toolchain_clang}
%endif
2021-01-12 14:25:17 +00:00
# Cross compile on copr for arm
# See https://bugzilla.redhat.com/1879599
%if 0%{?_with_cross_arm:1}
%global _target_cpu armv7hl
%global _arch arm
%global _build_arch arm
%global _with_cross 1
%endif
Fix LTO issues with kernel-tools There are two parts to this fix. One is using the recommended way to disable LTO. The other is to make it work for the kernel.spec file. Various kernel-tool programs (like perf) can not handle LTO yet, so they are disabled. This is done with '%define _lto_cflags {nil}'. However that doesn't quite work for the kernel for the %install section. It works for the %build section. Oddly, back at the birth of dist-git, the initial kernel.spec file was imported with a line at the top %global __spec_install_pre %{___build_pre} For whatever reason, the kernel was deemed special and that line pre-built the %install scripts _before_ the lto_cflags could dynamically be disabled. Moving the _lto_cflags line above the _pre line disables LTO for both the %build and %install sections of the spec file successfully. However, because that _pre line is unintiutive and caused hours of debugging headache, I hacked up the output to see what the %__spec_install_pre and ___build_pre looked like at the beginning of the %install section. The idea was __build_pre is what we want going forward. Unfortunately, after examining the results, I learned the %install section expects a clean RPM_BUILD_ROOT. But the kernel %build section puts each compiled variant into the RPM_BUILD_ROOT as it completes. Thus is gets removed on %install setup. So the %__spec_install_pre line has to stay. Instead I add a bunch of comments explaining why it is necessary and where to add changes like _lto_cflags. This hopefully reduces headaches in the future. V2: restore __spec_install_pre line and add comments. Cc: Jeff Law <law@redhat.com> Signed-off-by: Don Zickus <dzickus@redhat.com>
2020-10-28 03:06:59 +00:00
# RPM macros strip everything in BUILDROOT, either with __strip
# or find-debuginfo.sh. Make use of __spec_install_post override
# and save/restore binaries we want to package as unstripped.
%define buildroot_unstripped %{_builddir}/root_unstripped
%define buildroot_save_unstripped() \
(cd %{buildroot}; cp -rav --parents -t %{buildroot_unstripped}/ %1 || true) \
%{nil}
%define __restore_unstripped_root_post \
echo "Restoring unstripped artefacts %{buildroot_unstripped} -> %{buildroot}" \
cp -rav %{buildroot_unstripped}/. %{buildroot}/ \
%{nil}
Fix LTO issues with kernel-tools There are two parts to this fix. One is using the recommended way to disable LTO. The other is to make it work for the kernel.spec file. Various kernel-tool programs (like perf) can not handle LTO yet, so they are disabled. This is done with '%define _lto_cflags {nil}'. However that doesn't quite work for the kernel for the %install section. It works for the %build section. Oddly, back at the birth of dist-git, the initial kernel.spec file was imported with a line at the top %global __spec_install_pre %{___build_pre} For whatever reason, the kernel was deemed special and that line pre-built the %install scripts _before_ the lto_cflags could dynamically be disabled. Moving the _lto_cflags line above the _pre line disables LTO for both the %build and %install sections of the spec file successfully. However, because that _pre line is unintiutive and caused hours of debugging headache, I hacked up the output to see what the %__spec_install_pre and ___build_pre looked like at the beginning of the %install section. The idea was __build_pre is what we want going forward. Unfortunately, after examining the results, I learned the %install section expects a clean RPM_BUILD_ROOT. But the kernel %build section puts each compiled variant into the RPM_BUILD_ROOT as it completes. Thus is gets removed on %install setup. So the %__spec_install_pre line has to stay. Instead I add a bunch of comments explaining why it is necessary and where to add changes like _lto_cflags. This hopefully reduces headaches in the future. V2: restore __spec_install_pre line and add comments. Cc: Jeff Law <law@redhat.com> Signed-off-by: Don Zickus <dzickus@redhat.com>
2020-10-28 03:06:59 +00:00
# The kernel's %%install section is special
# Normally the %%install section starts by cleaning up the BUILD_ROOT
# like so:
#
# %%__spec_install_pre %%{___build_pre}\
# [ "$RPM_BUILD_ROOT" != "/" ] && rm -rf "${RPM_BUILD_ROOT}"\
# mkdir -p `dirname "$RPM_BUILD_ROOT"`\
# mkdir "$RPM_BUILD_ROOT"\
# %%{nil}
#
# But because of kernel variants, the %%build section, specifically
# BuildKernel(), moves each variant to its final destination as the
# variant is built. This violates the expectation of the %%install
# section. As a result we snapshot the current env variables and
# purposely leave out the removal section. All global wide changes
# should be added above this line otherwise the %%install section
# will not see them.
%global __spec_install_pre %{___build_pre}
# Replace '-' with '_' where needed so that variants can use '-' in
# their name.
%define uname_suffix() %{lua:
local flavour = rpm.expand('%{?1:+%{1}}')
flavour = flavour:gsub('-', '_')
if flavour ~= '' then
print(flavour)
end
}
# This returns the main kernel tied to a debug variant. For example,
# kernel-debug is the debug version of kernel, so we return an empty
# string. However, kernel-64k-debug is the debug version of kernel-64k,
# in this case we need to return "64k", and so on. This is used in
# macros below where we need this for some uname based requires.
%define uname_variant() %{lua:
local flavour = rpm.expand('%{?1:%{1}}')
_, _, main, sub = flavour:find("(%w+)-(.*)")
if main then
print("+" .. main)
end
}
# At the time of this writing (2019-03), RHEL8 packages use w2.xzdio
# compression for rpms (xz, level 2).
# Kernel has several large (hundreds of mbytes) rpms, they take ~5 mins
# to compress by single-threaded xz. Switch to threaded compression,
# and from level 2 to 3 to keep compressed sizes close to "w2" results.
#
# NB: if default compression in /usr/lib/rpm/redhat/macros ever changes,
# this one might need tweaking (e.g. if default changes to w3.xzdio,
# change below to w4T.xzdio):
#
# This is disabled on i686 as it triggers oom errors
%ifnarch i686
%define _binary_payload w3T.xzdio
%endif
Summary: The Linux kernel
%if 0%{?fedora}
%define secure_boot_arch x86_64
%else
%define secure_boot_arch x86_64 aarch64 s390x ppc64le
%endif
# Signing for secure boot authentication
%ifarch %{secure_boot_arch}
%global signkernel 1
%else
%global signkernel 0
%endif
# Sign modules on all arches
%global signmodules 1
# Compress modules only for architectures that build modules
%ifarch noarch
%global zipmodules 0
%else
%global zipmodules 1
%endif
redhat: Add sub-RPM with a EFI unified kernel image for virtual machines Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2142102 Upstream Status: RHEL only The new 'kernel-unified-virt' sub-RPM is added on x86_64 targets. This contains an EFI application that provides a combined vmlinux, initrd and cmdline, as a so called 'unified kernel image'. The spec for this is defined by the boot loader specification https://uapi-group.org/specifications/specs/boot_loader_specification/ The key benefit of a unified kernel is that its secure boot signature covers the initrd and cmdline contents, allowing a trustworthy measured boot process with attestation, which is not practical with locally generated initrds/cmdlines. Since the initrd is pre-generated its contents have to be very generic, to be usable on a wide variety of deployments. To make this problem tractable, the sub-RPM targets only usage in virtual machines. With such a restriction, the initrd only needs a very small set of block driver modules present, in order to be usable across KVM, Hyper-V and Xen hypervisors which will cover essentially all common public and private clouds. Similarly the kernel cmdline cannot contain any host specific data, which means the root filesystem to mount needs to be able to be automatically detected. A virtual machine image intending to use this unified kernel package thus needs to comply with the discoverable partitions specification: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/ Based-on-patch-by: Daniel P. Berrangé <berrange@redhat.com> Based-on-patch-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
2022-11-07 09:21:43 +00:00
%ifarch x86_64
%global efiuki 1
%else
%global efiuki 0
%endif
# Default compression algorithm
%global compression xz
%global compression_flags --compress
%global compext xz
%if %{zipmodules}
%global zipsed -e 's/\.ko$/\.ko.%compext/'
# for parallel xz processes, replace with 1 to go back to single process
%endif
%if 0%{?fedora}
%define primary_target fedora
%else
%define primary_target rhel
%endif
#
# genspec.sh variables
#
# Include Fedora files
%global include_fedora %%SPECINCLUDE_FEDORA_FILES%%
# Include RHEL files
%global include_rhel %%SPECINCLUDE_RHEL_FILES%%
# Provide Patchlist.changelog file
%global patchlist_changelog %%SPECPATCHLIST_CHANGELOG%%
# Set debugbuildsenabled to 1 to build separate base and debug kernels
# (on supported architectures). The kernel-debug-* subpackages will
# contain the debug kernel.
# Set debugbuildsenabled to 0 to not build a separate debug kernel, but
# to build the base kernel using the debug configuration. (Specifying
# the --with-release option overrides this setting.)
%define debugbuildsenabled %%SPECDEBUG_BUILDS_ENABLED%%
%%SPECBUILDID%%
%define specversion %%SPECVERSION%%
%define patchversion %%SPECKVERSION%%.%%SPECKPATCHLEVEL%%
%define pkgrelease %%SPECBUILD%%
%define kversion %%SPECKVERSION%%
%define tarfile_release %%SPECTARFILE_RELEASE%%
# This is needed to do merge window version magic
%define patchlevel %%SPECKPATCHLEVEL%%
# This allows pkg_release to have configurable %%{?dist} tag
%define specrelease %%SPECRELEASE%%
# This defines the kabi tarball version
%define kabiversion %%SPECKABIVERSION%%
#
# End of genspec.sh variables
#
%define pkg_release %{specrelease}
# libexec dir is not used by the linker, so the shared object there
# should not be exported to RPM provides
%global __provides_exclude_from ^%{_libexecdir}/kselftests
# The following build options are enabled by default, but may become disabled
# by later architecture-specific checks. These can also be disabled by using
# --without <opt> in the rpmbuild command, or by forcing these values to 0.
#
# standard kernel
%define with_up %{?_without_up: 0} %{?!_without_up: 1}
# kernel PAE (only valid for ARM (lpae))
%define with_pae %{?_without_pae: 0} %{?!_without_pae: 1}
# kernel-debug
%define with_debug %{?_without_debug: 0} %{?!_without_debug: 1}
# kernel-zfcpdump (s390 specific kernel for zfcpdump)
%define with_zfcpdump %{?_without_zfcpdump: 0} %{?!_without_zfcpdump: 1}
# kernel-64k (aarch64 kernel with 64K page_size)
%define with_arm64_64k %{?_without_arm64_64k: 0} %{?!_without_arm64_64k: 1}
# kernel-rt (x86_64 and aarch64 only PREEMPT_RT enabled kernel)
%define with_realtime %{?_without_realtime: 0} %{?!_without_realtime: 1}
# kernel-rt-64k (aarch64 RT kernel with 64K page_size)
%define with_realtime_arm64_64k %{?_without_realtime_arm64_64k: 0} %{?!_without_realtime_arm64_64k: 1}
# kernel-doc
%define with_doc %{?_without_doc: 0} %{?!_without_doc: 1}
# kernel-headers
%define with_headers %{?_without_headers: 0} %{?!_without_headers: 1}
%define with_cross_headers %{?_without_cross_headers: 0} %{?!_without_cross_headers: 1}
# perf
%define with_perf %{?_without_perf: 0} %{?!_without_perf: 1}
# tools
%define with_tools %{?_without_tools: 0} %{?!_without_tools: 1}
# kernel-debuginfo
%define with_debuginfo %{?_without_debuginfo: 0} %{?!_without_debuginfo: 1}
# kernel-abi-stablelists
%define with_kernel_abi_stablelists %{?_without_kernel_abi_stablelists: 0} %{?!_without_kernel_abi_stablelists: 1}
# internal samples and selftests
%define with_selftests %{?_without_selftests: 0} %{?!_without_selftests: 1}
#
# Additional options for user-friendly one-off kernel building:
#
# Only build the base kernel (--with baseonly):
%define with_baseonly %{?_with_baseonly: 1} %{?!_with_baseonly: 0}
# Only build the pae kernel (--with paeonly):
%define with_paeonly %{?_with_paeonly: 1} %{?!_with_paeonly: 0}
# Only build the debug kernel (--with dbgonly):
%define with_dbgonly %{?_with_dbgonly: 1} %{?!_with_dbgonly: 0}
# Only build the realtime kernel (--with rtonly):
%define with_rtonly %{?_with_rtonly: 1} %{?!_with_rtonly: 0}
# Control whether we perform a compat. check against published ABI.
%define with_kabichk %{?_without_kabichk: 0} %{?!_without_kabichk: 1}
# Temporarily disable kabi checks until RC.
%define with_kabichk 0
# Control whether we perform a compat. check against DUP ABI.
%define with_kabidupchk %{?_with_kabidupchk: 1} %{?!_with_kabidupchk: 0}
#
# Control whether to run an extensive DWARF based kABI check.
# Note that this option needs to have baseline setup in SOURCE300.
%define with_kabidwchk %{?_without_kabidwchk: 0} %{?!_without_kabidwchk: 1}
%define with_kabidw_base %{?_with_kabidw_base: 1} %{?!_with_kabidw_base: 0}
#
# Control whether to install the vdso directories.
%define with_vdso_install %{?_without_vdso_install: 0} %{?!_without_vdso_install: 1}
#
# should we do C=1 builds with sparse
%define with_sparse %{?_with_sparse: 1} %{?!_with_sparse: 0}
#
# Cross compile requested?
%define with_cross %{?_with_cross: 1} %{?!_with_cross: 0}
#
# build a release kernel on rawhide
%define with_release %{?_with_release: 1} %{?!_with_release: 0}
# verbose build, i.e. no silent rules and V=1
%define with_verbose %{?_with_verbose: 1} %{?!_with_verbose: 0}
#
# check for mismatched config options
%define with_configchecks %{?_without_configchecks: 0} %{?!_without_configchecks: 1}
#
# gcov support
%define with_gcov %{?_with_gcov:1}%{?!_with_gcov:0}
#
# ipa_clone support
%define with_ipaclones %{?_without_ipaclones: 0} %{?!_without_ipaclones: 1}
# Want to build a vanilla kernel build without any non-upstream patches?
%define with_vanilla %{?_with_vanilla: 1} %{?!_with_vanilla: 0}
%if 0%{?fedora}
# Kernel headers are being split out into a separate package
%define with_headers 0
%define with_cross_headers 0
# no ipa_clone for now
%define with_ipaclones 0
# no stablelist
%define with_kernel_abi_stablelists 0
# Fedora builds these separately
%define with_perf 0
%define with_tools 0
%endif
%if %{with_verbose}
%define make_opts V=1
%else
%define make_opts -s
%endif
%if %{with toolchain_clang}
%ifarch s390x ppc64le
%global llvm_ias 0
%else
%global llvm_ias 1
%endif
%global clang_make_opts HOSTCC=clang CC=clang LLVM_IAS=%{llvm_ias}
%if %{with clang_lto}
%global clang_make_opts %{clang_make_opts} LD=ld.lld HOSTLD=ld.lld AR=llvm-ar NM=llvm-nm HOSTAR=llvm-ar HOSTNM=llvm-nm
%endif
%global make_opts %{make_opts} %{clang_make_opts}
# clang does not support the -fdump-ipa-clones option
%global with_ipaclones 0
%endif
# turn off debug kernel and kabichk for gcov builds
%if %{with_gcov}
%define with_debug 0
%define with_kabichk 0
%define with_kabidupchk 0
%define with_kabidwchk 0
kernel.spec: disable more kabi switches for gcov build Backport of RHEL8 commit. commit 128ccd9b6c19f5cce20fac1479d9677623fbfc26 Author: Jan Stancek <jstancek@redhat.com> Date: Tue Dec 10 14:53:25 2019 -0500 [redhat] disable more kabi switches for gcov build Message-id: <2e9b8ebc97c9eb430116a118dc8003f44870abf9.1575989369.git.jstancek@redhat.com> Patchwork-id: 291825 O-Subject: [RHEL8.2 PATCH] redhat: disable more kabi switches for gcov build Bugzilla: 1781513 RH-Acked-by: Bruno Eduardo de Oliveira Meneguele <bmeneg@redhat.com> RH-Acked-by: Čestmír Kalina <ckalina@redhat.com> RH-Acked-by: Herton R. Krzesinski <herton@redhat.com> Bugzilla: 1781513 Brew: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=25255969 Upstream: RHEL only Tested: make rh-srpm-gcov + compile only in brew gcov build disables with_kabichk, which makes Source300 undefined. But there are still couple kabi switches which use SOURCE300, which can cause brew build to fail: + tar xjvf '%{SOURCE300}' -C /builddir/build/BUILDROOT/kernel-4.18.0-161.el8.gcov.noarch/lib/modules/ tar (child): %{SOURCE300}: Cannot open: No such file or directory tar (child): Error is not recoverable: exiting now tar: Child returned status 2 tar: Error is not recoverable: exiting now RPM build errors: error: Bad exit status from /var/tmp/rpm-tmp.lcnD1l (%install) Bad exit status from /var/tmp/rpm-tmp.lcnD1l (%install) Child return code was: 1 Signed-off-by: Jan Stancek <jstancek@redhat.com> Signed-off-by: Bruno Meneguele <bmeneg@redhat.com> Signed-off-by: Jiri Benc <jbenc@redhat.com> Signed-off-by: Jiri Olsa <jolsa@redhat.com>
2021-04-23 08:15:21 +00:00
%define with_kabidw_base 0
%define with_kernel_abi_stablelists 0
%endif
# turn off kABI DWARF-based check if we're generating the base dataset
%if %{with_kabidw_base}
%define with_kabidwchk 0
%endif
# kpatch_kcflags are extra compiler flags applied to base kernel
# -fdump-ipa-clones is enabled only for base kernels on selected arches
%if %{with_ipaclones}
%ifarch x86_64 ppc64le
%define kpatch_kcflags -fdump-ipa-clones
%else
%define with_ipaclones 0
%endif
%endif
%define make_target bzImage
%define image_install_path boot
%define KVERREL %{version}-%{release}.%{_target_cpu}
%define KVERREL_RE %(echo %KVERREL | sed 's/+/[+]/g')
%define hdrarch %_target_cpu
%define asmarch %_target_cpu
%if 0%{!?nopatches:1}
%define nopatches 0
%endif
%if %{with_vanilla}
%define nopatches 1
%endif
%if %{with_release}
%define debugbuildsenabled 1
%endif
%if !%{with_debuginfo}
%define _enable_debug_packages 0
%endif
%define debuginfodir /usr/lib/debug
# Needed because we override almost everything involving build-ids
# and debuginfo generation. Currently we rely on the old alldebug setting.
%global _build_id_links alldebug
# kernel PAE is only built on ARMv7
%ifnarch armv7hl
%define with_pae 0
%endif
# RT kernel is only built on x86_64 and aarch64
%ifnarch x86_64 aarch64
%define with_realtime 0
%endif
# if requested, only build base kernel
%if %{with_baseonly}
%define with_pae 0
%define with_debug 0
%define with_realtime 0
%define with_vdso_install 0
%define with_perf 0
%define with_tools 0
%define with_kernel_abi_stablelists 0
%define with_selftests 0
%define with_cross 0
%define with_cross_headers 0
%define with_ipaclones 0
%endif
# if requested, only build pae kernel
%if %{with_paeonly}
%define with_up 0
%define with_debug 0
%define with_realtime 0
%endif
# if requested, only build debug kernel
%if %{with_dbgonly}
%define with_up 0
%define with_realtime 0
%define with_vdso_install 0
%define with_perf 0
%define with_tools 0
%define with_kernel_abi_stablelists 0
%define with_selftests 0
%define with_cross 0
%define with_cross_headers 0
%define with_ipaclones 0
%endif
# if requested, only build realtime kernel
%if %{with_rtonly}
%define with_up 0
%define with_pae 0
%define with_debug 0
%define with_vdso_install 0
%define with_perf 0
%define with_tools 0
%define with_kernel_abi_stablelists 0
%define with_selftests 0
%define with_cross 0
%define with_cross_headers 0
%define with_ipaclones 0
%endif
# turn off kABI DUP check and DWARF-based check if kABI check is disabled
%if !%{with_kabichk}
%define with_kabidupchk 0
%define with_kabidwchk 0
%endif
%if %{with_vdso_install}
%define use_vdso 1
%endif
%ifnarch noarch
%define with_kernel_abi_stablelists 0
%endif
# Overrides for generic default options
# only package docs noarch
%ifnarch noarch
%define with_doc 0
%define doc_build_fail true
%endif
%if 0%{?fedora}
# don't do debug builds on anything but i686 and x86_64
%ifnarch i686 x86_64
%define with_debug 0
%endif
%endif
# don't build noarch kernels or headers (duh)
%ifarch noarch
%define with_up 0
%define with_realtime 0
%define with_headers 0
%define with_cross_headers 0
%define with_tools 0
%define with_perf 0
%define with_selftests 0
%define with_debug 0
%define all_arch_configs kernel-%{version}-*.config
%endif
# sparse blows up on ppc
%ifnarch ppc64le
%define with_sparse 0
%endif
# zfcpdump mechanism is s390 only
%ifnarch s390x
%define with_zfcpdump 0
%endif
# 64k variant only for aarch64
%ifnarch aarch64
%define with_arm64_64k 0
%define with_realtime_arm64_64k 0
%endif
%if 0%{?fedora}
# This is not for Fedora
%define with_zfcpdump 0
%endif
# Per-arch tweaks
%ifarch i686
%define asmarch x86
%define hdrarch i386
%define all_arch_configs kernel-%{version}-i?86*.config
%define kernel_image arch/x86/boot/bzImage
%endif
%ifarch x86_64
%define asmarch x86
%define all_arch_configs kernel-%{version}-x86_64*.config
%define kernel_image arch/x86/boot/bzImage
%endif
%ifarch ppc64le
%define asmarch powerpc
%define hdrarch powerpc
%define make_target vmlinux
%define kernel_image vmlinux
%define kernel_image_elf 1
%define use_vdso 0
%define all_arch_configs kernel-%{version}-ppc64le*.config
%endif
%ifarch s390x
%define asmarch s390
%define hdrarch s390
%define all_arch_configs kernel-%{version}-s390x.config
%define kernel_image arch/s390/boot/bzImage
%define vmlinux_decompressor arch/s390/boot/compressed/vmlinux
%endif
%ifarch %{arm}
%define all_arch_configs kernel-%{version}-arm*.config
%define skip_nonpae_vdso 1
%define asmarch arm
%define hdrarch arm
%define make_target bzImage
%define kernel_image arch/arm/boot/zImage
# http://lists.infradead.org/pipermail/linux-arm-kernel/2012-March/091404.html
%define kernel_mflags KALLSYMS_EXTRA_PASS=1
# we only build headers/perf/tools on the base arm arches
# just like we used to only build them on i386 for x86
%ifnarch armv7hl
%define with_headers 0
%define with_cross_headers 0
%endif
# These currently don't compile on armv7
%define with_selftests 0
%endif
%ifarch aarch64
%define all_arch_configs kernel-%{version}-aarch64*.config
%define asmarch arm64
%define hdrarch arm64
%define make_target vmlinuz.efi
%define kernel_image arch/arm64/boot/vmlinuz.efi
%endif
# Should make listnewconfig fail if there's config options
# printed out?
%if %{nopatches}
%define with_configchecks 0
%endif
# To temporarily exclude an architecture from being built, add it to
# %%nobuildarches. Do _NOT_ use the ExclusiveArch: line, because if we
# don't build kernel-headers then the new build system will no longer let
# us use the previous build of that package -- it'll just be completely AWOL.
# Which is a BadThing(tm).
# We only build kernel-headers on the following...
%if 0%{?fedora}
%define nobuildarches i386
%else
%define nobuildarches i386 i686 %{arm}
%endif
%ifarch %nobuildarches
# disable BuildKernel commands
%define with_up 0
%define with_debug 0
%define with_pae 0
%define with_zfcpdump 0
%define with_arm64_64k 0
%define with_realtime 0
%define with_realtime_arm64_64k 0
%define with_debuginfo 0
%define with_perf 0
%define with_tools 0
%define with_selftests 0
%define _enable_debug_packages 0
%endif
# Architectures we build tools/cpupower on
%if 0%{?fedora}
%define cpupowerarchs %{ix86} x86_64 ppc64le %{arm} aarch64
%else
%define cpupowerarchs i686 x86_64 ppc64le aarch64
%endif
%if 0%{?use_vdso}
%if 0%{?skip_nonpae_vdso}
%define _use_vdso 0
%else
%define _use_vdso 1
%endif
%else
%define _use_vdso 0
%endif
# If build of debug packages is disabled, we need to know if we want to create
# meta debug packages or not, after we define with_debug for all specific cases
# above. So this must be at the end here, after all cases of with_debug or not.
%define with_debug_meta 0
%if !%{debugbuildsenabled}
%if %{with_debug}
%define with_debug_meta 1
%endif
%define with_debug 0
%endif
#
# Packages that need to be installed before the kernel is, because the %%post
# scripts use them.
#
%define kernel_prereq coreutils, systemd >= 203-2, /usr/bin/kernel-install
%define initrd_prereq dracut >= 027
Name: kernel
License: ((GPL-2.0-only WITH Linux-syscall-note) OR BSD-2-Clause) AND ((GPL-2.0-only WITH Linux-syscall-note) OR BSD-3-Clause) AND ((GPL-2.0-only WITH Linux-syscall-note) OR CDDL-1.0) AND ((GPL-2.0-only WITH Linux-syscall-note) OR Linux-OpenIB) AND ((GPL-2.0-only WITH Linux-syscall-note) OR MIT) AND ((GPL-2.0-or-later WITH Linux-syscall-note) OR BSD-3-Clause) AND ((GPL-2.0-or-later WITH Linux-syscall-note) OR MIT) AND Apache-2.0 AND BSD-2-Clause AND BSD-3-Clause AND BSD-3-Clause-Clear AND GFDL-1.1-no-invariants-or-later AND GPL-1.0-or-later AND (GPL-1.0-or-later OR BSD-3-Clause) AND (GPL-1.0-or-later WITH Linux-syscall-note) AND GPL-2.0-only AND (GPL-2.0-only OR Apache-2.0) AND (GPL-2.0-only OR BSD-2-Clause) AND (GPL-2.0-only OR BSD-3-Clause) AND (GPL-2.0-only OR CDDL-1.0) AND (GPL-2.0-only OR GFDL-1.1-no-invariants-or-later) AND (GPL-2.0-only OR GFDL-1.2-no-invariants-only) AND (GPL-2.0-only WITH Linux-syscall-note) AND GPL-2.0-or-later AND (GPL-2.0-or-later OR BSD-2-Clause) AND (GPL-2.0-or-later OR BSD-3-Clause) AND (GPL-2.0-or-later OR CC-BY-4.0) AND (GPL-2.0-or-later WITH GCC-exception-2.0) AND (GPL-2.0-or-later WITH Linux-syscall-note) AND ISC AND LGPL-2.0-or-later AND (LGPL-2.0-or-later OR BSD-2-Clause) AND (LGPL-2.0-or-later WITH Linux-syscall-note) AND LGPL-2.1-only AND (LGPL-2.1-only OR BSD-2-Clause) AND (LGPL-2.1-only WITH Linux-syscall-note) AND LGPL-2.1-or-later AND (LGPL-2.1-or-later WITH Linux-syscall-note) AND (Linux-OpenIB OR GPL-2.0-only) AND (Linux-OpenIB OR GPL-2.0-only OR BSD-2-Clause) AND Linux-man-pages-copyleft AND MIT AND (MIT OR GPL-2.0-only) AND (MIT OR GPL-2.0-or-later) AND (MIT OR LGPL-2.1-only) AND (MPL-1.1 OR GPL-2.0-only) AND (X11 OR GPL-2.0-only) AND (X11 OR GPL-2.0-or-later) AND Zlib
URL: https://www.kernel.org/
Version: %{specversion}
Release: %{pkg_release}
# DO NOT CHANGE THE 'ExclusiveArch' LINE TO TEMPORARILY EXCLUDE AN ARCHITECTURE BUILD.
# SET %%nobuildarches (ABOVE) INSTEAD
%if 0%{?fedora}
ExclusiveArch: noarch x86_64 s390x %{arm} aarch64 ppc64le
%else
ExclusiveArch: noarch i386 i686 x86_64 s390x %{arm} aarch64 ppc64le
%endif
ExclusiveOS: Linux
%ifnarch %{nobuildarches}
Requires: kernel-core-uname-r = %{KVERREL}
Requires: kernel-modules-uname-r = %{KVERREL}
Requires: kernel-modules-core-uname-r = %{KVERREL}
Provides: installonlypkg(kernel)
%endif
#
# List the packages used during the kernel build
#
BuildRequires: kmod, bash, coreutils, tar, git-core, which
BuildRequires: bzip2, xz, findutils, gzip, m4, perl-interpreter, perl-Carp, perl-devel, perl-generators, make, diffutils, gawk, %compression
BuildRequires: gcc, binutils, redhat-rpm-config, hmaccalc, bison, flex, gcc-c++
BuildRequires: net-tools, hostname, bc, elfutils-devel
BuildRequires: dwarves
BuildRequires: python3-devel
BuildRequires: gcc-plugin-devel
BuildRequires: kernel-rpm-macros >= 185-9
# glibc-static is required for a consistent build environment (specifically
# CONFIG_CC_CAN_LINK_STATIC=y).
BuildRequires: glibc-static
%if %{with_headers}
BuildRequires: rsync
%endif
%if %{with_doc}
BuildRequires: xmlto, asciidoc, python3-sphinx, python3-sphinx_rtd_theme, python3-pyyaml
%endif
%if %{with_sparse}
BuildRequires: sparse
%endif
%if %{with_perf}
BuildRequires: zlib-devel binutils-devel newt-devel perl(ExtUtils::Embed) bison flex xz-devel
BuildRequires: audit-libs-devel python3-setuptools
BuildRequires: java-devel
BuildRequires: libbpf-devel >= 0.6.0-1
BuildRequires: libbabeltrace-devel
BuildRequires: libtraceevent-devel
%ifnarch %{arm} s390x
BuildRequires: numactl-devel
%endif
%ifarch aarch64
BuildRequires: opencsd-devel >= 1.2.1
%endif
%endif
%if %{with_tools}
BuildRequires: gettext ncurses-devel
BuildRequires: libcap-devel libcap-ng-devel
# The following are rtla requirements
BuildRequires: python3-docutils
BuildRequires: libtraceevent-devel
BuildRequires: libtracefs-devel
BuildRequires: libbpf-devel
BuildRequires: bpftool
BuildRequires: clang
%ifnarch s390x
BuildRequires: pciutils-devel
%endif
%ifarch i686 x86_64
BuildRequires: libnl3-devel
%endif
%endif
%if %{with_tools} || %{signmodules} || %{signkernel}
BuildRequires: openssl-devel
%endif
%if %{with_selftests}
BuildRequires: clang llvm fuse-devel zlib-devel binutils-devel python3-docutils
%ifarch x86_64
BuildRequires: lld
%endif
%ifnarch %{arm}
BuildRequires: numactl-devel
%endif
BuildRequires: libcap-devel libcap-ng-devel rsync libmnl-devel
%endif
BuildConflicts: rhbuildsys(DiskFree) < 500Mb
%if %{with_debuginfo}
BuildRequires: rpm-build, elfutils
BuildConflicts: rpm < 4.13.0.1-19
BuildConflicts: dwarves < 1.13
# Most of these should be enabled after more investigation
%undefine _include_minidebuginfo
%undefine _find_debuginfo_dwz_opts
%undefine _unique_build_ids
%undefine _unique_debug_names
%undefine _unique_debug_srcs
%undefine _debugsource_packages
%undefine _debuginfo_subpackages
# Remove -q option below to provide 'extracting debug info' messages
%global _find_debuginfo_opts -r -q
%global _missing_build_ids_terminate_build 1
%global _no_recompute_build_ids 1
%endif
%if %{with_kabidwchk} || %{with_kabidw_base}
BuildRequires: kabi-dw
%endif
%if %{signkernel}%{signmodules}
BuildRequires: openssl
%if %{signkernel}
# ELN uses Fedora signing process, so exclude
%if 0%{?rhel}%{?centos} && !0%{?eln}
BuildRequires: system-sb-certs
%endif
%ifarch x86_64 aarch64
BuildRequires: nss-tools
BuildRequires: pesign >= 0.10-4
%endif
%endif
%endif
%if %{with_cross}
BuildRequires: binutils-%{_build_arch}-linux-gnu, gcc-%{_build_arch}-linux-gnu
%define cross_opts CROSS_COMPILE=%{_build_arch}-linux-gnu-
%define __strip %{_build_arch}-linux-gnu-strip
%endif
# These below are required to build man pages
%if %{with_perf}
BuildRequires: xmlto
%endif
%if %{with_perf} || %{with_tools}
BuildRequires: asciidoc
%endif
%if %{with toolchain_clang}
BuildRequires: clang
%endif
%if %{with clang_lto}
BuildRequires: llvm
BuildRequires: lld
%endif
redhat: Add sub-RPM with a EFI unified kernel image for virtual machines Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2142102 Upstream Status: RHEL only The new 'kernel-unified-virt' sub-RPM is added on x86_64 targets. This contains an EFI application that provides a combined vmlinux, initrd and cmdline, as a so called 'unified kernel image'. The spec for this is defined by the boot loader specification https://uapi-group.org/specifications/specs/boot_loader_specification/ The key benefit of a unified kernel is that its secure boot signature covers the initrd and cmdline contents, allowing a trustworthy measured boot process with attestation, which is not practical with locally generated initrds/cmdlines. Since the initrd is pre-generated its contents have to be very generic, to be usable on a wide variety of deployments. To make this problem tractable, the sub-RPM targets only usage in virtual machines. With such a restriction, the initrd only needs a very small set of block driver modules present, in order to be usable across KVM, Hyper-V and Xen hypervisors which will cover essentially all common public and private clouds. Similarly the kernel cmdline cannot contain any host specific data, which means the root filesystem to mount needs to be able to be automatically detected. A virtual machine image intending to use this unified kernel package thus needs to comply with the discoverable partitions specification: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/ Based-on-patch-by: Daniel P. Berrangé <berrange@redhat.com> Based-on-patch-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
2022-11-07 09:21:43 +00:00
%if %{efiuki}
BuildRequires: dracut >= 057-79.git20241127.el9
redhat: Add sub-RPM with a EFI unified kernel image for virtual machines Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2142102 Upstream Status: RHEL only The new 'kernel-unified-virt' sub-RPM is added on x86_64 targets. This contains an EFI application that provides a combined vmlinux, initrd and cmdline, as a so called 'unified kernel image'. The spec for this is defined by the boot loader specification https://uapi-group.org/specifications/specs/boot_loader_specification/ The key benefit of a unified kernel is that its secure boot signature covers the initrd and cmdline contents, allowing a trustworthy measured boot process with attestation, which is not practical with locally generated initrds/cmdlines. Since the initrd is pre-generated its contents have to be very generic, to be usable on a wide variety of deployments. To make this problem tractable, the sub-RPM targets only usage in virtual machines. With such a restriction, the initrd only needs a very small set of block driver modules present, in order to be usable across KVM, Hyper-V and Xen hypervisors which will cover essentially all common public and private clouds. Similarly the kernel cmdline cannot contain any host specific data, which means the root filesystem to mount needs to be able to be automatically detected. A virtual machine image intending to use this unified kernel package thus needs to comply with the discoverable partitions specification: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/ Based-on-patch-by: Daniel P. Berrangé <berrange@redhat.com> Based-on-patch-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
2022-11-07 09:21:43 +00:00
# For dracut UEFI uki binaries
BuildRequires: binutils
# For the initrd
BuildRequires: lvm2
# For systemd-stub
redhat: Add sub-RPM with a EFI unified kernel image for virtual machines Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2142102 Upstream Status: RHEL only The new 'kernel-unified-virt' sub-RPM is added on x86_64 targets. This contains an EFI application that provides a combined vmlinux, initrd and cmdline, as a so called 'unified kernel image'. The spec for this is defined by the boot loader specification https://uapi-group.org/specifications/specs/boot_loader_specification/ The key benefit of a unified kernel is that its secure boot signature covers the initrd and cmdline contents, allowing a trustworthy measured boot process with attestation, which is not practical with locally generated initrds/cmdlines. Since the initrd is pre-generated its contents have to be very generic, to be usable on a wide variety of deployments. To make this problem tractable, the sub-RPM targets only usage in virtual machines. With such a restriction, the initrd only needs a very small set of block driver modules present, in order to be usable across KVM, Hyper-V and Xen hypervisors which will cover essentially all common public and private clouds. Similarly the kernel cmdline cannot contain any host specific data, which means the root filesystem to mount needs to be able to be automatically detected. A virtual machine image intending to use this unified kernel package thus needs to comply with the discoverable partitions specification: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/ Based-on-patch-by: Daniel P. Berrangé <berrange@redhat.com> Based-on-patch-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
2022-11-07 09:21:43 +00:00
BuildRequires: systemd-boot-unsigned
# For systemd-pcrphase
redhat: Add sub-RPM with a EFI unified kernel image for virtual machines Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2142102 Upstream Status: RHEL only The new 'kernel-unified-virt' sub-RPM is added on x86_64 targets. This contains an EFI application that provides a combined vmlinux, initrd and cmdline, as a so called 'unified kernel image'. The spec for this is defined by the boot loader specification https://uapi-group.org/specifications/specs/boot_loader_specification/ The key benefit of a unified kernel is that its secure boot signature covers the initrd and cmdline contents, allowing a trustworthy measured boot process with attestation, which is not practical with locally generated initrds/cmdlines. Since the initrd is pre-generated its contents have to be very generic, to be usable on a wide variety of deployments. To make this problem tractable, the sub-RPM targets only usage in virtual machines. With such a restriction, the initrd only needs a very small set of block driver modules present, in order to be usable across KVM, Hyper-V and Xen hypervisors which will cover essentially all common public and private clouds. Similarly the kernel cmdline cannot contain any host specific data, which means the root filesystem to mount needs to be able to be automatically detected. A virtual machine image intending to use this unified kernel package thus needs to comply with the discoverable partitions specification: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/ Based-on-patch-by: Daniel P. Berrangé <berrange@redhat.com> Based-on-patch-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
2022-11-07 09:21:43 +00:00
BuildRequires: systemd-udev >= 252-1
# For UKI kernel cmdline addons
BuildRequires: systemd-ukify
redhat: Add sub-RPM with a EFI unified kernel image for virtual machines Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2142102 Upstream Status: RHEL only The new 'kernel-unified-virt' sub-RPM is added on x86_64 targets. This contains an EFI application that provides a combined vmlinux, initrd and cmdline, as a so called 'unified kernel image'. The spec for this is defined by the boot loader specification https://uapi-group.org/specifications/specs/boot_loader_specification/ The key benefit of a unified kernel is that its secure boot signature covers the initrd and cmdline contents, allowing a trustworthy measured boot process with attestation, which is not practical with locally generated initrds/cmdlines. Since the initrd is pre-generated its contents have to be very generic, to be usable on a wide variety of deployments. To make this problem tractable, the sub-RPM targets only usage in virtual machines. With such a restriction, the initrd only needs a very small set of block driver modules present, in order to be usable across KVM, Hyper-V and Xen hypervisors which will cover essentially all common public and private clouds. Similarly the kernel cmdline cannot contain any host specific data, which means the root filesystem to mount needs to be able to be automatically detected. A virtual machine image intending to use this unified kernel package thus needs to comply with the discoverable partitions specification: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/ Based-on-patch-by: Daniel P. Berrangé <berrange@redhat.com> Based-on-patch-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
2022-11-07 09:21:43 +00:00
# For TPM operations in UKI initramfs
BuildRequires: tpm2-tools
# For UKI sb cert
%if 0%{?centos}
BuildRequires: centos-sb-certs >= 9.0-23
%else
BuildRequires: redhat-sb-certs >= 9.4-0.1
%endif
redhat: Add sub-RPM with a EFI unified kernel image for virtual machines Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2142102 Upstream Status: RHEL only The new 'kernel-unified-virt' sub-RPM is added on x86_64 targets. This contains an EFI application that provides a combined vmlinux, initrd and cmdline, as a so called 'unified kernel image'. The spec for this is defined by the boot loader specification https://uapi-group.org/specifications/specs/boot_loader_specification/ The key benefit of a unified kernel is that its secure boot signature covers the initrd and cmdline contents, allowing a trustworthy measured boot process with attestation, which is not practical with locally generated initrds/cmdlines. Since the initrd is pre-generated its contents have to be very generic, to be usable on a wide variety of deployments. To make this problem tractable, the sub-RPM targets only usage in virtual machines. With such a restriction, the initrd only needs a very small set of block driver modules present, in order to be usable across KVM, Hyper-V and Xen hypervisors which will cover essentially all common public and private clouds. Similarly the kernel cmdline cannot contain any host specific data, which means the root filesystem to mount needs to be able to be automatically detected. A virtual machine image intending to use this unified kernel package thus needs to comply with the discoverable partitions specification: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/ Based-on-patch-by: Daniel P. Berrangé <berrange@redhat.com> Based-on-patch-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
2022-11-07 09:21:43 +00:00
%endif
# Because this is the kernel, it's hard to get a single upstream URL
# to represent the base without needing to do a bunch of patching. This
# tarball is generated from a src-git tree. If you want to see the
# exact git commit you can run
#
# xzcat -qq ${TARBALL} | git get-tar-commit-id
Source0: linux-%{tarfile_release}.tar.xz
Source1: Makefile.rhelver
Source2: kernel.changelog
redhat: switch the kernel package to use certs from system-sb-certs Bugzilla: INTERNAL Upstream Status: RHEL only commit ff5d8e5c949ed0e3468632fffa113d46ddcf8aea Author: Herton R. Krzesinski <herton@redhat.com> Date: Tue Jan 25 20:15:17 2022 -0300 redhat: switch the kernel package to use certs from system-sb-certs Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2045327 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2037084 Upstream Status: RHEL only Both redhat and centos are providing now the public certificates we use for secure boot signing through the redhat-sb-certs or centos-sb-certs packages. Those provides the system-sb-certs "virtual" package. Thus don't carry anymore the copy of the same certificates inside the kernel sources, instead switch to use the certificates provided by those packages. This will enable secure boot signing for centos too, as centos uses a different set of certificates for signing and we were not using them in the package yet. With this change, we also drop the usage of the beta certificates and the switch to the release certs: they aren't provided in the new scheme of system-sb-certs and anyway eg. grub2 isn't including/using those certs for signing. If there are still any switching of keys needed, ideally this should be done with the package providing system-sb-certs. While reviewing/doing this change, I also noted some missing signkernel macro guards were missing in the spec, which I added. Also, in the install part where we copy files to the kernel-doc package, I consolidated the logic and added missing signkernel/signmodules guards, with the existing code things would break if you disabled any of those options. v2: change pesign_name_0 for CentOS as reported by Brian Stinson Signed-off-by: Herton R. Krzesinski <herton@redhat.com> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
2022-08-29 19:46:18 +00:00
%if %{signkernel}
# Name of the packaged file containing signing key
%ifarch ppc64le
%define signing_key_filename kernel-signing-ppc.cer
%endif
%ifarch s390x
%define signing_key_filename kernel-signing-s390.cer
%endif
redhat: switch the kernel package to use certs from system-sb-certs Bugzilla: INTERNAL Upstream Status: RHEL only commit ff5d8e5c949ed0e3468632fffa113d46ddcf8aea Author: Herton R. Krzesinski <herton@redhat.com> Date: Tue Jan 25 20:15:17 2022 -0300 redhat: switch the kernel package to use certs from system-sb-certs Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2045327 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2037084 Upstream Status: RHEL only Both redhat and centos are providing now the public certificates we use for secure boot signing through the redhat-sb-certs or centos-sb-certs packages. Those provides the system-sb-certs "virtual" package. Thus don't carry anymore the copy of the same certificates inside the kernel sources, instead switch to use the certificates provided by those packages. This will enable secure boot signing for centos too, as centos uses a different set of certificates for signing and we were not using them in the package yet. With this change, we also drop the usage of the beta certificates and the switch to the release certs: they aren't provided in the new scheme of system-sb-certs and anyway eg. grub2 isn't including/using those certs for signing. If there are still any switching of keys needed, ideally this should be done with the package providing system-sb-certs. While reviewing/doing this change, I also noted some missing signkernel macro guards were missing in the spec, which I added. Also, in the install part where we copy files to the kernel-doc package, I consolidated the logic and added missing signkernel/signmodules guards, with the existing code things would break if you disabled any of those options. v2: change pesign_name_0 for CentOS as reported by Brian Stinson Signed-off-by: Herton R. Krzesinski <herton@redhat.com> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
2022-08-29 19:46:18 +00:00
%define secureboot_ca_0 %{_datadir}/pki/sb-certs/secureboot-ca-%{_arch}.cer
%define secureboot_key_0 %{_datadir}/pki/sb-certs/secureboot-kernel-%{_arch}.cer
redhat: switch the kernel package to use certs from system-sb-certs Bugzilla: INTERNAL Upstream Status: RHEL only commit ff5d8e5c949ed0e3468632fffa113d46ddcf8aea Author: Herton R. Krzesinski <herton@redhat.com> Date: Tue Jan 25 20:15:17 2022 -0300 redhat: switch the kernel package to use certs from system-sb-certs Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2045327 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2037084 Upstream Status: RHEL only Both redhat and centos are providing now the public certificates we use for secure boot signing through the redhat-sb-certs or centos-sb-certs packages. Those provides the system-sb-certs "virtual" package. Thus don't carry anymore the copy of the same certificates inside the kernel sources, instead switch to use the certificates provided by those packages. This will enable secure boot signing for centos too, as centos uses a different set of certificates for signing and we were not using them in the package yet. With this change, we also drop the usage of the beta certificates and the switch to the release certs: they aren't provided in the new scheme of system-sb-certs and anyway eg. grub2 isn't including/using those certs for signing. If there are still any switching of keys needed, ideally this should be done with the package providing system-sb-certs. While reviewing/doing this change, I also noted some missing signkernel macro guards were missing in the spec, which I added. Also, in the install part where we copy files to the kernel-doc package, I consolidated the logic and added missing signkernel/signmodules guards, with the existing code things would break if you disabled any of those options. v2: change pesign_name_0 for CentOS as reported by Brian Stinson Signed-off-by: Herton R. Krzesinski <herton@redhat.com> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
2022-08-29 19:46:18 +00:00
%if 0%{?centos}
%define pesign_name_0 centossecureboot201
%else
%ifarch x86_64 aarch64
%define pesign_name_0 redhatsecureboot501
%endif
%ifarch s390x
%define pesign_name_0 redhatsecureboot302
%endif
%ifarch ppc64le
%define pesign_name_0 redhatsecureboot701
%endif
redhat: switch the kernel package to use certs from system-sb-certs Bugzilla: INTERNAL Upstream Status: RHEL only commit ff5d8e5c949ed0e3468632fffa113d46ddcf8aea Author: Herton R. Krzesinski <herton@redhat.com> Date: Tue Jan 25 20:15:17 2022 -0300 redhat: switch the kernel package to use certs from system-sb-certs Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2045327 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2037084 Upstream Status: RHEL only Both redhat and centos are providing now the public certificates we use for secure boot signing through the redhat-sb-certs or centos-sb-certs packages. Those provides the system-sb-certs "virtual" package. Thus don't carry anymore the copy of the same certificates inside the kernel sources, instead switch to use the certificates provided by those packages. This will enable secure boot signing for centos too, as centos uses a different set of certificates for signing and we were not using them in the package yet. With this change, we also drop the usage of the beta certificates and the switch to the release certs: they aren't provided in the new scheme of system-sb-certs and anyway eg. grub2 isn't including/using those certs for signing. If there are still any switching of keys needed, ideally this should be done with the package providing system-sb-certs. While reviewing/doing this change, I also noted some missing signkernel macro guards were missing in the spec, which I added. Also, in the install part where we copy files to the kernel-doc package, I consolidated the logic and added missing signkernel/signmodules guards, with the existing code things would break if you disabled any of those options. v2: change pesign_name_0 for CentOS as reported by Brian Stinson Signed-off-by: Herton R. Krzesinski <herton@redhat.com> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
2022-08-29 19:46:18 +00:00
%endif
redhat: switch the kernel package to use certs from system-sb-certs Bugzilla: INTERNAL Upstream Status: RHEL only commit ff5d8e5c949ed0e3468632fffa113d46ddcf8aea Author: Herton R. Krzesinski <herton@redhat.com> Date: Tue Jan 25 20:15:17 2022 -0300 redhat: switch the kernel package to use certs from system-sb-certs Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2045327 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2037084 Upstream Status: RHEL only Both redhat and centos are providing now the public certificates we use for secure boot signing through the redhat-sb-certs or centos-sb-certs packages. Those provides the system-sb-certs "virtual" package. Thus don't carry anymore the copy of the same certificates inside the kernel sources, instead switch to use the certificates provided by those packages. This will enable secure boot signing for centos too, as centos uses a different set of certificates for signing and we were not using them in the package yet. With this change, we also drop the usage of the beta certificates and the switch to the release certs: they aren't provided in the new scheme of system-sb-certs and anyway eg. grub2 isn't including/using those certs for signing. If there are still any switching of keys needed, ideally this should be done with the package providing system-sb-certs. While reviewing/doing this change, I also noted some missing signkernel macro guards were missing in the spec, which I added. Also, in the install part where we copy files to the kernel-doc package, I consolidated the logic and added missing signkernel/signmodules guards, with the existing code things would break if you disabled any of those options. v2: change pesign_name_0 for CentOS as reported by Brian Stinson Signed-off-by: Herton R. Krzesinski <herton@redhat.com> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
2022-08-29 19:46:18 +00:00
# signkernel
%endif
Source20: mod-denylist.sh
Source21: mod-sign.sh
Source22: parallel_xz.sh
%define modsign_cmd %{SOURCE21}
%if 0%{?include_rhel}
Source23: x509.genkey.rhel
Source24: kernel-aarch64-rhel.config
Source25: kernel-aarch64-debug-rhel.config
Source26: mod-extra.list.rhel
Source27: kernel-ppc64le-rhel.config
Source28: kernel-ppc64le-debug-rhel.config
Source29: kernel-s390x-rhel.config
Source30: kernel-s390x-debug-rhel.config
Source31: kernel-s390x-zfcpdump-rhel.config
Source32: kernel-x86_64-rhel.config
Source33: kernel-x86_64-debug-rhel.config
Source34: filter-x86_64.sh.rhel
Source35: filter-armv7hl.sh.rhel
Source37: filter-aarch64.sh.rhel
Source38: filter-ppc64le.sh.rhel
Source39: filter-s390x.sh.rhel
Source40: filter-modules.sh.rhel
Source41: x509.genkey.centos
# ARM64 64K page-size kernel config
Source42: kernel-aarch64-64k-rhel.config
Source43: kernel-aarch64-64k-debug-rhel.config
Source44: kernel-x86_64-rt-rhel.config
Source45: kernel-x86_64-rt-debug-rhel.config
Source46: kernel-aarch64-rt-rhel.config
Source47: kernel-aarch64-rt-debug-rhel.config
Source48: kernel-aarch64-rt-64k-rhel.config
Source49: kernel-aarch64-rt-64k-debug-rhel.config
%endif
%if 0%{?include_fedora}
Source50: x509.genkey.fedora
Source51: mod-extra.list.fedora
Source52: kernel-aarch64-fedora.config
Source53: kernel-aarch64-debug-fedora.config
Source54: kernel-armv7hl-fedora.config
Source55: kernel-armv7hl-debug-fedora.config
Source56: kernel-armv7hl-lpae-fedora.config
Source57: kernel-armv7hl-lpae-debug-fedora.config
Source60: kernel-ppc64le-fedora.config
Source61: kernel-ppc64le-debug-fedora.config
Source62: kernel-s390x-fedora.config
Source63: kernel-s390x-debug-fedora.config
Source64: kernel-x86_64-fedora.config
Source65: kernel-x86_64-debug-fedora.config
Source67: filter-x86_64.sh.fedora
Source68: filter-armv7hl.sh.fedora
Source70: filter-aarch64.sh.fedora
Source71: filter-ppc64le.sh.fedora
Source72: filter-s390x.sh.fedora
Source73: filter-modules.sh.fedora
%endif
Source75: partial-kgcov-snip.config
Source80: generate_all_configs.sh
Source81: process_configs.sh
Source82: update_scripts.sh
Source84: mod-internal.list
Source85: mod-partner.list
Source100: rheldup3.x509
Source101: rhelkpatch1.x509
Source102: rhelimaca1.x509
Source103: rhelima.x509
Source104: rhelima_centos.x509
Source105: nvidiagpuoot001.x509
%if 0%{?centos}
%define ima_signing_cert %{SOURCE104}
%else
%define ima_signing_cert %{SOURCE103}
%endif
%define ima_cert_name ima.cer
redhat: Add sub-RPM with a EFI unified kernel image for virtual machines Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2142102 Upstream Status: RHEL only The new 'kernel-unified-virt' sub-RPM is added on x86_64 targets. This contains an EFI application that provides a combined vmlinux, initrd and cmdline, as a so called 'unified kernel image'. The spec for this is defined by the boot loader specification https://uapi-group.org/specifications/specs/boot_loader_specification/ The key benefit of a unified kernel is that its secure boot signature covers the initrd and cmdline contents, allowing a trustworthy measured boot process with attestation, which is not practical with locally generated initrds/cmdlines. Since the initrd is pre-generated its contents have to be very generic, to be usable on a wide variety of deployments. To make this problem tractable, the sub-RPM targets only usage in virtual machines. With such a restriction, the initrd only needs a very small set of block driver modules present, in order to be usable across KVM, Hyper-V and Xen hypervisors which will cover essentially all common public and private clouds. Similarly the kernel cmdline cannot contain any host specific data, which means the root filesystem to mount needs to be able to be automatically detected. A virtual machine image intending to use this unified kernel package thus needs to comply with the discoverable partitions specification: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/ Based-on-patch-by: Daniel P. Berrangé <berrange@redhat.com> Based-on-patch-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
2022-11-07 09:21:43 +00:00
Source150: dracut-virt.conf
Source151: uki_create_addons.py
Source152: uki_addons.json
Source200: check-kabi
Source201: Module.kabi_aarch64
Source202: Module.kabi_ppc64le
Source203: Module.kabi_s390x
Source204: Module.kabi_x86_64
Source210: Module.kabi_dup_aarch64
Source211: Module.kabi_dup_ppc64le
Source212: Module.kabi_dup_s390x
Source213: Module.kabi_dup_x86_64
Source300: kernel-abi-stablelists-%{kabiversion}.tar.bz2
Source301: kernel-kabi-dw-%{kabiversion}.tar.bz2
# Sources for kernel-tools
Source2000: cpupower.service
Source2001: cpupower.config
Source2002: kvm_stat.logrotate
# Some people enjoy building customized kernels from the dist-git in Fedora and
# use this to override configuration options. One day they may all use the
# source tree, but in the mean time we carry this to support the legacy workflow
Source3000: merge.pl
Source3001: kernel-local
%if %{patchlist_changelog}
Source3002: Patchlist.changelog
%endif
Source4000: README.rst
Source4001: rpminspect.yaml
Source4002: gating.yaml
## Patches needed for building this package
%if !%{nopatches}
Patch1: patch-%{patchversion}-redhat.patch
%endif
# empty final patch to facilitate testing of kernel patches
Patch999999: linux-kernel-test.patch
# END OF PATCH DEFINITIONS
%description
The kernel meta package
#
# This macro does requires, provides, conflicts, obsoletes for a kernel package.
redhat: make kernel-zfcpdump-core to not provide kernel-core/kernel Bugzilla: INTERNAL Upstream Status: RHEL only, https://gitlab.com/cki-project/kernel-ark commit 97717f4f4aaa7ae6c85c3e326e8a180738ee1bcc Author: Herton R. Krzesinski <herton@redhat.com> Date: Fri Jul 15 14:04:36 2022 -0300 redhat: make kernel-zfcpdump-core to not provide kernel-core/kernel Upstream Status: RHEL only As reported on bug 2027654*, when doing dnf install kernel on s390x it might pull kernel-zfcpdump-core which should not be a choice for a generic kernel. Adjust the kernel_variant_package macro to add an option allowing adding provides or not and use it for the zfcpdump variant. v2: - fix if condition to not hide kernel-<flavour>-core-uname-r which is required by the kernel-<flavour> meta package. - wrap kernel provides in kernel_reqprovconf macro as well - rename the macro option from -p to -o as suggested by Daniel Horak v3: - fix kernel_reqprovconf expansion as noted by Bruno Goncalves/Jan Stancek v4: - do not wrap installonlypkg since that should be only a hint to yum/dnf to allow multiple versions of same packages installed This same change was applied to centos stream 9, and is being forwarded ported now to ARK/Fedora, with a fix for the -m option of kernel_variant_package, it doesn't have an argument so ':' can't be added after it, for some reason rpm in centos didn't have issues with it, but on ARK/Fedora we get a failure. *https://bugzilla.redhat.com/show_bug.cgi?id=2027654 Signed-off-by: Herton R. Krzesinski <herton@redhat.com> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
2022-08-29 18:01:08 +00:00
# %%kernel_reqprovconf [-o] <subpackage>
# It uses any kernel_<subpackage>_conflicts and kernel_<subpackage>_obsoletes
# macros defined above.
#
redhat: make kernel-zfcpdump-core to not provide kernel-core/kernel Bugzilla: INTERNAL Upstream Status: RHEL only, https://gitlab.com/cki-project/kernel-ark commit 97717f4f4aaa7ae6c85c3e326e8a180738ee1bcc Author: Herton R. Krzesinski <herton@redhat.com> Date: Fri Jul 15 14:04:36 2022 -0300 redhat: make kernel-zfcpdump-core to not provide kernel-core/kernel Upstream Status: RHEL only As reported on bug 2027654*, when doing dnf install kernel on s390x it might pull kernel-zfcpdump-core which should not be a choice for a generic kernel. Adjust the kernel_variant_package macro to add an option allowing adding provides or not and use it for the zfcpdump variant. v2: - fix if condition to not hide kernel-<flavour>-core-uname-r which is required by the kernel-<flavour> meta package. - wrap kernel provides in kernel_reqprovconf macro as well - rename the macro option from -p to -o as suggested by Daniel Horak v3: - fix kernel_reqprovconf expansion as noted by Bruno Goncalves/Jan Stancek v4: - do not wrap installonlypkg since that should be only a hint to yum/dnf to allow multiple versions of same packages installed This same change was applied to centos stream 9, and is being forwarded ported now to ARK/Fedora, with a fix for the -m option of kernel_variant_package, it doesn't have an argument so ':' can't be added after it, for some reason rpm in centos didn't have issues with it, but on ARK/Fedora we get a failure. *https://bugzilla.redhat.com/show_bug.cgi?id=2027654 Signed-off-by: Herton R. Krzesinski <herton@redhat.com> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
2022-08-29 18:01:08 +00:00
%define kernel_reqprovconf(o) \
%if %{-o:0}%{!-o:1}\
Provides: kernel = %{specversion}-%{pkg_release}\
redhat: make kernel-zfcpdump-core to not provide kernel-core/kernel Bugzilla: INTERNAL Upstream Status: RHEL only, https://gitlab.com/cki-project/kernel-ark commit 97717f4f4aaa7ae6c85c3e326e8a180738ee1bcc Author: Herton R. Krzesinski <herton@redhat.com> Date: Fri Jul 15 14:04:36 2022 -0300 redhat: make kernel-zfcpdump-core to not provide kernel-core/kernel Upstream Status: RHEL only As reported on bug 2027654*, when doing dnf install kernel on s390x it might pull kernel-zfcpdump-core which should not be a choice for a generic kernel. Adjust the kernel_variant_package macro to add an option allowing adding provides or not and use it for the zfcpdump variant. v2: - fix if condition to not hide kernel-<flavour>-core-uname-r which is required by the kernel-<flavour> meta package. - wrap kernel provides in kernel_reqprovconf macro as well - rename the macro option from -p to -o as suggested by Daniel Horak v3: - fix kernel_reqprovconf expansion as noted by Bruno Goncalves/Jan Stancek v4: - do not wrap installonlypkg since that should be only a hint to yum/dnf to allow multiple versions of same packages installed This same change was applied to centos stream 9, and is being forwarded ported now to ARK/Fedora, with a fix for the -m option of kernel_variant_package, it doesn't have an argument so ':' can't be added after it, for some reason rpm in centos didn't have issues with it, but on ARK/Fedora we get a failure. *https://bugzilla.redhat.com/show_bug.cgi?id=2027654 Signed-off-by: Herton R. Krzesinski <herton@redhat.com> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
2022-08-29 18:01:08 +00:00
%endif\
Provides: kernel-%{_target_cpu} = %{specversion}-%{pkg_release}%{uname_suffix %{?1:%{1}}}\
Provides: kernel-uname-r = %{KVERREL}%{uname_suffix %{?1:%{1}}}\
Requires: kernel%{?1:-%{1}}-modules-core-uname-r = %{KVERREL}%{uname_suffix %{?1:%{1}}}\
Requires(pre): %{kernel_prereq}\
Requires(pre): %{initrd_prereq}\
Requires(pre): ((linux-firmware >= 20150904-56.git6ebf5d57) if linux-firmware)\
Recommends: linux-firmware\
Requires(preun): systemd >= 200\
Conflicts: xfsprogs < 4.3.0-1\
Conflicts: xorg-x11-drv-vmmouse < 13.0.99\
%{expand:%%{?kernel%{?1:_%{1}}_conflicts:Conflicts: %%{kernel%{?1:_%{1}}_conflicts}}}\
%{expand:%%{?kernel%{?1:_%{1}}_obsoletes:Obsoletes: %%{kernel%{?1:_%{1}}_obsoletes}}}\
%{expand:%%{?kernel%{?1:_%{1}}_provides:Provides: %%{kernel%{?1:_%{1}}_provides}}}\
# We can't let RPM do the dependencies automatic because it'll then pick up\
# a correct but undesirable perl dependency from the module headers which\
# isn't required for the kernel proper to function\
AutoReq: no\
AutoProv: yes\
%{nil}
%package doc
Summary: Various documentation bits found in the kernel source
Group: Documentation
%description doc
This package contains documentation files from the kernel
source. Various bits of information about the Linux kernel and the
device drivers shipped with it are documented in these files.
You'll want to install this package if you need a reference to the
options that can be passed to Linux kernel modules at load time.
%package headers
Summary: Header files for the Linux kernel for use by glibc
Obsoletes: glibc-kernheaders < 3.0-46
Provides: glibc-kernheaders = 3.0-46
%description headers
Kernel-headers includes the C header files that specify the interface
between the Linux kernel and userspace libraries and programs. The
header files define structures and constants that are needed for
building most standard programs and are also needed for rebuilding the
glibc package.
%package cross-headers
Summary: Header files for the Linux kernel for use by cross-glibc
%description cross-headers
Kernel-cross-headers includes the C header files that specify the interface
between the Linux kernel and userspace libraries and programs. The
header files define structures and constants that are needed for
building most standard programs and are also needed for rebuilding the
cross-glibc package.
%package debuginfo-common-%{_target_cpu}
Summary: Kernel source files used by %{name}-debuginfo packages
Provides: installonlypkg(kernel)
%description debuginfo-common-%{_target_cpu}
This package is required by %{name}-debuginfo subpackages.
It provides the kernel source files common to all builds.
%if %{with_perf}
%package -n perf
Summary: Performance monitoring for the Linux kernel
Requires: bzip2
%description -n perf
This package contains the perf tool, which enables performance monitoring
of the Linux kernel.
%package -n perf-debuginfo
Summary: Debug information for package perf
Requires: %{name}-debuginfo-common-%{_target_cpu} = %{version}-%{release}
AutoReqProv: no
%description -n perf-debuginfo
This package provides debug information for the perf package.
# Note that this pattern only works right to match the .build-id
# symlinks because of the trailing nonmatching alternation and
# the leading .*, because of find-debuginfo.sh's buggy handling
# of matching the pattern against the symlinks file.
%{expand:%%global _find_debuginfo_opts %{?_find_debuginfo_opts} -p '.*%%{_bindir}/perf(\.debug)?|.*%%{_libexecdir}/perf-core/.*|.*%%{_libdir}/libperf-jvmti.so(\.debug)?|XXX' -o perf-debuginfo.list}
%package -n python3-perf
Summary: Python bindings for apps which will manipulate perf events
%description -n python3-perf
The python3-perf package contains a module that permits applications
written in the Python programming language to use the interface
to manipulate perf events.
%package -n python3-perf-debuginfo
Summary: Debug information for package perf python bindings
Requires: %{name}-debuginfo-common-%{_target_cpu} = %{version}-%{release}
AutoReqProv: no
%description -n python3-perf-debuginfo
This package provides debug information for the perf python bindings.
# the python_sitearch macro should already be defined from above
%{expand:%%global _find_debuginfo_opts %{?_find_debuginfo_opts} -p '.*%%{python3_sitearch}/perf.*so(\.debug)?|XXX' -o python3-perf-debuginfo.list}
%package -n libperf
Summary: The perf library from kernel source
%description -n libperf
This package contains the kernel source perf library.
%package -n libperf-devel
Summary: Developement files for the perf library from kernel source
Requires: libperf = %{version}-%{release}
%description -n libperf-devel
This package includes libraries and header files needed for development
of applications which use perf library from kernel source.
%package -n libperf-debuginfo
Summary: Debug information for package libperf
Group: Development/Debug
Requires: %{name}-debuginfo-common-%{_target_cpu} = %{version}-%{release}
AutoReqProv: no
%description -n libperf-debuginfo
This package provides debug information for the libperf package.
# Note that this pattern only works right to match the .build-id
# symlinks because of the trailing nonmatching alternation and
# the leading .*, because of find-debuginfo.sh's buggy handling
# of matching the pattern against the symlinks file.
%{expand:%%global _find_debuginfo_opts %{?_find_debuginfo_opts} -p '.*%%{_libdir}/libperf.so.*(\.debug)?|XXX' -o libperf-debuginfo.list}
# with_perf
%endif
%if %{with_tools}
%package -n kernel-tools
Summary: Assortment of tools for the Linux kernel
%ifarch %{cpupowerarchs}
Provides: cpupowerutils = 1:009-0.6.p1
Obsoletes: cpupowerutils < 1:009-0.6.p1
Provides: cpufreq-utils = 1:009-0.6.p1
Provides: cpufrequtils = 1:009-0.6.p1
Obsoletes: cpufreq-utils < 1:009-0.6.p1
Obsoletes: cpufrequtils < 1:009-0.6.p1
Obsoletes: cpuspeed < 1:1.5-16
Requires: kernel-tools-libs = %{version}-%{release}
%endif
%define __requires_exclude ^%{_bindir}/python
%description -n kernel-tools
This package contains the tools/ directory from the kernel source
and the supporting documentation.
%package -n kernel-tools-libs
Summary: Libraries for the kernels-tools
%description -n kernel-tools-libs
This package contains the libraries built from the tools/ directory
from the kernel source.
%package -n kernel-tools-libs-devel
Summary: Assortment of tools for the Linux kernel
Requires: kernel-tools = %{version}-%{release}
%ifarch %{cpupowerarchs}
Provides: cpupowerutils-devel = 1:009-0.6.p1
Obsoletes: cpupowerutils-devel < 1:009-0.6.p1
%endif
Requires: kernel-tools-libs = %{version}-%{release}
Provides: kernel-tools-devel
%description -n kernel-tools-libs-devel
This package contains the development files for the tools/ directory from
the kernel source.
%package -n kernel-tools-debuginfo
Summary: Debug information for package kernel-tools
Requires: %{name}-debuginfo-common-%{_target_cpu} = %{version}-%{release}
AutoReqProv: no
%description -n kernel-tools-debuginfo
This package provides debug information for package kernel-tools.
# Note that this pattern only works right to match the .build-id
# symlinks because of the trailing nonmatching alternation and
# the leading .*, because of find-debuginfo.sh's buggy handling
# of matching the pattern against the symlinks file.
%{expand:%%global _find_debuginfo_opts %{?_find_debuginfo_opts} -p '.*%%{_bindir}/bootconfig(\.debug)?|.*%%{_bindir}/centrino-decode(\.debug)?|.*%%{_bindir}/powernow-k8-decode(\.debug)?|.*%%{_bindir}/cpupower(\.debug)?|.*%%{_libdir}/libcpupower.*|.*%%{_bindir}/turbostat(\.debug)?|.*%%{_bindir}/x86_energy_perf_policy(\.debug)?|.*%%{_bindir}/tmon(\.debug)?|.*%%{_bindir}/lsgpio(\.debug)?|.*%%{_bindir}/gpio-hammer(\.debug)?|.*%%{_bindir}/gpio-event-mon(\.debug)?|.*%%{_bindir}/gpio-watch(\.debug)?|.*%%{_bindir}/iio_event_monitor(\.debug)?|.*%%{_bindir}/iio_generic_buffer(\.debug)?|.*%%{_bindir}/lsiio(\.debug)?|.*%%{_bindir}/intel-speed-select(\.debug)?|.*%%{_bindir}/page_owner_sort(\.debug)?|.*%%{_bindir}/slabinfo(\.debug)?|.*%%{_sbindir}/intel_sdsi(\.debug)?|XXX' -o kernel-tools-debuginfo.list}
%package -n rtla
Summary: Real-Time Linux Analysis tools
Requires: libtraceevent
Requires: libtracefs
Requires: libbpf
%ifarch %{cpupowerarchs}
Requires: kernel-tools-libs = %{version}-%{release}
%endif
%description -n rtla
The rtla meta-tool includes a set of commands that aims to analyze
the real-time properties of Linux. Instead of testing Linux as a black box,
rtla leverages kernel tracing capabilities to provide precise information
about the properties and root causes of unexpected results.
%package -n rv
Summary: RV: Runtime Verification
%description -n rv
Runtime Verification (RV) is a lightweight (yet rigorous) method that
complements classical exhaustive verification techniques (such as model
checking and theorem proving) with a more practical approach for
complex systems.
The rv tool is the interface for a collection of monitors that aim
analysing the logical and timing behavior of Linux.
# with_tools
%endif
%if %{with_selftests}
%package selftests-internal
Summary: Kernel samples and selftests
Requires: binutils, bpftool, iproute-tc, nmap-ncat, python3, fuse-libs, keyutils
%description selftests-internal
Kernel sample programs and selftests.
# Note that this pattern only works right to match the .build-id
# symlinks because of the trailing nonmatching alternation and
# the leading .*, because of find-debuginfo.sh's buggy handling
# of matching the pattern against the symlinks file.
%{expand:%%global _find_debuginfo_opts %{?_find_debuginfo_opts} -p '.*%%{_libexecdir}/(ksamples|kselftests)/.*|XXX' -o selftests-debuginfo.list}
%define __requires_exclude ^liburandom_read.so.*$
# with_selftests
%endif
%define kernel_gcov_package() \
%package %{?1:%{1}-}gcov\
Summary: gcov graph and source files for coverage data collection.\
%description %{?1:%{1}-}gcov\
%{?1:%{1}-}gcov includes the gcov graph and source files for gcov coverage collection.\
%{nil}
%package -n kernel-abi-stablelists
Summary: The Red Hat Enterprise Linux kernel ABI symbol stablelists
AutoReqProv: no
%description -n kernel-abi-stablelists
The kABI package contains information pertaining to the Red Hat Enterprise
Linux kernel ABI, including lists of kernel symbols that are needed by
external Linux kernel modules, and a yum plugin to aid enforcement.
%if %{with_kabidw_base}
%package kernel-kabidw-base-internal
Summary: The baseline dataset for kABI verification using DWARF data
Group: System Environment/Kernel
AutoReqProv: no
%description kernel-kabidw-base-internal
The package contains data describing the current ABI of the Red Hat Enterprise
Linux kernel, suitable for the kabi-dw tool.
%endif
#
# This macro creates a kernel-<subpackage>-debuginfo package.
# %%kernel_debuginfo_package <subpackage>
#
# Explanation of the find_debuginfo_opts: We build multiple kernels (debug
# pae etc.) so the regex filters those kernels appropriately. We also
# have to package several binaries as part of kernel-devel but getting
# unique build-ids is tricky for these userspace binaries. We don't really
# care about debugging those so we just filter those out and remove it.
%define kernel_debuginfo_package() \
%package %{?1:%{1}-}debuginfo\
Summary: Debug information for package %{name}%{?1:-%{1}}\
Requires: %{name}-debuginfo-common-%{_target_cpu} = %{version}-%{release}\
Provides: %{name}%{?1:-%{1}}-debuginfo-%{_target_cpu} = %{version}-%{release}\
Provides: installonlypkg(kernel)\
AutoReqProv: no\
%description %{?1:%{1}-}debuginfo\
This package provides debug information for package %{name}%{?1:-%{1}}.\
This is required to use SystemTap with %{name}%{?1:-%{1}}-%{KVERREL}.\
%{expand:%%global _find_debuginfo_opts %{?_find_debuginfo_opts} --keep-section '.BTF' -p '.*\/usr\/src\/kernels/.*|XXX' -o ignored-debuginfo.list -p '/.*/%%{KVERREL_RE}%{?1:[+]%{1}}/.*|/.*%%{KVERREL_RE}%{?1:\+%{1}}(\.debug)?' -o debuginfo%{?1}.list}\
%{nil}
#
# This macro creates a kernel-<subpackage>-devel package.
# %%kernel_devel_package [-m] <subpackage> <pretty-name>
#
%define kernel_devel_package(m) \
%package %{?1:%{1}-}devel\
Summary: Development package for building kernel modules to match the %{?2:%{2} }kernel\
Provides: kernel%{?1:-%{1}}-devel-%{_target_cpu} = %{version}-%{release}\
Provides: kernel-devel-%{_target_cpu} = %{version}-%{release}%{uname_suffix %{?1:%{1}}}\
Provides: kernel-devel-uname-r = %{KVERREL}%{uname_suffix %{?1:%{1}}}\
Provides: installonlypkg(kernel)\
AutoReqProv: no\
Requires(pre): findutils\
Requires: findutils\
Requires: perl-interpreter\
Requires: openssl-devel\
Requires: elfutils-libelf-devel\
Requires: bison\
Requires: flex\
Requires: make\
Requires: gcc\
%if %{-m:1}%{!-m:0}\
Requires: kernel-devel-uname-r = %{KVERREL}%{uname_variant %{?1:%{1}}}\
%endif\
%description %{?1:%{1}-}devel\
This package provides kernel headers and makefiles sufficient to build modules\
against the %{?2:%{2} }kernel package.\
%{nil}
#
# This macro creates an empty kernel-<subpackage>-devel-matched package that
# requires both the core and devel packages locked on the same version.
# %%kernel_devel_matched_package [-m] <subpackage> <pretty-name>
#
%define kernel_devel_matched_package(m) \
%package %{?1:%{1}-}devel-matched\
Summary: Meta package to install matching core and devel packages for a given %{?2:%{2} }kernel\
Requires: kernel%{?1:-%{1}}-devel = %{version}-%{release}\
Requires: kernel%{?1:-%{1}}-core = %{version}-%{release}\
%description %{?1:%{1}-}devel-matched\
This meta package is used to install matching core and devel packages for a given %{?2:%{2} }kernel.\
%{nil}
#
# kernel-<variant>-ipaclones-internal package
#
%define kernel_ipaclones_package() \
%package %{?1:%{1}-}ipaclones-internal\
Summary: *.ipa-clones files generated by -fdump-ipa-clones for kernel%{?1:-%{1}}\
Group: System Environment/Kernel\
AutoReqProv: no\
%description %{?1:%{1}-}ipaclones-internal\
This package provides *.ipa-clones files.\
%{nil}
#
# This macro creates a kernel-<subpackage>-modules-internal package.
# %%kernel_modules_internal_package <subpackage> <pretty-name>
#
%define kernel_modules_internal_package() \
%package %{?1:%{1}-}modules-internal\
Summary: Extra kernel modules to match the %{?2:%{2} }kernel\
Group: System Environment/Kernel\
Provides: kernel%{?1:-%{1}}-modules-internal-%{_target_cpu} = %{version}-%{release}\
Provides: kernel%{?1:-%{1}}-modules-internal-%{_target_cpu} = %{version}-%{release}%{uname_suffix %{?1:%{1}}}\
Provides: kernel%{?1:-%{1}}-modules-internal = %{version}-%{release}%{uname_suffix %{?1:%{1}}}\
Provides: installonlypkg(kernel-module)\
Provides: kernel%{?1:-%{1}}-modules-internal-uname-r = %{KVERREL}%{uname_suffix %{?1:%{1}}}\
Requires: kernel-uname-r = %{KVERREL}%{uname_suffix %{?1:%{1}}}\
Requires: kernel%{?1:-%{1}}-modules-uname-r = %{KVERREL}%{uname_suffix %{?1:%{1}}}\
Requires: kernel%{?1:-%{1}}-modules-core-uname-r = %{KVERREL}%{uname_suffix %{?1:%{1}}}\
AutoReq: no\
AutoProv: yes\
%description %{?1:%{1}-}modules-internal\
This package provides kernel modules for the %{?2:%{2} }kernel package for Red Hat internal usage.\
%{nil}
#
# This macro creates a kernel-<subpackage>-modules-extra package.
# %%kernel_modules_extra_package [-m] <subpackage> <pretty-name>
#
%define kernel_modules_extra_package(m) \
%package %{?1:%{1}-}modules-extra\
Summary: Extra kernel modules to match the %{?2:%{2} }kernel\
Provides: kernel%{?1:-%{1}}-modules-extra-%{_target_cpu} = %{version}-%{release}\
Provides: kernel%{?1:-%{1}}-modules-extra-%{_target_cpu} = %{version}-%{release}%{uname_suffix %{?1:%{1}}}\
Provides: kernel%{?1:-%{1}}-modules-extra = %{version}-%{release}%{uname_suffix %{?1:%{1}}}\
Provides: installonlypkg(kernel-module)\
Provides: kernel%{?1:-%{1}}-modules-extra-uname-r = %{KVERREL}%{uname_suffix %{?1:%{1}}}\
Requires: kernel-uname-r = %{KVERREL}%{uname_suffix %{?1:%{1}}}\
Requires: kernel%{?1:-%{1}}-modules-uname-r = %{KVERREL}%{uname_suffix %{?1:%{1}}}\
Requires: kernel%{?1:-%{1}}-modules-core-uname-r = %{KVERREL}%{uname_suffix %{?1:%{1}}}\
%if %{-m:1}%{!-m:0}\
Requires: kernel-modules-extra-uname-r = %{KVERREL}%{uname_variant %{?1:%{1}}}\
%endif\
AutoReq: no\
AutoProv: yes\
%description %{?1:%{1}-}modules-extra\
This package provides less commonly used kernel modules for the %{?2:%{2} }kernel package.\
%{nil}
#
# This macro creates a kernel-<subpackage>-modules package.
# %%kernel_modules_package [-m] <subpackage> <pretty-name>
#
%define kernel_modules_package(m) \
%package %{?1:%{1}-}modules\
Summary: kernel modules to match the %{?2:%{2}-}core kernel\
Provides: kernel%{?1:-%{1}}-modules-%{_target_cpu} = %{version}-%{release}\
Provides: kernel-modules-%{_target_cpu} = %{version}-%{release}%{uname_suffix %{?1:%{1}}}\
Provides: kernel-modules = %{version}-%{release}%{uname_suffix %{?1:%{1}}}\
Provides: installonlypkg(kernel-module)\
Provides: kernel%{?1:-%{1}}-modules-uname-r = %{KVERREL}%{uname_suffix %{?1:%{1}}}\
Requires: kernel-uname-r = %{KVERREL}%{uname_suffix %{?1:%{1}}}\
Requires: kernel%{?1:-%{1}}-modules-core-uname-r = %{KVERREL}%{uname_suffix %{?1:%{1}}}\
%if %{-m:1}%{!-m:0}\
Requires: kernel-modules-uname-r = %{KVERREL}%{uname_variant %{?1:%{1}}}\
%endif\
AutoReq: no\
AutoProv: yes\
%description %{?1:%{1}-}modules\
This package provides commonly used kernel modules for the %{?2:%{2}-}core kernel package.\
%{nil}
#
# This macro creates a kernel-<subpackage>-modules-core package.
# %%kernel_modules_core_package [-m] <subpackage> <pretty-name>
#
%define kernel_modules_core_package(m) \
%package %{?1:%{1}-}modules-core\
Summary: Core kernel modules to match the %{?2:%{2}-}core kernel\
Provides: kernel%{?1:-%{1}}-modules-core-%{_target_cpu} = %{version}-%{release}\
Provides: kernel-modules-core-%{_target_cpu} = %{version}-%{release}%{uname_suffix %{?1:%{1}}}\
Provides: kernel-modules-core = %{version}-%{release}%{uname_suffix %{?1:%{1}}}\
Provides: installonlypkg(kernel-module)\
Provides: kernel%{?1:-%{1}}-modules-core-uname-r = %{KVERREL}%{uname_suffix %{?1:%{1}}}\
Requires: kernel-uname-r = %{KVERREL}%{uname_suffix %{?1:%{1}}}\
%if %{-m:1}%{!-m:0}\
Requires: kernel-modules-core-uname-r = %{KVERREL}%{uname_variant %{?1:%{1}}}\
%endif\
AutoReq: no\
AutoProv: yes\
%description %{?1:%{1}-}modules-core\
This package provides essential kernel modules for the %{?2:%{2}-}core kernel package.\
%{nil}
#
# this macro creates a kernel-<subpackage> meta package.
# %%kernel_meta_package <subpackage>
#
%define kernel_meta_package() \
%package %{1}\
summary: kernel meta-package for the %{1} kernel\
Requires: kernel-%{1}-core-uname-r = %{KVERREL}%{uname_suffix %{1}}\
Requires: kernel-%{1}-modules-uname-r = %{KVERREL}%{uname_suffix %{1}}\
Requires: kernel-%{1}-modules-core-uname-r = %{KVERREL}%{uname_suffix %{1}}\
%if "%{1}" == "rt" || "%{1}" == "rt-debug" || "%{1}" == "rt-64k" || "%{1}" == "rt-64k-debug"\
Requires: realtime-setup\
%endif\
Provides: installonlypkg(kernel)\
%description %{1}\
The meta-package for the %{1} kernel\
%{nil}
#
# This macro creates a kernel-<subpackage> and its -devel and -debuginfo too.
# %%define variant_summary The Linux kernel compiled for <configuration>
redhat: make kernel-zfcpdump-core to not provide kernel-core/kernel Bugzilla: INTERNAL Upstream Status: RHEL only, https://gitlab.com/cki-project/kernel-ark commit 97717f4f4aaa7ae6c85c3e326e8a180738ee1bcc Author: Herton R. Krzesinski <herton@redhat.com> Date: Fri Jul 15 14:04:36 2022 -0300 redhat: make kernel-zfcpdump-core to not provide kernel-core/kernel Upstream Status: RHEL only As reported on bug 2027654*, when doing dnf install kernel on s390x it might pull kernel-zfcpdump-core which should not be a choice for a generic kernel. Adjust the kernel_variant_package macro to add an option allowing adding provides or not and use it for the zfcpdump variant. v2: - fix if condition to not hide kernel-<flavour>-core-uname-r which is required by the kernel-<flavour> meta package. - wrap kernel provides in kernel_reqprovconf macro as well - rename the macro option from -p to -o as suggested by Daniel Horak v3: - fix kernel_reqprovconf expansion as noted by Bruno Goncalves/Jan Stancek v4: - do not wrap installonlypkg since that should be only a hint to yum/dnf to allow multiple versions of same packages installed This same change was applied to centos stream 9, and is being forwarded ported now to ARK/Fedora, with a fix for the -m option of kernel_variant_package, it doesn't have an argument so ':' can't be added after it, for some reason rpm in centos didn't have issues with it, but on ARK/Fedora we get a failure. *https://bugzilla.redhat.com/show_bug.cgi?id=2027654 Signed-off-by: Herton R. Krzesinski <herton@redhat.com> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
2022-08-29 18:01:08 +00:00
# %%kernel_variant_package [-n <pretty-name>] [-m] [-o] <subpackage>
#
redhat: make kernel-zfcpdump-core to not provide kernel-core/kernel Bugzilla: INTERNAL Upstream Status: RHEL only, https://gitlab.com/cki-project/kernel-ark commit 97717f4f4aaa7ae6c85c3e326e8a180738ee1bcc Author: Herton R. Krzesinski <herton@redhat.com> Date: Fri Jul 15 14:04:36 2022 -0300 redhat: make kernel-zfcpdump-core to not provide kernel-core/kernel Upstream Status: RHEL only As reported on bug 2027654*, when doing dnf install kernel on s390x it might pull kernel-zfcpdump-core which should not be a choice for a generic kernel. Adjust the kernel_variant_package macro to add an option allowing adding provides or not and use it for the zfcpdump variant. v2: - fix if condition to not hide kernel-<flavour>-core-uname-r which is required by the kernel-<flavour> meta package. - wrap kernel provides in kernel_reqprovconf macro as well - rename the macro option from -p to -o as suggested by Daniel Horak v3: - fix kernel_reqprovconf expansion as noted by Bruno Goncalves/Jan Stancek v4: - do not wrap installonlypkg since that should be only a hint to yum/dnf to allow multiple versions of same packages installed This same change was applied to centos stream 9, and is being forwarded ported now to ARK/Fedora, with a fix for the -m option of kernel_variant_package, it doesn't have an argument so ':' can't be added after it, for some reason rpm in centos didn't have issues with it, but on ARK/Fedora we get a failure. *https://bugzilla.redhat.com/show_bug.cgi?id=2027654 Signed-off-by: Herton R. Krzesinski <herton@redhat.com> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
2022-08-29 18:01:08 +00:00
%define kernel_variant_package(n:mo) \
%package %{?1:%{1}-}core\
Summary: %{variant_summary}\
Provides: kernel-%{?1:%{1}-}core-uname-r = %{KVERREL}%{uname_suffix %{?1:%{1}}}\
Provides: installonlypkg(kernel)\
%if %{-m:1}%{!-m:0}\
Requires: kernel-core-uname-r = %{KVERREL}%{uname_variant %{?1:%{1}}}\
Requires: kernel-%{?1:%{1}-}-modules-core-uname-r = %{KVERREL}%{uname_variant %{?1:%{1}}}\
%endif\
redhat: make kernel-zfcpdump-core to not provide kernel-core/kernel Bugzilla: INTERNAL Upstream Status: RHEL only, https://gitlab.com/cki-project/kernel-ark commit 97717f4f4aaa7ae6c85c3e326e8a180738ee1bcc Author: Herton R. Krzesinski <herton@redhat.com> Date: Fri Jul 15 14:04:36 2022 -0300 redhat: make kernel-zfcpdump-core to not provide kernel-core/kernel Upstream Status: RHEL only As reported on bug 2027654*, when doing dnf install kernel on s390x it might pull kernel-zfcpdump-core which should not be a choice for a generic kernel. Adjust the kernel_variant_package macro to add an option allowing adding provides or not and use it for the zfcpdump variant. v2: - fix if condition to not hide kernel-<flavour>-core-uname-r which is required by the kernel-<flavour> meta package. - wrap kernel provides in kernel_reqprovconf macro as well - rename the macro option from -p to -o as suggested by Daniel Horak v3: - fix kernel_reqprovconf expansion as noted by Bruno Goncalves/Jan Stancek v4: - do not wrap installonlypkg since that should be only a hint to yum/dnf to allow multiple versions of same packages installed This same change was applied to centos stream 9, and is being forwarded ported now to ARK/Fedora, with a fix for the -m option of kernel_variant_package, it doesn't have an argument so ':' can't be added after it, for some reason rpm in centos didn't have issues with it, but on ARK/Fedora we get a failure. *https://bugzilla.redhat.com/show_bug.cgi?id=2027654 Signed-off-by: Herton R. Krzesinski <herton@redhat.com> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
2022-08-29 18:01:08 +00:00
%{expand:%%kernel_reqprovconf %{?1:%{1}} %{-o:%{-o}}}\
%if %{?1:1} %{!?1:0} \
%{expand:%%kernel_meta_package %{?1:%{1}}}\
%endif\
%{expand:%%kernel_devel_package %{?1:%{1}} %{!?{-n}:%{1}}%{?{-n}:%{-n*}} %{-m:%{-m}}}\
%{expand:%%kernel_devel_matched_package %{?1:%{1}} %{!?{-n}:%{1}}%{?{-n}:%{-n*}} %{-m:%{-m}}}\
%{expand:%%kernel_modules_package %{?1:%{1}} %{!?{-n}:%{1}}%{?{-n}:%{-n*}} %{-m:%{-m}}}\
%{expand:%%kernel_modules_core_package %{?1:%{1}} %{!?{-n}:%{1}}%{?{-n}:%{-n*}} %{-m:%{-m}}}\
%{expand:%%kernel_modules_extra_package %{?1:%{1}} %{!?{-n}:%{1}}%{?{-n}:%{-n*}} %{-m:%{-m}}}\
%if %{-m:0}%{!-m:1}\
%{expand:%%kernel_modules_internal_package %{?1:%{1}} %{!?{-n}:%{1}}%{?{-n}:%{-n*}}}\
%if 0%{!?fedora:1}\
%{expand:%%kernel_modules_partner_package %{?1:%{1}} %{!?{-n}:%{1}}%{?{-n}:%{-n*}}}\
%endif\
%{expand:%%kernel_debuginfo_package %{?1:%{1}}}\
%endif\
redhat: Add sub-RPM with a EFI unified kernel image for virtual machines Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2142102 Upstream Status: RHEL only The new 'kernel-unified-virt' sub-RPM is added on x86_64 targets. This contains an EFI application that provides a combined vmlinux, initrd and cmdline, as a so called 'unified kernel image'. The spec for this is defined by the boot loader specification https://uapi-group.org/specifications/specs/boot_loader_specification/ The key benefit of a unified kernel is that its secure boot signature covers the initrd and cmdline contents, allowing a trustworthy measured boot process with attestation, which is not practical with locally generated initrds/cmdlines. Since the initrd is pre-generated its contents have to be very generic, to be usable on a wide variety of deployments. To make this problem tractable, the sub-RPM targets only usage in virtual machines. With such a restriction, the initrd only needs a very small set of block driver modules present, in order to be usable across KVM, Hyper-V and Xen hypervisors which will cover essentially all common public and private clouds. Similarly the kernel cmdline cannot contain any host specific data, which means the root filesystem to mount needs to be able to be automatically detected. A virtual machine image intending to use this unified kernel package thus needs to comply with the discoverable partitions specification: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/ Based-on-patch-by: Daniel P. Berrangé <berrange@redhat.com> Based-on-patch-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
2022-11-07 09:21:43 +00:00
%if %{efiuki}\
%if "%{1}" != "rt" && "%{1}" != "rt-debug" && "%{1}" != "rt-64k" && "%{1}" != "rt-64k-debug"\
redhat: Add sub-RPM with a EFI unified kernel image for virtual machines Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2142102 Upstream Status: RHEL only The new 'kernel-unified-virt' sub-RPM is added on x86_64 targets. This contains an EFI application that provides a combined vmlinux, initrd and cmdline, as a so called 'unified kernel image'. The spec for this is defined by the boot loader specification https://uapi-group.org/specifications/specs/boot_loader_specification/ The key benefit of a unified kernel is that its secure boot signature covers the initrd and cmdline contents, allowing a trustworthy measured boot process with attestation, which is not practical with locally generated initrds/cmdlines. Since the initrd is pre-generated its contents have to be very generic, to be usable on a wide variety of deployments. To make this problem tractable, the sub-RPM targets only usage in virtual machines. With such a restriction, the initrd only needs a very small set of block driver modules present, in order to be usable across KVM, Hyper-V and Xen hypervisors which will cover essentially all common public and private clouds. Similarly the kernel cmdline cannot contain any host specific data, which means the root filesystem to mount needs to be able to be automatically detected. A virtual machine image intending to use this unified kernel package thus needs to comply with the discoverable partitions specification: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/ Based-on-patch-by: Daniel P. Berrangé <berrange@redhat.com> Based-on-patch-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
2022-11-07 09:21:43 +00:00
%package %{?1:%{1}-}uki-virt\
Summary: %{variant_summary} unified kernel image for virtual machines\
Provides: installonlypkg(kernel)\
Provides: kernel-uname-r = %{KVERREL}%{uname_suffix %{?1:%{1}}}\
redhat: Add sub-RPM with a EFI unified kernel image for virtual machines Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2142102 Upstream Status: RHEL only The new 'kernel-unified-virt' sub-RPM is added on x86_64 targets. This contains an EFI application that provides a combined vmlinux, initrd and cmdline, as a so called 'unified kernel image'. The spec for this is defined by the boot loader specification https://uapi-group.org/specifications/specs/boot_loader_specification/ The key benefit of a unified kernel is that its secure boot signature covers the initrd and cmdline contents, allowing a trustworthy measured boot process with attestation, which is not practical with locally generated initrds/cmdlines. Since the initrd is pre-generated its contents have to be very generic, to be usable on a wide variety of deployments. To make this problem tractable, the sub-RPM targets only usage in virtual machines. With such a restriction, the initrd only needs a very small set of block driver modules present, in order to be usable across KVM, Hyper-V and Xen hypervisors which will cover essentially all common public and private clouds. Similarly the kernel cmdline cannot contain any host specific data, which means the root filesystem to mount needs to be able to be automatically detected. A virtual machine image intending to use this unified kernel package thus needs to comply with the discoverable partitions specification: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/ Based-on-patch-by: Daniel P. Berrangé <berrange@redhat.com> Based-on-patch-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
2022-11-07 09:21:43 +00:00
Requires: kernel%{?1:-%{1}}-modules-core-uname-r = %{KVERREL}%{uname_suffix %{?1:%{1}}}\
Requires(pre): %{kernel_prereq}\
Requires(pre): systemd >= 252-20\
%package %{?1:%{1}-}uki-virt-addons\
Summary: %{variant_summary} unified kernel image addons for virtual machines\
Provides: installonlypkg(kernel)\
Requires: kernel%{?1:-%{1}}-uki-virt = %{version}-%{release}\
Requires(pre): systemd >= 252-20\
redhat: Add sub-RPM with a EFI unified kernel image for virtual machines Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2142102 Upstream Status: RHEL only The new 'kernel-unified-virt' sub-RPM is added on x86_64 targets. This contains an EFI application that provides a combined vmlinux, initrd and cmdline, as a so called 'unified kernel image'. The spec for this is defined by the boot loader specification https://uapi-group.org/specifications/specs/boot_loader_specification/ The key benefit of a unified kernel is that its secure boot signature covers the initrd and cmdline contents, allowing a trustworthy measured boot process with attestation, which is not practical with locally generated initrds/cmdlines. Since the initrd is pre-generated its contents have to be very generic, to be usable on a wide variety of deployments. To make this problem tractable, the sub-RPM targets only usage in virtual machines. With such a restriction, the initrd only needs a very small set of block driver modules present, in order to be usable across KVM, Hyper-V and Xen hypervisors which will cover essentially all common public and private clouds. Similarly the kernel cmdline cannot contain any host specific data, which means the root filesystem to mount needs to be able to be automatically detected. A virtual machine image intending to use this unified kernel package thus needs to comply with the discoverable partitions specification: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/ Based-on-patch-by: Daniel P. Berrangé <berrange@redhat.com> Based-on-patch-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
2022-11-07 09:21:43 +00:00
%endif\
%endif\
%if %{with_gcov}\
%{expand:%%kernel_gcov_package %{?1:%{1}}}\
%endif\
%{nil}
#
# This macro creates a kernel-<subpackage>-modules-partner package.
# %%kernel_modules_partner_package <subpackage> <pretty-name>
#
%define kernel_modules_partner_package() \
%package %{?1:%{1}-}modules-partner\
Summary: Extra kernel modules to match the %{?2:%{2} }kernel\
Group: System Environment/Kernel\
Provides: kernel%{?1:-%{1}}-modules-partner-%{_target_cpu} = %{version}-%{release}\
Provides: kernel%{?1:-%{1}}-modules-partner-%{_target_cpu} = %{version}-%{release}%{uname_suffix %{?1:%{1}}}\
Provides: kernel%{?1:-%{1}}-modules-partner = %{version}-%{release}%{uname_suffix %{?1:%{1}}}\
Provides: installonlypkg(kernel-module)\
Provides: kernel%{?1:-%{1}}-modules-partner-uname-r = %{KVERREL}%{uname_suffix %{?1:%{1}}}\
Requires: kernel-uname-r = %{KVERREL}%{uname_suffix %{?1:%{1}}}\
Requires: kernel%{?1:-%{1}}-modules-uname-r = %{KVERREL}%{uname_suffix %{?1:%{1}}}\
AutoReq: no\
AutoProv: yes\
%description %{?1:%{1}-}modules-partner\
This package provides kernel modules for the %{?2:%{2} }kernel package for Red Hat partners usage.\
%{nil}
# Now, each variant package.
%if %{with_pae}
%define variant_summary The Linux kernel compiled for Cortex-A15
%kernel_variant_package lpae
%description lpae-core
This package includes a version of the Linux kernel with support for
Cortex-A15 devices with LPAE and HW virtualisation support
%endif
%if %{with_zfcpdump}
%define variant_summary The Linux kernel compiled for zfcpdump usage
redhat: make kernel-zfcpdump-core to not provide kernel-core/kernel Bugzilla: INTERNAL Upstream Status: RHEL only, https://gitlab.com/cki-project/kernel-ark commit 97717f4f4aaa7ae6c85c3e326e8a180738ee1bcc Author: Herton R. Krzesinski <herton@redhat.com> Date: Fri Jul 15 14:04:36 2022 -0300 redhat: make kernel-zfcpdump-core to not provide kernel-core/kernel Upstream Status: RHEL only As reported on bug 2027654*, when doing dnf install kernel on s390x it might pull kernel-zfcpdump-core which should not be a choice for a generic kernel. Adjust the kernel_variant_package macro to add an option allowing adding provides or not and use it for the zfcpdump variant. v2: - fix if condition to not hide kernel-<flavour>-core-uname-r which is required by the kernel-<flavour> meta package. - wrap kernel provides in kernel_reqprovconf macro as well - rename the macro option from -p to -o as suggested by Daniel Horak v3: - fix kernel_reqprovconf expansion as noted by Bruno Goncalves/Jan Stancek v4: - do not wrap installonlypkg since that should be only a hint to yum/dnf to allow multiple versions of same packages installed This same change was applied to centos stream 9, and is being forwarded ported now to ARK/Fedora, with a fix for the -m option of kernel_variant_package, it doesn't have an argument so ':' can't be added after it, for some reason rpm in centos didn't have issues with it, but on ARK/Fedora we get a failure. *https://bugzilla.redhat.com/show_bug.cgi?id=2027654 Signed-off-by: Herton R. Krzesinski <herton@redhat.com> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
2022-08-29 18:01:08 +00:00
%kernel_variant_package -o zfcpdump
%description zfcpdump-core
The kernel package contains the Linux kernel (vmlinuz) for use by the
zfcpdump infrastructure.
# with_zfcpdump
%endif
%if %{with_arm64_64k}
%define variant_summary The Linux kernel compiled for 64k pagesize usage
%kernel_variant_package 64k
%description 64k-core
The kernel package contains a variant of the ARM64 Linux kernel using
a 64K page size.
%endif
%if %{with_arm64_64k} && %{with_debug}
%define variant_summary The Linux kernel compiled with extra debugging enabled
%if !%{debugbuildsenabled}
%kernel_variant_package -m 64k-debug
%else
%kernel_variant_package 64k-debug
%endif
%description 64k-debug-core
The debug kernel package contains a variant of the ARM64 Linux kernel using
a 64K page size.
This variant of the kernel has numerous debugging options enabled.
It should only be installed when trying to gather additional information
on kernel bugs, as some of these options impact performance noticably.
%endif
%if %{with_realtime}
%define variant_summary The Linux kernel compiled with PREEMPT_RT enabled
%kernel_variant_package rt
%description rt-core
This package includes a version of the Linux kernel compiled with PREEMPT_RT
(real-time preemption support).
%endif
%if %{with_debug} && %{with_realtime}
%define variant_summary The Linux kernel compiled with PREEMPT_RT enabled
%kernel_variant_package rt-debug
%description rt-debug-core
This package includes a version of the Linux kernel compiled with PREEMPT_RT
(real-time preemption support) and has numerous debugging options enabled.
It should only be installed when trying to gather additional information
on kernel bugs, as some of these options impact performance noticably.
%endif
%if %{with_realtime_arm64_64k}
%define variant_summary The Linux kernel compiled with PREEMPT_RT enabled and for 64k pagesize usage
%kernel_variant_package rt-64k
%description rt-64k-core
The kernel package contains a variant of the ARM64 Linux kernel with PREEMPT_RT
enabled and using a 64K page size.
%endif
%if %{with_realtime_arm64_64k} && %{with_debug}
%define variant_summary The Linux PREEMPT_RT kernel compiled with extra debugging enabled
%if !%{debugbuildsenabled}
%kernel_variant_package -m rt-64k-debug
%else
%kernel_variant_package rt-64k-debug
%endif
%description rt-64k-debug-core
The debug kernel package contains a variant of the ARM64 Linux PREEMPT_RT
kernel using a 64K page size.
This variant of the kernel has numerous debugging options enabled.
It should only be installed when trying to gather additional information
on kernel bugs, as some of these options impact performance noticably.
%endif
%if !%{debugbuildsenabled}
%kernel_variant_package -m debug
%else
%kernel_variant_package debug
%endif
%description debug-core
The kernel package contains the Linux kernel (vmlinuz), the core of any
Linux operating system. The kernel handles the basic functions
of the operating system: memory allocation, process allocation, device
input and output, etc.
This variant of the kernel has numerous debugging options enabled.
It should only be installed when trying to gather additional information
on kernel bugs, as some of these options impact performance noticably.
# And finally the main -core package
%define variant_summary The Linux kernel
%kernel_variant_package
%description core
The kernel package contains the Linux kernel (vmlinuz), the core of any
Linux operating system. The kernel handles the basic functions
of the operating system: memory allocation, process allocation, device
input and output, etc.
redhat: Add sub-RPM with a EFI unified kernel image for virtual machines Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2142102 Upstream Status: RHEL only The new 'kernel-unified-virt' sub-RPM is added on x86_64 targets. This contains an EFI application that provides a combined vmlinux, initrd and cmdline, as a so called 'unified kernel image'. The spec for this is defined by the boot loader specification https://uapi-group.org/specifications/specs/boot_loader_specification/ The key benefit of a unified kernel is that its secure boot signature covers the initrd and cmdline contents, allowing a trustworthy measured boot process with attestation, which is not practical with locally generated initrds/cmdlines. Since the initrd is pre-generated its contents have to be very generic, to be usable on a wide variety of deployments. To make this problem tractable, the sub-RPM targets only usage in virtual machines. With such a restriction, the initrd only needs a very small set of block driver modules present, in order to be usable across KVM, Hyper-V and Xen hypervisors which will cover essentially all common public and private clouds. Similarly the kernel cmdline cannot contain any host specific data, which means the root filesystem to mount needs to be able to be automatically detected. A virtual machine image intending to use this unified kernel package thus needs to comply with the discoverable partitions specification: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/ Based-on-patch-by: Daniel P. Berrangé <berrange@redhat.com> Based-on-patch-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
2022-11-07 09:21:43 +00:00
%if %{efiuki}
%description debug-uki-virt
Prebuilt debug unified kernel image for virtual machines.
%description debug-uki-virt-addons
Prebuilt debug unified kernel image addons for virtual machines.
redhat: Add sub-RPM with a EFI unified kernel image for virtual machines Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2142102 Upstream Status: RHEL only The new 'kernel-unified-virt' sub-RPM is added on x86_64 targets. This contains an EFI application that provides a combined vmlinux, initrd and cmdline, as a so called 'unified kernel image'. The spec for this is defined by the boot loader specification https://uapi-group.org/specifications/specs/boot_loader_specification/ The key benefit of a unified kernel is that its secure boot signature covers the initrd and cmdline contents, allowing a trustworthy measured boot process with attestation, which is not practical with locally generated initrds/cmdlines. Since the initrd is pre-generated its contents have to be very generic, to be usable on a wide variety of deployments. To make this problem tractable, the sub-RPM targets only usage in virtual machines. With such a restriction, the initrd only needs a very small set of block driver modules present, in order to be usable across KVM, Hyper-V and Xen hypervisors which will cover essentially all common public and private clouds. Similarly the kernel cmdline cannot contain any host specific data, which means the root filesystem to mount needs to be able to be automatically detected. A virtual machine image intending to use this unified kernel package thus needs to comply with the discoverable partitions specification: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/ Based-on-patch-by: Daniel P. Berrangé <berrange@redhat.com> Based-on-patch-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
2022-11-07 09:21:43 +00:00
%description uki-virt
Prebuilt default unified kernel image for virtual machines.
%description uki-virt-addons
Prebuilt default unified kernel image addons for virtual machines.
redhat: Add sub-RPM with a EFI unified kernel image for virtual machines Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2142102 Upstream Status: RHEL only The new 'kernel-unified-virt' sub-RPM is added on x86_64 targets. This contains an EFI application that provides a combined vmlinux, initrd and cmdline, as a so called 'unified kernel image'. The spec for this is defined by the boot loader specification https://uapi-group.org/specifications/specs/boot_loader_specification/ The key benefit of a unified kernel is that its secure boot signature covers the initrd and cmdline contents, allowing a trustworthy measured boot process with attestation, which is not practical with locally generated initrds/cmdlines. Since the initrd is pre-generated its contents have to be very generic, to be usable on a wide variety of deployments. To make this problem tractable, the sub-RPM targets only usage in virtual machines. With such a restriction, the initrd only needs a very small set of block driver modules present, in order to be usable across KVM, Hyper-V and Xen hypervisors which will cover essentially all common public and private clouds. Similarly the kernel cmdline cannot contain any host specific data, which means the root filesystem to mount needs to be able to be automatically detected. A virtual machine image intending to use this unified kernel package thus needs to comply with the discoverable partitions specification: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/ Based-on-patch-by: Daniel P. Berrangé <berrange@redhat.com> Based-on-patch-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
2022-11-07 09:21:43 +00:00
%endif
%if %{with_ipaclones}
%kernel_ipaclones_package
%endif
%prep
# do a few sanity-checks for --with *only builds
%if %{with_baseonly}
%if !%{with_up}
echo "Cannot build --with baseonly, up build is disabled"
exit 1
%endif
%endif
# more sanity checking; do it quietly
if [ "%{patches}" != "%%{patches}" ] ; then
for patch in %{patches} ; do
if [ ! -f $patch ] ; then
echo "ERROR: Patch ${patch##/*/} listed in specfile but is missing"
exit 1
fi
done
fi 2>/dev/null
patch_command='git apply'
ApplyPatch()
{
local patch=$1
shift
if [ ! -f $RPM_SOURCE_DIR/$patch ]; then
exit 1
fi
if ! grep -E "^Patch[0-9]+: $patch\$" %{_specdir}/${RPM_PACKAGE_NAME}.spec ; then
if [ "${patch:0:8}" != "patch-%{kversion}." ] ; then
echo "ERROR: Patch $patch not listed as a source patch in specfile"
exit 1
fi
fi 2>/dev/null
case "$patch" in
*.bz2) bunzip2 < "$RPM_SOURCE_DIR/$patch" | $patch_command ${1+"$@"} ;;
*.gz) gunzip < "$RPM_SOURCE_DIR/$patch" | $patch_command ${1+"$@"} ;;
*.xz) unxz < "$RPM_SOURCE_DIR/$patch" | $patch_command ${1+"$@"} ;;
*) $patch_command ${1+"$@"} < "$RPM_SOURCE_DIR/$patch" ;;
esac
}
# don't apply patch if it's empty
ApplyOptionalPatch()
{
local patch=$1
shift
if [ ! -f $RPM_SOURCE_DIR/$patch ]; then
exit 1
fi
local C=$(wc -l $RPM_SOURCE_DIR/$patch | awk '{print $1}')
if [ "$C" -gt 9 ]; then
ApplyPatch $patch ${1+"$@"}
fi
}
%setup -q -n kernel-%{tarfile_release} -c
mv linux-%{tarfile_release} linux-%{KVERREL}
cd linux-%{KVERREL}
cp -a %{SOURCE1} .
%if !%{nopatches}
ApplyOptionalPatch patch-%{patchversion}-redhat.patch
%endif
ApplyOptionalPatch linux-kernel-test.patch
# END OF PATCH APPLICATIONS
# Any further pre-build tree manipulations happen here.
chmod +x scripts/checkpatch.pl
mv COPYING COPYING-%{version}-%{release}
# This Prevents scripts/setlocalversion from mucking with our version numbers.
touch .scmversion
# Mangle /usr/bin/python shebangs to /usr/bin/python3
# Mangle all Python shebangs to be Python 3 explicitly
# -p preserves timestamps
# -n prevents creating ~backup files
# -i specifies the interpreter for the shebang
# This fixes errors such as
# *** ERROR: ambiguous python shebang in /usr/bin/kvm_stat: #!/usr/bin/python. Change it to python3 (or python2) explicitly.
# We patch all sources below for which we got a report/error.
pathfix.py -i "%{__python3}" -p -n \
tools/kvm/kvm_stat/kvm_stat \
scripts/show_delta \
scripts/diffconfig \
scripts/bloat-o-meter \
scripts/jobserver-exec \
tools \
Documentation \
scripts/clang-tools
# only deal with configs if we are going to build for the arch
%ifnarch %nobuildarches
if [ -L configs ]; then
rm -f configs
fi
mkdir configs
cd configs
# Drop some necessary files from the source dir into the buildroot
cp $RPM_SOURCE_DIR/kernel-*.config .
cp %{SOURCE80} .
# merge.pl
cp %{SOURCE3000} .
# kernel-local
cp %{SOURCE3001} .
FLAVOR=%{primary_target} SPECVERSION=%{version} ./generate_all_configs.sh %{debugbuildsenabled}
# Merge in any user-provided local config option changes
%ifnarch %nobuildarches
for i in %{all_arch_configs}
do
mv $i $i.tmp
./merge.pl %{SOURCE3001} $i.tmp > $i
%if %{with_gcov}
echo "Merging with gcov options"
cat %{SOURCE75}
mv $i $i.tmp
./merge.pl %{SOURCE75} $i.tmp > $i
%endif
rm $i.tmp
done
%endif
%if %{with clang_lto}
for i in *aarch64*.config *x86_64*.config; do
sed -i 's/# CONFIG_LTO_CLANG_THIN is not set/CONFIG_LTO_CLANG_THIN=y/' $i
sed -i 's/CONFIG_LTO_NONE=y/# CONFIG_LTO_NONE is not set/' $i
done
%endif
# Add DUP and kpatch certificates to system trusted keys for RHEL
%if 0%{?rhel}
%if %{signkernel}%{signmodules}
openssl x509 -inform der -in %{SOURCE100} -out rheldup3.pem
openssl x509 -inform der -in %{SOURCE101} -out rhelkpatch1.pem
openssl x509 -inform der -in %{SOURCE102} -out rhelimaca1.pem
openssl x509 -inform der -in %{SOURCE105} -out nvidiagpuoot001.pem
cat rheldup3.pem rhelkpatch1.pem rhelimaca1.pem nvidiagpuoot001.pem > ../certs/rhel.pem
redhat: switch the kernel package to use certs from system-sb-certs Bugzilla: INTERNAL Upstream Status: RHEL only commit ff5d8e5c949ed0e3468632fffa113d46ddcf8aea Author: Herton R. Krzesinski <herton@redhat.com> Date: Tue Jan 25 20:15:17 2022 -0300 redhat: switch the kernel package to use certs from system-sb-certs Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2045327 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2037084 Upstream Status: RHEL only Both redhat and centos are providing now the public certificates we use for secure boot signing through the redhat-sb-certs or centos-sb-certs packages. Those provides the system-sb-certs "virtual" package. Thus don't carry anymore the copy of the same certificates inside the kernel sources, instead switch to use the certificates provided by those packages. This will enable secure boot signing for centos too, as centos uses a different set of certificates for signing and we were not using them in the package yet. With this change, we also drop the usage of the beta certificates and the switch to the release certs: they aren't provided in the new scheme of system-sb-certs and anyway eg. grub2 isn't including/using those certs for signing. If there are still any switching of keys needed, ideally this should be done with the package providing system-sb-certs. While reviewing/doing this change, I also noted some missing signkernel macro guards were missing in the spec, which I added. Also, in the install part where we copy files to the kernel-doc package, I consolidated the logic and added missing signkernel/signmodules guards, with the existing code things would break if you disabled any of those options. v2: change pesign_name_0 for CentOS as reported by Brian Stinson Signed-off-by: Herton R. Krzesinski <herton@redhat.com> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
2022-08-29 19:46:18 +00:00
%if %{signkernel}
%ifarch s390x ppc64le
openssl x509 -inform der -in %{secureboot_ca_0} -out secureboot.pem
cat secureboot.pem >> ../certs/rhel.pem
%endif
redhat: switch the kernel package to use certs from system-sb-certs Bugzilla: INTERNAL Upstream Status: RHEL only commit ff5d8e5c949ed0e3468632fffa113d46ddcf8aea Author: Herton R. Krzesinski <herton@redhat.com> Date: Tue Jan 25 20:15:17 2022 -0300 redhat: switch the kernel package to use certs from system-sb-certs Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2045327 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2037084 Upstream Status: RHEL only Both redhat and centos are providing now the public certificates we use for secure boot signing through the redhat-sb-certs or centos-sb-certs packages. Those provides the system-sb-certs "virtual" package. Thus don't carry anymore the copy of the same certificates inside the kernel sources, instead switch to use the certificates provided by those packages. This will enable secure boot signing for centos too, as centos uses a different set of certificates for signing and we were not using them in the package yet. With this change, we also drop the usage of the beta certificates and the switch to the release certs: they aren't provided in the new scheme of system-sb-certs and anyway eg. grub2 isn't including/using those certs for signing. If there are still any switching of keys needed, ideally this should be done with the package providing system-sb-certs. While reviewing/doing this change, I also noted some missing signkernel macro guards were missing in the spec, which I added. Also, in the install part where we copy files to the kernel-doc package, I consolidated the logic and added missing signkernel/signmodules guards, with the existing code things would break if you disabled any of those options. v2: change pesign_name_0 for CentOS as reported by Brian Stinson Signed-off-by: Herton R. Krzesinski <herton@redhat.com> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
2022-08-29 19:46:18 +00:00
%endif
for i in *.config; do
sed -i 's@CONFIG_SYSTEM_TRUSTED_KEYS=""@CONFIG_SYSTEM_TRUSTED_KEYS="certs/rhel.pem"@' $i
done
%endif
%endif
# Adjust FIPS module name for RHEL
%if 0%{?rhel}
for i in *.config; do
sed -i 's/CONFIG_CRYPTO_FIPS_NAME=.*/CONFIG_CRYPTO_FIPS_NAME="Red Hat Enterprise Linux %{rhel} - Kernel Cryptographic API"/' $i
done
%endif
cp %{SOURCE81} .
OPTS=""
%if %{with_configchecks}
OPTS="$OPTS -w -n -c"
%endif
%if %{with clang_lto}
for opt in %{clang_make_opts}; do
OPTS="$OPTS -m $opt"
done
%endif
RHJOBS=$RPM_BUILD_NCPUS PACKAGE_NAME=kernel ./process_configs.sh $OPTS ${specversion}
cp %{SOURCE82} .
RPM_SOURCE_DIR=$RPM_SOURCE_DIR ./update_scripts.sh %{primary_target}
# We may want to override files from the primary target in case of building
# against a flavour of it (eg. centos not rhel), thus override it here if
# necessary
if [ "%{primary_target}" == "rhel" ]; then
%if 0%{?centos}
echo "Updating scripts/sources to centos version"
RPM_SOURCE_DIR=$RPM_SOURCE_DIR ./update_scripts.sh centos
%else
echo "Not updating scripts/sources to centos version"
%endif
fi
# end of kernel config
%endif
cd ..
# # End of Configs stuff
# get rid of unwanted files resulting from patch fuzz
find . \( -name "*.orig" -o -name "*~" \) -delete >/dev/null
# remove unnecessary SCM files
find . -name .gitignore -delete >/dev/null
cd ..
###
### build
###
%build
rm -rf %{buildroot_unstripped} || true
mkdir -p %{buildroot_unstripped}
%if %{with_sparse}
%define sparse_mflags C=1
%endif
cp_vmlinux()
{
eu-strip --remove-comment -o "$2" "$1"
}
# Note we need to disable these flags for cross builds because the flags
# from redhat-rpm-config assume that host == target so target arch
# flags cause issues with the host compiler.
%if !%{with_cross}
%define build_hostcflags %{?build_cflags}
%define build_hostldflags %{?build_ldflags}
%endif
%define make %{__make} %{?cross_opts} %{?make_opts} HOSTCFLAGS="%{?build_hostcflags}" HOSTLDFLAGS="%{?build_hostldflags}"
InitBuildVars() {
# Initialize the kernel .config file and create some variables that are
# needed for the actual build process.
Variant=$1
# Pick the right kernel config file
Config=kernel-%{version}-%{_target_cpu}${Variant:+-${Variant}}.config
DevelDir=/usr/src/kernels/%{KVERREL}${Variant:++${Variant}}
KernelVer=%{version}-%{release}.%{_target_cpu}${Variant:++${Variant}}
# make sure EXTRAVERSION says what we want it to say
# Trim the release if this is a CI build, since KERNELVERSION is limited to 64 characters
ShortRel=$(perl -e "print \"%{release}\" =~ s/\.pr\.[0-9A-Fa-f]{32}//r")
perl -p -i -e "s/^EXTRAVERSION.*/EXTRAVERSION = -${ShortRel}.%{_target_cpu}${Variant:++${Variant}}/" Makefile
# if pre-rc1 devel kernel, must fix up PATCHLEVEL for our versioning scheme
# if we are post rc1 this should match anyway so this won't matter
perl -p -i -e 's/^PATCHLEVEL.*/PATCHLEVEL = %{patchlevel}/' Makefile
%{make} %{?_smp_mflags} mrproper
cp configs/$Config .config
%if %{signkernel}%{signmodules}
cp configs/x509.genkey certs/.
%endif
Arch=`head -1 .config | cut -b 3-`
echo USING ARCH=$Arch
KCFLAGS="%{?kcflags}"
# add kpatch flags for base kernel
if [ "$Variant" == "" ]; then
KCFLAGS="$KCFLAGS %{?kpatch_kcflags}"
fi
}
BuildKernel() {
MakeTarget=$1
KernelImage=$2
DoVDSO=$3
Variant=$4
InstallName=${5:-vmlinuz}
DoModules=1
if [ "$Variant" = "zfcpdump" ]; then
DoModules=0
fi
# When the bootable image is just the ELF kernel, strip it.
# We already copy the unstripped file into the debuginfo package.
if [ "$KernelImage" = vmlinux ]; then
CopyKernel=cp_vmlinux
else
CopyKernel=cp
fi
%if %{with_gcov}
# Make build directory unique for each variant, so that gcno symlinks
# are also unique for each variant.
if [ -n "$Variant" ]; then
ln -s $(pwd) ../linux-%{KVERREL}-${Variant}
fi
echo "GCOV - continuing build in: $(pwd)"
pushd ../linux-%{KVERREL}${Variant:+-${Variant}}
pwd > ../kernel${Variant:+-${Variant}}-gcov.list
%endif
InitBuildVars $Variant
echo BUILDING A KERNEL FOR ${Variant} %{_target_cpu}...
%{make} ARCH=$Arch olddefconfig >/dev/null
# This ensures build-ids are unique to allow parallel debuginfo
perl -p -i -e "s/^CONFIG_BUILD_SALT.*/CONFIG_BUILD_SALT=\"%{KVERREL}\"/" .config
%{make} ARCH=$Arch KCFLAGS="$KCFLAGS" WITH_GCOV="%{?with_gcov}" %{?_smp_mflags} $MakeTarget %{?sparse_mflags} %{?kernel_mflags}
if [ $DoModules -eq 1 ]; then
%{make} ARCH=$Arch KCFLAGS="$KCFLAGS" WITH_GCOV="%{?with_gcov}" %{?_smp_mflags} modules %{?sparse_mflags} || exit 1
fi
mkdir -p $RPM_BUILD_ROOT/%{image_install_path}
mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer
mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer/systemtap
%if %{with_debuginfo}
mkdir -p $RPM_BUILD_ROOT%{debuginfodir}/%{image_install_path}
%endif
%ifarch %{arm} aarch64
%{make} ARCH=$Arch dtbs INSTALL_DTBS_PATH=$RPM_BUILD_ROOT/%{image_install_path}/dtb-$KernelVer
%{make} ARCH=$Arch dtbs_install INSTALL_DTBS_PATH=$RPM_BUILD_ROOT/%{image_install_path}/dtb-$KernelVer
cp -r $RPM_BUILD_ROOT/%{image_install_path}/dtb-$KernelVer $RPM_BUILD_ROOT/lib/modules/$KernelVer/dtb
find arch/$Arch/boot/dts -name '*.dtb' -type f -delete
%endif
# Start installing the results
install -m 644 .config $RPM_BUILD_ROOT/boot/config-$KernelVer
install -m 644 .config $RPM_BUILD_ROOT/lib/modules/$KernelVer/config
install -m 644 System.map $RPM_BUILD_ROOT/boot/System.map-$KernelVer
install -m 644 System.map $RPM_BUILD_ROOT/lib/modules/$KernelVer/System.map
# We estimate the size of the initramfs because rpm needs to take this size
# into consideration when performing disk space calculations. (See bz #530778)
dd if=/dev/zero of=$RPM_BUILD_ROOT/boot/initramfs-$KernelVer.img bs=1M count=20
if [ -f arch/$Arch/boot/zImage.stub ]; then
cp arch/$Arch/boot/zImage.stub $RPM_BUILD_ROOT/%{image_install_path}/zImage.stub-$KernelVer || :
cp arch/$Arch/boot/zImage.stub $RPM_BUILD_ROOT/lib/modules/$KernelVer/zImage.stub-$KernelVer || :
fi
%if %{signkernel}
if [ "$KernelImage" = vmlinux ]; then
# We can't strip and sign $KernelImage in place, because
# we need to preserve original vmlinux for debuginfo.
# Use a copy for signing.
$CopyKernel $KernelImage $KernelImage.tosign
KernelImage=$KernelImage.tosign
CopyKernel=cp
fi
# Sign the image if we're using EFI
# aarch64 kernels are gziped EFI images
KernelExtension=${KernelImage##*.}
if [ "$KernelExtension" == "gz" ]; then
SignImage=${KernelImage%.*}
else
SignImage=$KernelImage
fi
%ifarch x86_64 aarch64
%pesign -s -i $SignImage -o vmlinuz.signed -a %{secureboot_ca_0} -c %{secureboot_key_0} -n %{pesign_name_0}
%endif
%ifarch s390x ppc64le
if [ -x /usr/bin/rpm-sign ]; then
rpm-sign --key "%{pesign_name_0}" --lkmsign $SignImage --output vmlinuz.signed
redhat: switch the kernel package to use certs from system-sb-certs Bugzilla: INTERNAL Upstream Status: RHEL only commit ff5d8e5c949ed0e3468632fffa113d46ddcf8aea Author: Herton R. Krzesinski <herton@redhat.com> Date: Tue Jan 25 20:15:17 2022 -0300 redhat: switch the kernel package to use certs from system-sb-certs Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2045327 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2037084 Upstream Status: RHEL only Both redhat and centos are providing now the public certificates we use for secure boot signing through the redhat-sb-certs or centos-sb-certs packages. Those provides the system-sb-certs "virtual" package. Thus don't carry anymore the copy of the same certificates inside the kernel sources, instead switch to use the certificates provided by those packages. This will enable secure boot signing for centos too, as centos uses a different set of certificates for signing and we were not using them in the package yet. With this change, we also drop the usage of the beta certificates and the switch to the release certs: they aren't provided in the new scheme of system-sb-certs and anyway eg. grub2 isn't including/using those certs for signing. If there are still any switching of keys needed, ideally this should be done with the package providing system-sb-certs. While reviewing/doing this change, I also noted some missing signkernel macro guards were missing in the spec, which I added. Also, in the install part where we copy files to the kernel-doc package, I consolidated the logic and added missing signkernel/signmodules guards, with the existing code things would break if you disabled any of those options. v2: change pesign_name_0 for CentOS as reported by Brian Stinson Signed-off-by: Herton R. Krzesinski <herton@redhat.com> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
2022-08-29 19:46:18 +00:00
elif [ "$DoModules" == "1" -a "%{signmodules}" == "1" ]; then
chmod +x scripts/sign-file
./scripts/sign-file -p sha256 certs/signing_key.pem certs/signing_key.x509 $SignImage vmlinuz.signed
else
mv $SignImage vmlinuz.signed
fi
%endif
if [ ! -s vmlinuz.signed ]; then
echo "pesigning failed"
exit 1
fi
mv vmlinuz.signed $SignImage
if [ "$KernelExtension" == "gz" ]; then
gzip -f9 $SignImage
fi
# signkernel
%endif
$CopyKernel $KernelImage \
$RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer
chmod 755 $RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer
cp $RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer $RPM_BUILD_ROOT/lib/modules/$KernelVer/$InstallName
# hmac sign the kernel for FIPS
echo "Creating hmac file: $RPM_BUILD_ROOT/%{image_install_path}/.vmlinuz-$KernelVer.hmac"
ls -l $RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer
(cd $RPM_BUILD_ROOT/%{image_install_path} && sha512hmac $InstallName-$KernelVer) > $RPM_BUILD_ROOT/%{image_install_path}/.vmlinuz-$KernelVer.hmac;
cp $RPM_BUILD_ROOT/%{image_install_path}/.vmlinuz-$KernelVer.hmac $RPM_BUILD_ROOT/lib/modules/$KernelVer/.vmlinuz.hmac
if [ $DoModules -eq 1 ]; then
# Override $(mod-fw) because we don't want it to install any firmware
# we'll get it from the linux-firmware package and we don't want conflicts
%{make} %{?_smp_mflags} ARCH=$Arch INSTALL_MOD_PATH=$RPM_BUILD_ROOT %{?_smp_mflags} modules_install KERNELRELEASE=$KernelVer mod-fw=
fi
%if %{with_gcov}
# install gcov-needed files to $BUILDROOT/$BUILD/...:
# gcov_info->filename is absolute path
# gcno references to sources can use absolute paths (e.g. in out-of-tree builds)
# sysfs symlink targets (set up at compile time) use absolute paths to BUILD dir
find . \( -name '*.gcno' -o -name '*.[chS]' \) -exec install -D '{}' "$RPM_BUILD_ROOT/$(pwd)/{}" \;
%endif
# add an a noop %%defattr statement 'cause rpm doesn't like empty file list files
echo '%%defattr(-,-,-)' > ../kernel${Variant:+-${Variant}}-ldsoconf.list
if [ $DoVDSO -ne 0 ]; then
%{make} ARCH=$Arch INSTALL_MOD_PATH=$RPM_BUILD_ROOT vdso_install KERNELRELEASE=$KernelVer
if [ -s ldconfig-kernel.conf ]; then
install -D -m 444 ldconfig-kernel.conf \
$RPM_BUILD_ROOT/etc/ld.so.conf.d/kernel-$KernelVer.conf
echo /etc/ld.so.conf.d/kernel-$KernelVer.conf >> ../kernel${Variant:+-${Variant}}-ldsoconf.list
fi
rm -rf $RPM_BUILD_ROOT/lib/modules/$KernelVer/vdso/.build-id
fi
# And save the headers/makefiles etc for building modules against
#
# This all looks scary, but the end result is supposed to be:
# * all arch relevant include/ files
# * all Makefile/Kconfig files
# * all script/ files
rm -f $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
rm -f $RPM_BUILD_ROOT/lib/modules/$KernelVer/source
mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
(cd $RPM_BUILD_ROOT/lib/modules/$KernelVer ; ln -s build source)
# dirs for additional modules per module-init-tools, kbuild/modules.txt
mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer/updates
mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer/weak-updates
# CONFIG_KERNEL_HEADER_TEST generates some extra files in the process of
# testing so just delete
find . -name *.h.s -delete
# first copy everything
cp --parents `find -type f -name "Makefile*" -o -name "Kconfig*"` $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
if [ ! -e Module.symvers ]; then
touch Module.symvers
fi
cp Module.symvers $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
cp System.map $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
if [ -s Module.markers ]; then
cp Module.markers $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
fi
# create the kABI metadata for use in packaging
# NOTENOTE: the name symvers is used by the rpm backend
# NOTENOTE: to discover and run the /usr/lib/rpm/fileattrs/kabi.attr
# NOTENOTE: script which dynamically adds exported kernel symbol
# NOTENOTE: checksums to the rpm metadata provides list.
# NOTENOTE: if you change the symvers name, update the backend too
echo "**** GENERATING kernel ABI metadata ****"
gzip -c9 < Module.symvers > $RPM_BUILD_ROOT/boot/symvers-$KernelVer.gz
cp $RPM_BUILD_ROOT/boot/symvers-$KernelVer.gz $RPM_BUILD_ROOT/lib/modules/$KernelVer/symvers.gz
%if %{with_kabichk}
echo "**** kABI checking is enabled in kernel SPEC file. ****"
chmod 0755 $RPM_SOURCE_DIR/check-kabi
if [ -e $RPM_SOURCE_DIR/Module.kabi_%{_target_cpu}$Variant ]; then
cp $RPM_SOURCE_DIR/Module.kabi_%{_target_cpu}$Variant $RPM_BUILD_ROOT/Module.kabi
$RPM_SOURCE_DIR/check-kabi -k $RPM_BUILD_ROOT/Module.kabi -s Module.symvers || exit 1
# for now, don't keep it around.
rm $RPM_BUILD_ROOT/Module.kabi
else
echo "**** NOTE: Cannot find reference Module.kabi file. ****"
fi
%endif
%if %{with_kabidupchk}
echo "**** kABI DUP checking is enabled in kernel SPEC file. ****"
if [ -e $RPM_SOURCE_DIR/Module.kabi_dup_%{_target_cpu}$Variant ]; then
cp $RPM_SOURCE_DIR/Module.kabi_dup_%{_target_cpu}$Variant $RPM_BUILD_ROOT/Module.kabi
$RPM_SOURCE_DIR/check-kabi -k $RPM_BUILD_ROOT/Module.kabi -s Module.symvers || exit 1
# for now, don't keep it around.
rm $RPM_BUILD_ROOT/Module.kabi
else
echo "**** NOTE: Cannot find DUP reference Module.kabi file. ****"
fi
%endif
%if %{with_kabidw_base}
# Don't build kabi base for debug kernels
kernel.spec: Fix error messages during build of zfcpdump kernel Backport of RHEL8 commit. - small conflict Flavour/Variant variable names. commit 1b5714ef1f57ebc640fff6b6498a92f8e60a3699 Author: Philipp Rudo <prudo@redhat.com> Date: Tue Aug 27 10:51:21 2019 -0400 [rpmspec] redhat: Fix error messages during build of zfcpdump kernel Message-id: <20190827105121.28041-1-prudo@redhat.com> Patchwork-id: 269801 O-Subject: [RHEL8.2 PATCH] [rpmspec] redhat: Fix error messages during build of zfcpdump kernel Bugzilla: 1745652 RH-Acked-by: Jarod Wilson <jarod@redhat.com> RH-Acked-by: Steve Best <sbest@redhat.com> Bugzilla: 1745652 Upstream Status: RHEL-only Build Info: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=23194083 Tested: Ran brew build and checked build.log for s390x The zfcpdump kernel variant was renamed from 'kdump' to 'zfcpdump' to prevent misconception in the transition from RHEL7 to RHEL8. When forwardporting the kabi-dw tool it was missed to adjust to the rename causing error messages during build like + '[' zfcpdump '!=' kdump ']' + mkdir -p /builddir/build/BUILDROOT/kernel-4.18.0-137.el8.rhel.8.1.0.1743504.bz.s390x/kabi-dwarf + tar xjvf /builddir/build/SOURCES/kernel-kabi-dw-4.18.0-137.tar.bz2 -C /builddir/build/BUILDROOT/kernel-4.18.0-137.el8.rhel.8.1.0.1743504.bz.s390x/kabi-dwarf base/ run_kabi-dw.sh **** Baseline dataset for kABI DWARF-BASED comparison report not found **** Fix them by adjusting to the rename. Other than the error messages no negative impact is expected. The zfcpdump kernel is not kABI protected. Fixes: cbcbf154b64a ("[redhat] kabi: integrate kabi-dw") Signed-off-by: Philipp Rudo <prudo@redhat.com> Signed-off-by: Phillip Lougher <plougher@redhat.com> Signed-off-by: Jiri Benc <jbenc@redhat.com> Signed-off-by: Jiri Olsa <jolsa@redhat.com>
2021-04-23 08:15:21 +00:00
if [ "$Variant" != "zfcpdump" -a "$Variant" != "debug" ]; then
mkdir -p $RPM_BUILD_ROOT/kabi-dwarf
tar xjvf %{SOURCE301} -C $RPM_BUILD_ROOT/kabi-dwarf
mkdir -p $RPM_BUILD_ROOT/kabi-dwarf/stablelists
tar xjvf %{SOURCE300} -C $RPM_BUILD_ROOT/kabi-dwarf/stablelists
echo "**** GENERATING DWARF-based kABI baseline dataset ****"
chmod 0755 $RPM_BUILD_ROOT/kabi-dwarf/run_kabi-dw.sh
$RPM_BUILD_ROOT/kabi-dwarf/run_kabi-dw.sh generate \
"$RPM_BUILD_ROOT/kabi-dwarf/stablelists/kabi-current/kabi_stablelist_%{_target_cpu}" \
"$(pwd)" \
"$RPM_BUILD_ROOT/kabidw-base/%{_target_cpu}${Variant:+.${Variant}}" || :
rm -rf $RPM_BUILD_ROOT/kabi-dwarf
fi
%endif
%if %{with_kabidwchk}
kernel.spec: Fix error messages during build of zfcpdump kernel Backport of RHEL8 commit. - small conflict Flavour/Variant variable names. commit 1b5714ef1f57ebc640fff6b6498a92f8e60a3699 Author: Philipp Rudo <prudo@redhat.com> Date: Tue Aug 27 10:51:21 2019 -0400 [rpmspec] redhat: Fix error messages during build of zfcpdump kernel Message-id: <20190827105121.28041-1-prudo@redhat.com> Patchwork-id: 269801 O-Subject: [RHEL8.2 PATCH] [rpmspec] redhat: Fix error messages during build of zfcpdump kernel Bugzilla: 1745652 RH-Acked-by: Jarod Wilson <jarod@redhat.com> RH-Acked-by: Steve Best <sbest@redhat.com> Bugzilla: 1745652 Upstream Status: RHEL-only Build Info: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=23194083 Tested: Ran brew build and checked build.log for s390x The zfcpdump kernel variant was renamed from 'kdump' to 'zfcpdump' to prevent misconception in the transition from RHEL7 to RHEL8. When forwardporting the kabi-dw tool it was missed to adjust to the rename causing error messages during build like + '[' zfcpdump '!=' kdump ']' + mkdir -p /builddir/build/BUILDROOT/kernel-4.18.0-137.el8.rhel.8.1.0.1743504.bz.s390x/kabi-dwarf + tar xjvf /builddir/build/SOURCES/kernel-kabi-dw-4.18.0-137.tar.bz2 -C /builddir/build/BUILDROOT/kernel-4.18.0-137.el8.rhel.8.1.0.1743504.bz.s390x/kabi-dwarf base/ run_kabi-dw.sh **** Baseline dataset for kABI DWARF-BASED comparison report not found **** Fix them by adjusting to the rename. Other than the error messages no negative impact is expected. The zfcpdump kernel is not kABI protected. Fixes: cbcbf154b64a ("[redhat] kabi: integrate kabi-dw") Signed-off-by: Philipp Rudo <prudo@redhat.com> Signed-off-by: Phillip Lougher <plougher@redhat.com> Signed-off-by: Jiri Benc <jbenc@redhat.com> Signed-off-by: Jiri Olsa <jolsa@redhat.com>
2021-04-23 08:15:21 +00:00
if [ "$Variant" != "zfcpdump" ]; then
mkdir -p $RPM_BUILD_ROOT/kabi-dwarf
tar xjvf %{SOURCE301} -C $RPM_BUILD_ROOT/kabi-dwarf
if [ -d "$RPM_BUILD_ROOT/kabi-dwarf/base/%{_target_cpu}${Variant:+.${Variant}}" ]; then
mkdir -p $RPM_BUILD_ROOT/kabi-dwarf/stablelists
tar xjvf %{SOURCE300} -C $RPM_BUILD_ROOT/kabi-dwarf/stablelists
echo "**** GENERATING DWARF-based kABI dataset ****"
chmod 0755 $RPM_BUILD_ROOT/kabi-dwarf/run_kabi-dw.sh
$RPM_BUILD_ROOT/kabi-dwarf/run_kabi-dw.sh generate \
"$RPM_BUILD_ROOT/kabi-dwarf/stablelists/kabi-current/kabi_stablelist_%{_target_cpu}" \
"$(pwd)" \
"$RPM_BUILD_ROOT/kabi-dwarf/base/%{_target_cpu}${Variant:+.${Variant}}.tmp" || :
echo "**** kABI DWARF-based comparison report ****"
$RPM_BUILD_ROOT/kabi-dwarf/run_kabi-dw.sh compare \
"$RPM_BUILD_ROOT/kabi-dwarf/base/%{_target_cpu}${Variant:+.${Variant}}" \
"$RPM_BUILD_ROOT/kabi-dwarf/base/%{_target_cpu}${Variant:+.${Variant}}.tmp" || :
echo "**** End of kABI DWARF-based comparison report ****"
else
echo "**** Baseline dataset for kABI DWARF-BASED comparison report not found ****"
fi
rm -rf $RPM_BUILD_ROOT/kabi-dwarf
fi
%endif
# then drop all but the needed Makefiles/Kconfig files
rm -rf $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/scripts
rm -rf $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/include
cp .config $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
cp -a scripts $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
rm -rf $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/scripts/tracing
rm -f $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/scripts/spdxcheck.py
%ifarch s390x
# CONFIG_EXPOLINE_EXTERN=y produces arch/s390/lib/expoline/expoline.o
# which is needed during external module build.
if [ -f arch/s390/lib/expoline/expoline.o ]; then
cp -a --parents arch/s390/lib/expoline/expoline.o $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
fi
%endif
# Files for 'make scripts' to succeed with kernel-devel.
mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/security/selinux/include
cp -a --parents security/selinux/include/classmap.h $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
cp -a --parents security/selinux/include/initial_sid_to_string.h $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/tools/include/tools
cp -a --parents tools/include/tools/be_byteshift.h $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
cp -a --parents tools/include/tools/le_byteshift.h $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
# Files for 'make prepare' to succeed with kernel-devel.
cp -a --parents tools/include/linux/compiler* $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
cp -a --parents tools/include/linux/types.h $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
cp -a --parents tools/build/Build.include $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
cp --parents tools/build/fixdep.c $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
cp --parents tools/objtool/sync-check.sh $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
cp -a --parents tools/bpf/resolve_btfids $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
cp --parents security/selinux/include/policycap_names.h $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
cp --parents security/selinux/include/policycap.h $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
cp -a --parents tools/include/asm $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
cp -a --parents tools/include/asm-generic $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
cp -a --parents tools/include/linux $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
cp -a --parents tools/include/uapi/asm $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
cp -a --parents tools/include/uapi/asm-generic $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
cp -a --parents tools/include/uapi/linux $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
cp -a --parents tools/include/vdso $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
cp --parents tools/scripts/utilities.mak $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
cp -a --parents tools/lib/subcmd $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
cp --parents tools/lib/*.c $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
cp --parents tools/objtool/*.[ch] $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
cp --parents tools/objtool/Build $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
cp --parents tools/objtool/include/objtool/*.h $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
cp -a --parents tools/lib/bpf $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
cp --parents tools/lib/bpf/Build $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
if [ -f tools/objtool/objtool ]; then
cp -a tools/objtool/objtool $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/tools/objtool/ || :
fi
if [ -f tools/objtool/fixdep ]; then
cp -a tools/objtool/fixdep $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/tools/objtool/ || :
fi
if [ -d arch/$Arch/scripts ]; then
cp -a arch/$Arch/scripts $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/arch/%{_arch} || :
fi
if [ -f arch/$Arch/*lds ]; then
cp -a arch/$Arch/*lds $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/arch/%{_arch}/ || :
fi
if [ -f arch/%{asmarch}/kernel/module.lds ]; then
cp -a --parents arch/%{asmarch}/kernel/module.lds $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/
fi
find $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/scripts \( -iname "*.o" -o -iname "*.cmd" \) -exec rm -f {} +
%ifarch ppc64le
cp -a --parents arch/powerpc/lib/crtsavres.[So] $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/
%endif
if [ -d arch/%{asmarch}/include ]; then
cp -a --parents arch/%{asmarch}/include $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/
fi
if [ -d tools/arch/%{asmarch}/include ]; then
cp -a --parents tools/arch/%{asmarch}/include $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
fi
%ifarch aarch64
# arch/arm64/include/asm/xen references arch/arm
cp -a --parents arch/arm/include/asm/xen $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/
# arch/arm64/include/asm/opcodes.h references arch/arm
cp -a --parents arch/arm/include/asm/opcodes.h $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/
%endif
# include the machine specific headers for ARM variants, if available.
%ifarch %{arm}
if [ -d arch/%{asmarch}/mach-${Variant}/include ]; then
cp -a --parents arch/%{asmarch}/mach-${Variant}/include $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/
fi
# include a few files for 'make prepare'
cp -a --parents arch/arm/tools/gen-mach-types $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/
cp -a --parents arch/arm/tools/mach-types $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/
%endif
cp -a include $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/include
# Cross-reference from include/perf/events/sof.h
cp -a sound/soc/sof/sof-audio.h $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/sound/soc/sof
%ifarch i686 x86_64
# files for 'make prepare' to succeed with kernel-devel
cp -a --parents arch/x86/entry/syscalls/syscall_32.tbl $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/
cp -a --parents arch/x86/entry/syscalls/syscall_64.tbl $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/
cp -a --parents arch/x86/tools/relocs_32.c $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/
cp -a --parents arch/x86/tools/relocs_64.c $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/
cp -a --parents arch/x86/tools/relocs.c $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/
cp -a --parents arch/x86/tools/relocs_common.c $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/
cp -a --parents arch/x86/tools/relocs.h $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/
cp -a --parents arch/x86/purgatory/purgatory.c $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/
cp -a --parents arch/x86/purgatory/stack.S $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/
cp -a --parents arch/x86/purgatory/setup-x86_64.S $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/
cp -a --parents arch/x86/purgatory/entry64.S $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/
cp -a --parents arch/x86/boot/string.h $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/
cp -a --parents arch/x86/boot/string.c $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/
cp -a --parents arch/x86/boot/ctype.h $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/
cp -a --parents scripts/syscalltbl.sh $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/
cp -a --parents scripts/syscallhdr.sh $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/
cp -a --parents tools/arch/x86/include/asm $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
cp -a --parents tools/arch/x86/include/uapi/asm $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
cp -a --parents tools/objtool/arch/x86/lib $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
cp -a --parents tools/arch/x86/lib/ $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
cp -a --parents tools/arch/x86/tools/gen-insn-attr-x86.awk $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
cp -a --parents tools/objtool/arch/x86/ $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
%endif
# Clean up intermediate tools files
find $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/tools \( -iname "*.o" -o -iname "*.cmd" \) -exec rm -f {} +
# Make sure the Makefile, version.h, and auto.conf have a matching
# timestamp so that external modules can be built
touch -r $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/Makefile \
$RPM_BUILD_ROOT/lib/modules/$KernelVer/build/include/generated/uapi/linux/version.h \
$RPM_BUILD_ROOT/lib/modules/$KernelVer/build/include/config/auto.conf
%if %{with_debuginfo}
eu-readelf -n vmlinux | grep "Build ID" | awk '{print $NF}' > vmlinux.id
cp vmlinux.id $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/vmlinux.id
#
# save the vmlinux file for kernel debugging into the kernel-debuginfo rpm
#
mkdir -p $RPM_BUILD_ROOT%{debuginfodir}/lib/modules/$KernelVer
cp vmlinux $RPM_BUILD_ROOT%{debuginfodir}/lib/modules/$KernelVer
if [ -n "%{vmlinux_decompressor}" ]; then
eu-readelf -n %{vmlinux_decompressor} | grep "Build ID" | awk '{print $NF}' > vmlinux.decompressor.id
# Without build-id the build will fail. But for s390 the build-id
# wasn't added before 5.11. In case it is missing prefer not
# packaging the debuginfo over a build failure.
if [ -s vmlinux.decompressor.id ]; then
cp vmlinux.decompressor.id $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/vmlinux.decompressor.id
cp %{vmlinux_decompressor} $RPM_BUILD_ROOT%{debuginfodir}/lib/modules/$KernelVer/vmlinux.decompressor
fi
fi
%endif
find $RPM_BUILD_ROOT/lib/modules/$KernelVer -name "*.ko" -type f >modnames
# mark modules executable so that strip-to-file can strip them
xargs --no-run-if-empty chmod u+x < modnames
# Generate a list of modules for block and networking.
grep -F /drivers/ modnames | xargs --no-run-if-empty nm -upA |
sed -n 's,^.*/\([^/]*\.ko\): *U \(.*\)$,\1 \2,p' > drivers.undef
collect_modules_list()
{
sed -r -n -e "s/^([^ ]+) \\.?($2)\$/\\1/p" drivers.undef |
LC_ALL=C sort -u > $RPM_BUILD_ROOT/lib/modules/$KernelVer/modules.$1
if [ ! -z "$3" ]; then
sed -r -e "/^($3)\$/d" -i $RPM_BUILD_ROOT/lib/modules/$KernelVer/modules.$1
fi
}
collect_modules_list networking \
'register_netdev|ieee80211_register_hw|usbnet_probe|phy_driver_register|rt(l_|2x00)(pci|usb)_probe|register_netdevice'
collect_modules_list block \
'ata_scsi_ioctl|scsi_add_host|scsi_add_host_with_dma|blk_alloc_queue|blk_init_queue|register_mtd_blktrans|scsi_esp_register|scsi_register_device_handler|blk_queue_physical_block_size' 'pktcdvd.ko|dm-mod.ko'
collect_modules_list drm \
'drm_open|drm_init'
collect_modules_list modesetting \
'drm_crtc_init'
# detect missing or incorrect license tags
( find $RPM_BUILD_ROOT/lib/modules/$KernelVer -name '*.ko' | xargs /sbin/modinfo -l | \
grep -E -v 'GPL( v2)?$|Dual BSD/GPL$|Dual MPL/GPL$|GPL and additional rights$' ) && exit 1
remove_depmod_files()
{
# remove files that will be auto generated by depmod at rpm -i time
pushd $RPM_BUILD_ROOT/lib/modules/$KernelVer/
# in case below list needs to be extended, remember to add a
# matching ghost entry in the files section as well
rm -f modules.{alias,alias.bin,builtin.alias.bin,builtin.bin} \
modules.{dep,dep.bin,devname,softdep,symbols,symbols.bin}
popd
}
remove_depmod_files
# Identify modules in the kernel-modules-extras package
%{SOURCE20} $RPM_BUILD_ROOT lib/modules/$KernelVer $(realpath configs/mod-extra.list)
# Identify modules in the kernel-modules-extras package
%{SOURCE20} $RPM_BUILD_ROOT lib/modules/$KernelVer %{SOURCE84} internal
%if 0%{!?fedora:1}
# Identify modules in the kernel-modules-partner package
%{SOURCE20} $RPM_BUILD_ROOT lib/modules/$KernelVer %{SOURCE85} partner
%endif
#
# Generate the kernel-core and kernel-modules files lists
#
# Copy the System.map file for depmod to use, and create a backup of the
# full module tree so we can restore it after we're done filtering
cp System.map $RPM_BUILD_ROOT/.
cp configs/filter-*.sh $RPM_BUILD_ROOT/.
pushd $RPM_BUILD_ROOT
mkdir restore
cp -r lib/modules/$KernelVer/* restore/.
kernel packaging: Fix extra namespace collision commit b2819ae00d4cd6380e1151dd0628f32e19a85d6f Author: Prarit Bhargava <prarit@redhat.com> Date: Fri Jun 7 18:00:37 2019 -0400 [rpmspec] kernel packaging: Fix extra namespace collision Message-id: <20190607180038.20685-4-prarit@redhat.com> Patchwork-id: 263188 O-Subject: [RHEL8.1 BZ 1699868 v4 3/4] kernel packaging: Fix extra namespace collision Bugzilla: 1699868 RH-Acked-by: Marcelo Leitner <mleitner@redhat.com> RH-Acked-by: Laura Abbott <labbott@redhat.com> Bugzilla: http://bugzilla.redhat.com/1699868 The kernel-modules-extra package collides with the 3rd party driver location, /lib/modules/'uname -r'/extra. When the kernel-modules-extra package has already been installed and a new kernel is installed, the result is a significant increase to the install time of a kernel and the wrong kernel modules being loaded into the new kernel. The /lib/modules/'uname -r'/extra directory is designated as a spot where 3rd party vendors can place their out-of-box drivers. When a new kernel is installed (specifically the kernel-core package) a call is made to /usr/sbin/weak-modules (from the kmod package) to examine drivers in the previously installed kernels' extra directories to bring those drivers forward into the new kernel. The kernel-modules-extra package installs modules into the /extra directory. As a result, when /usr/sbin/weak-modules is executed it brings the modules from kernel-modules-extra forward into the new kernel as well. This is a critical mistake as the wrong modules have now been brought forward. Additionally, /usr/sbin/weak-modules takes longer to execute every time a new kernel is installed. After five kernels are installed the time to install the kernel-core package climbs to approximately 10 minutes. After some code investigation and discussion with the authors of the original Fedora code, and input from Herton, this can be avoided by installing the kernel-modules-extra modules to their original directories in 8.0.z. The existing build process copies all the modules into a temporary area called restore, and leaving the original modules directory as a work area. The modules listed in mod-extra.list are copied to extra/ and removed from the work area, and core.list and modules.list files are created. The restore area is then copied back, and the rpm build process continues. My changes create a mod-extra.list and a mod-internal.list (similar to core.list and modules.list), and remove the files from the work area so that the core.list and modules.list can be created. The list files are used later on to create dynamic %files sections for the subpackages. Remove the /lib/modules/'uname -r'/extra installation path from the kernel-modules-extra package and install the modules in their original directories. v4: Make modules-internal.list and modules-extra.list use consistent (mleitner). Fix cat usage in spec file and scripts (jbenc). Signed-off-by: Prarit Bhargava <prarit@redhat.com> Cc: Herton R. Krzesinski <herton@redhat.com> Cc: Prarit Bhargava <prarit@redhat.com> Cc: Marcelo Leitner <mleitner@redhat.com> Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
2020-03-31 17:22:23 +00:00
# don't include anything going into kernel-modules-extra in the file lists
xargs rm -rf < mod-extra.list
# don't include anything going int kernel-modules-internal in the file lists
xargs rm -rf < mod-internal.list
%if 0%{!?fedora:1}
# don't include anything going int kernel-modules-partner in the file lists
xargs rm -rf < mod-partner.list
%endif
if [ $DoModules -eq 1 ]; then
# Find all the module files and filter them out into the core and
# modules lists. This actually removes anything going into -modules
# from the dir.
find lib/modules/$KernelVer/kernel -name *.ko | sort -n > modules.list
./filter-modules.sh modules.list %{_target_cpu}
rm filter-*.sh
# Run depmod on the resulting module tree and make sure it isn't broken
depmod -b . -aeF ./System.map $KernelVer &> depmod.out
if [ -s depmod.out ]; then
echo "Depmod failure"
cat depmod.out
exit 1
else
rm depmod.out
fi
else
# Ensure important files/directories exist to let the packaging succeed
echo '%%defattr(-,-,-)' > modules.list
echo '%%defattr(-,-,-)' > k-d.list
mkdir -p lib/modules/$KernelVer/kernel
# Add files usually created by make modules, needed to prevent errors
# thrown by depmod during package installation
touch lib/modules/$KernelVer/modules.order
touch lib/modules/$KernelVer/modules.builtin
fi
redhat: Add sub-RPM with a EFI unified kernel image for virtual machines Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2142102 Upstream Status: RHEL only The new 'kernel-unified-virt' sub-RPM is added on x86_64 targets. This contains an EFI application that provides a combined vmlinux, initrd and cmdline, as a so called 'unified kernel image'. The spec for this is defined by the boot loader specification https://uapi-group.org/specifications/specs/boot_loader_specification/ The key benefit of a unified kernel is that its secure boot signature covers the initrd and cmdline contents, allowing a trustworthy measured boot process with attestation, which is not practical with locally generated initrds/cmdlines. Since the initrd is pre-generated its contents have to be very generic, to be usable on a wide variety of deployments. To make this problem tractable, the sub-RPM targets only usage in virtual machines. With such a restriction, the initrd only needs a very small set of block driver modules present, in order to be usable across KVM, Hyper-V and Xen hypervisors which will cover essentially all common public and private clouds. Similarly the kernel cmdline cannot contain any host specific data, which means the root filesystem to mount needs to be able to be automatically detected. A virtual machine image intending to use this unified kernel package thus needs to comply with the discoverable partitions specification: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/ Based-on-patch-by: Daniel P. Berrangé <berrange@redhat.com> Based-on-patch-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
2022-11-07 09:21:43 +00:00
%if %{efiuki}
if [ "$Variant" != "rt" ] && [ "$Variant" != "rt-debug" ] && [ "$Variant" != "rt-64k" ] && [ "$Variant" != "rt-64k-debug" ]; then
popd
# RHEL/CentOS specific .SBAT entries
%if 0%{?centos}
SBATsuffix="centos"
%else
SBATsuffix="rhel"
%endif
SBAT=$(cat <<- EOF
linux,1,Red Hat,linux,$KernelVer,mailto:secalert@redhat.com
linux.$SBATsuffix,1,Red Hat,linux,$KernelVer,mailto:secalert@redhat.com
kernel-uki-virt.$SBATsuffix,1,Red Hat,kernel-uki-virt,$KernelVer,mailto:secalert@redhat.com
EOF
)
KernelUnifiedImageDir="$RPM_BUILD_ROOT/lib/modules/$KernelVer"
KernelUnifiedImage="$KernelUnifiedImageDir/$InstallName-virt.efi"
mkdir -p $KernelUnifiedImageDir
dracut --conf=%{SOURCE150} \
--confdir=$(mktemp -d) \
--verbose \
--kver "$KernelVer" \
--kmoddir "$RPM_BUILD_ROOT/lib/modules/$KernelVer/" \
--logfile=$(mktemp) \
--uefi \
--sbat "$SBAT" \
--kernel-image $(realpath $KernelImage) \
--kernel-cmdline 'console=tty0 console=ttyS0' \
$KernelUnifiedImage
redhat: Add sub-RPM with a EFI unified kernel image for virtual machines Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2142102 Upstream Status: RHEL only The new 'kernel-unified-virt' sub-RPM is added on x86_64 targets. This contains an EFI application that provides a combined vmlinux, initrd and cmdline, as a so called 'unified kernel image'. The spec for this is defined by the boot loader specification https://uapi-group.org/specifications/specs/boot_loader_specification/ The key benefit of a unified kernel is that its secure boot signature covers the initrd and cmdline contents, allowing a trustworthy measured boot process with attestation, which is not practical with locally generated initrds/cmdlines. Since the initrd is pre-generated its contents have to be very generic, to be usable on a wide variety of deployments. To make this problem tractable, the sub-RPM targets only usage in virtual machines. With such a restriction, the initrd only needs a very small set of block driver modules present, in order to be usable across KVM, Hyper-V and Xen hypervisors which will cover essentially all common public and private clouds. Similarly the kernel cmdline cannot contain any host specific data, which means the root filesystem to mount needs to be able to be automatically detected. A virtual machine image intending to use this unified kernel package thus needs to comply with the discoverable partitions specification: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/ Based-on-patch-by: Daniel P. Berrangé <berrange@redhat.com> Based-on-patch-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
2022-11-07 09:21:43 +00:00
KernelAddonsDirOut="$KernelUnifiedImage.extra.d"
mkdir -p $KernelAddonsDirOut
python3 %{SOURCE151} %{SOURCE152} $KernelAddonsDirOut virt %{primary_target} %{_target_cpu}
redhat: Add sub-RPM with a EFI unified kernel image for virtual machines Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2142102 Upstream Status: RHEL only The new 'kernel-unified-virt' sub-RPM is added on x86_64 targets. This contains an EFI application that provides a combined vmlinux, initrd and cmdline, as a so called 'unified kernel image'. The spec for this is defined by the boot loader specification https://uapi-group.org/specifications/specs/boot_loader_specification/ The key benefit of a unified kernel is that its secure boot signature covers the initrd and cmdline contents, allowing a trustworthy measured boot process with attestation, which is not practical with locally generated initrds/cmdlines. Since the initrd is pre-generated its contents have to be very generic, to be usable on a wide variety of deployments. To make this problem tractable, the sub-RPM targets only usage in virtual machines. With such a restriction, the initrd only needs a very small set of block driver modules present, in order to be usable across KVM, Hyper-V and Xen hypervisors which will cover essentially all common public and private clouds. Similarly the kernel cmdline cannot contain any host specific data, which means the root filesystem to mount needs to be able to be automatically detected. A virtual machine image intending to use this unified kernel package thus needs to comply with the discoverable partitions specification: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/ Based-on-patch-by: Daniel P. Berrangé <berrange@redhat.com> Based-on-patch-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
2022-11-07 09:21:43 +00:00
%if %{signkernel}
%if 0%{?centos}
UKI_secureboot_name=centossecureboot204
%else
UKI_secureboot_name=redhatsecureboot504
%endif
UKI_secureboot_cert=%{_datadir}/pki/sb-certs/secureboot-uki-virt-%{_arch}.cer
%pesign -s -i $KernelUnifiedImage -o $KernelUnifiedImage.signed -a %{secureboot_ca_0} -c $UKI_secureboot_cert -n $UKI_secureboot_name
if [ ! -s $KernelUnifiedImage.signed ]; then
echo "pesigning failed"
exit 1
fi
mv $KernelUnifiedImage.signed $KernelUnifiedImage
redhat: Add sub-RPM with a EFI unified kernel image for virtual machines Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2142102 Upstream Status: RHEL only The new 'kernel-unified-virt' sub-RPM is added on x86_64 targets. This contains an EFI application that provides a combined vmlinux, initrd and cmdline, as a so called 'unified kernel image'. The spec for this is defined by the boot loader specification https://uapi-group.org/specifications/specs/boot_loader_specification/ The key benefit of a unified kernel is that its secure boot signature covers the initrd and cmdline contents, allowing a trustworthy measured boot process with attestation, which is not practical with locally generated initrds/cmdlines. Since the initrd is pre-generated its contents have to be very generic, to be usable on a wide variety of deployments. To make this problem tractable, the sub-RPM targets only usage in virtual machines. With such a restriction, the initrd only needs a very small set of block driver modules present, in order to be usable across KVM, Hyper-V and Xen hypervisors which will cover essentially all common public and private clouds. Similarly the kernel cmdline cannot contain any host specific data, which means the root filesystem to mount needs to be able to be automatically detected. A virtual machine image intending to use this unified kernel package thus needs to comply with the discoverable partitions specification: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/ Based-on-patch-by: Daniel P. Berrangé <berrange@redhat.com> Based-on-patch-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
2022-11-07 09:21:43 +00:00
for addon in "$KernelAddonsDirOut"/*; do
%pesign -s -i $addon -o $addon.signed -a %{secureboot_ca_0} -c %{secureboot_key_0} -n %{pesign_name_0}
rm -f $addon
mv $addon.signed $addon
done
redhat: Add sub-RPM with a EFI unified kernel image for virtual machines Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2142102 Upstream Status: RHEL only The new 'kernel-unified-virt' sub-RPM is added on x86_64 targets. This contains an EFI application that provides a combined vmlinux, initrd and cmdline, as a so called 'unified kernel image'. The spec for this is defined by the boot loader specification https://uapi-group.org/specifications/specs/boot_loader_specification/ The key benefit of a unified kernel is that its secure boot signature covers the initrd and cmdline contents, allowing a trustworthy measured boot process with attestation, which is not practical with locally generated initrds/cmdlines. Since the initrd is pre-generated its contents have to be very generic, to be usable on a wide variety of deployments. To make this problem tractable, the sub-RPM targets only usage in virtual machines. With such a restriction, the initrd only needs a very small set of block driver modules present, in order to be usable across KVM, Hyper-V and Xen hypervisors which will cover essentially all common public and private clouds. Similarly the kernel cmdline cannot contain any host specific data, which means the root filesystem to mount needs to be able to be automatically detected. A virtual machine image intending to use this unified kernel package thus needs to comply with the discoverable partitions specification: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/ Based-on-patch-by: Daniel P. Berrangé <berrange@redhat.com> Based-on-patch-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
2022-11-07 09:21:43 +00:00
# signkernel
%endif
# hmac sign the UKI for FIPS
KernelUnifiedImageHMAC="$KernelUnifiedImageDir/.$InstallName-virt.efi.hmac"
echo "hmac sign the UKI for FIPS"
echo "Creating hmac file: $KernelUnifiedImageHMAC"
(cd $KernelUnifiedImageDir && sha512hmac $InstallName-virt.efi) > $KernelUnifiedImageHMAC;
pushd $RPM_BUILD_ROOT
redhat: Add sub-RPM with a EFI unified kernel image for virtual machines Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2142102 Upstream Status: RHEL only The new 'kernel-unified-virt' sub-RPM is added on x86_64 targets. This contains an EFI application that provides a combined vmlinux, initrd and cmdline, as a so called 'unified kernel image'. The spec for this is defined by the boot loader specification https://uapi-group.org/specifications/specs/boot_loader_specification/ The key benefit of a unified kernel is that its secure boot signature covers the initrd and cmdline contents, allowing a trustworthy measured boot process with attestation, which is not practical with locally generated initrds/cmdlines. Since the initrd is pre-generated its contents have to be very generic, to be usable on a wide variety of deployments. To make this problem tractable, the sub-RPM targets only usage in virtual machines. With such a restriction, the initrd only needs a very small set of block driver modules present, in order to be usable across KVM, Hyper-V and Xen hypervisors which will cover essentially all common public and private clouds. Similarly the kernel cmdline cannot contain any host specific data, which means the root filesystem to mount needs to be able to be automatically detected. A virtual machine image intending to use this unified kernel package thus needs to comply with the discoverable partitions specification: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/ Based-on-patch-by: Daniel P. Berrangé <berrange@redhat.com> Based-on-patch-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
2022-11-07 09:21:43 +00:00
# Variant != rt && Variant != rt-debug && Variant != rt-64k && Variant != rt-64k-debug
fi
redhat: Add sub-RPM with a EFI unified kernel image for virtual machines Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2142102 Upstream Status: RHEL only The new 'kernel-unified-virt' sub-RPM is added on x86_64 targets. This contains an EFI application that provides a combined vmlinux, initrd and cmdline, as a so called 'unified kernel image'. The spec for this is defined by the boot loader specification https://uapi-group.org/specifications/specs/boot_loader_specification/ The key benefit of a unified kernel is that its secure boot signature covers the initrd and cmdline contents, allowing a trustworthy measured boot process with attestation, which is not practical with locally generated initrds/cmdlines. Since the initrd is pre-generated its contents have to be very generic, to be usable on a wide variety of deployments. To make this problem tractable, the sub-RPM targets only usage in virtual machines. With such a restriction, the initrd only needs a very small set of block driver modules present, in order to be usable across KVM, Hyper-V and Xen hypervisors which will cover essentially all common public and private clouds. Similarly the kernel cmdline cannot contain any host specific data, which means the root filesystem to mount needs to be able to be automatically detected. A virtual machine image intending to use this unified kernel package thus needs to comply with the discoverable partitions specification: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/ Based-on-patch-by: Daniel P. Berrangé <berrange@redhat.com> Based-on-patch-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
2022-11-07 09:21:43 +00:00
# efiuki
%endif
remove_depmod_files
# Go back and find all of the various directories in the tree. We use this
# for the dir lists in kernel-core
find lib/modules/$KernelVer/kernel -mindepth 1 -type d | sort -n > module-dirs.list
# Cleanup
rm System.map
spec: speed up "cp -r" when it overwrites existing files. Bugzilla: INTERNAL Upstream Status: RHEL only, https://gitlab.com/cki-project/kernel-ark commit 5bb18adcdf9baa927725549ad904f7aac8b752c6 Author: Denys Vlasenko <dvlasenk@redhat.com> Date: Wed Jan 26 14:45:21 2022 +0100 spec: speed up "cp -r" when it overwrites existing files. On "slow" storage, this reduces "cp -r" time from 5-15 minutes to a few seconds. >> and if file exists, open(O_WRONLY|O_TRUNC). > >Great. cp uses a common unsafe overwrite anti-pattern. i.e. it can >result in an empty file (losing the old data without having any of >the new data written) if the system crashes at just the wrong time. > >As it is, open(O_WRONLY|O_TRUNC) on an existing file of 177 bytes in >length is a truncate down (same as open(O_WRONLY); ftruncate(0);), >so that would definitely cause XFS to trigger the XFS_ITRUNCATED >flush-on-close() data loss mitigation here. Why won't we just use mv instead of cp, you ask? (1) There is no "mv -r", you need to open-code the logic to recurse the directories, and move only files. And more importantly (2) renames on these filesystems also wait syncronously for metadata update to hit the storage. I tested it: (cd restore && find -type d) \ | while read -r dir; do mkdir -p "lib/modules/$KernelVer/$dir" find "restore/$dir" -maxdepth 1 -type f -exec mv -t "lib/modules/$KernelVer/$dir" '{}' '+' done It is about as slow as the "cp -r". Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
2022-08-29 17:48:43 +00:00
# Just "cp -r" can be very slow: here, it rewrites _existing files_
# with open(O_TRUNC). Many filesystems synchronously wait for metadata
# update for such file rewrites (seen in strace as final close syscall
# taking a long time). On a rotational disk, cp was observed to take
# more than 5 minutes on ext4 and more than 15 minutes (!) on xfs.
# With --remove-destination, we avoid this, and copying
# (with enough RAM to cache it) takes 5 seconds:
cp -r --remove-destination restore/* lib/modules/$KernelVer/.
rm -rf restore
popd
# Make sure the files lists start with absolute paths or rpmbuild fails.
# Also add in the dir entries
sed -e 's/^lib*/\/lib/' %{?zipsed} $RPM_BUILD_ROOT/k-d.list > ../kernel${Variant:+-${Variant}}-modules.list
sed -e 's/^lib*/%dir \/lib/' %{?zipsed} $RPM_BUILD_ROOT/module-dirs.list > ../kernel${Variant:+-${Variant}}-modules-core.list
sed -e 's/^lib*/\/lib/' %{?zipsed} $RPM_BUILD_ROOT/modules.list >> ../kernel${Variant:+-${Variant}}-modules-core.list
sed -e 's/^lib*/\/lib/' %{?zipsed} $RPM_BUILD_ROOT/mod-extra.list >> ../kernel${Variant:+-${Variant}}-modules-extra.list
# Cleanup
rm -f $RPM_BUILD_ROOT/k-d.list
rm -f $RPM_BUILD_ROOT/modules.list
rm -f $RPM_BUILD_ROOT/module-dirs.list
kernel packaging: Fix extra namespace collision commit b2819ae00d4cd6380e1151dd0628f32e19a85d6f Author: Prarit Bhargava <prarit@redhat.com> Date: Fri Jun 7 18:00:37 2019 -0400 [rpmspec] kernel packaging: Fix extra namespace collision Message-id: <20190607180038.20685-4-prarit@redhat.com> Patchwork-id: 263188 O-Subject: [RHEL8.1 BZ 1699868 v4 3/4] kernel packaging: Fix extra namespace collision Bugzilla: 1699868 RH-Acked-by: Marcelo Leitner <mleitner@redhat.com> RH-Acked-by: Laura Abbott <labbott@redhat.com> Bugzilla: http://bugzilla.redhat.com/1699868 The kernel-modules-extra package collides with the 3rd party driver location, /lib/modules/'uname -r'/extra. When the kernel-modules-extra package has already been installed and a new kernel is installed, the result is a significant increase to the install time of a kernel and the wrong kernel modules being loaded into the new kernel. The /lib/modules/'uname -r'/extra directory is designated as a spot where 3rd party vendors can place their out-of-box drivers. When a new kernel is installed (specifically the kernel-core package) a call is made to /usr/sbin/weak-modules (from the kmod package) to examine drivers in the previously installed kernels' extra directories to bring those drivers forward into the new kernel. The kernel-modules-extra package installs modules into the /extra directory. As a result, when /usr/sbin/weak-modules is executed it brings the modules from kernel-modules-extra forward into the new kernel as well. This is a critical mistake as the wrong modules have now been brought forward. Additionally, /usr/sbin/weak-modules takes longer to execute every time a new kernel is installed. After five kernels are installed the time to install the kernel-core package climbs to approximately 10 minutes. After some code investigation and discussion with the authors of the original Fedora code, and input from Herton, this can be avoided by installing the kernel-modules-extra modules to their original directories in 8.0.z. The existing build process copies all the modules into a temporary area called restore, and leaving the original modules directory as a work area. The modules listed in mod-extra.list are copied to extra/ and removed from the work area, and core.list and modules.list files are created. The restore area is then copied back, and the rpm build process continues. My changes create a mod-extra.list and a mod-internal.list (similar to core.list and modules.list), and remove the files from the work area so that the core.list and modules.list can be created. The list files are used later on to create dynamic %files sections for the subpackages. Remove the /lib/modules/'uname -r'/extra installation path from the kernel-modules-extra package and install the modules in their original directories. v4: Make modules-internal.list and modules-extra.list use consistent (mleitner). Fix cat usage in spec file and scripts (jbenc). Signed-off-by: Prarit Bhargava <prarit@redhat.com> Cc: Herton R. Krzesinski <herton@redhat.com> Cc: Prarit Bhargava <prarit@redhat.com> Cc: Marcelo Leitner <mleitner@redhat.com> Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
2020-03-31 17:22:23 +00:00
rm -f $RPM_BUILD_ROOT/mod-extra.list
rm -f $RPM_BUILD_ROOT/mod-internal.list
%if 0%{!?fedora:1}
rm -f $RPM_BUILD_ROOT/mod-partner.list
%endif
%if %{with_cross}
make -C $RPM_BUILD_ROOT/lib/modules/$KernelVer/build M=scripts clean
make -C $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/tools/bpf/resolve_btfids clean
sed -i 's/REBUILD_SCRIPTS_FOR_CROSS:=0/REBUILD_SCRIPTS_FOR_CROSS:=1/' $RPM_BUILD_ROOT/lib/modules/$KernelVer/build/Makefile
%endif
# Move the devel headers out of the root file system
mkdir -p $RPM_BUILD_ROOT/usr/src/kernels
mv $RPM_BUILD_ROOT/lib/modules/$KernelVer/build $RPM_BUILD_ROOT/$DevelDir
# This is going to create a broken link during the build, but we don't use
# it after this point. We need the link to actually point to something
# when kernel-devel is installed, and a relative link doesn't work across
# the F17 UsrMove feature.
ln -sf $DevelDir $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
%ifnarch armv7hl
# Generate vmlinux.h and put it to kernel-devel path
# zfcpdump build does not have btf anymore
if [ "$Variant" != "zfcpdump" ]; then
# Build the bootstrap bpftool to generate vmlinux.h
make -C tools/bpf/bpftool bootstrap
tools/bpf/bpftool/bootstrap/bpftool btf dump file vmlinux format c > $RPM_BUILD_ROOT/$DevelDir/vmlinux.h
fi
%endif
# prune junk from kernel-devel
find $RPM_BUILD_ROOT/usr/src/kernels -name ".*.cmd" -delete
# Red Hat UEFI Secure Boot CA cert, which can be used to authenticate the kernel
mkdir -p $RPM_BUILD_ROOT%{_datadir}/doc/kernel-keys/$KernelVer
redhat: switch the kernel package to use certs from system-sb-certs Bugzilla: INTERNAL Upstream Status: RHEL only commit ff5d8e5c949ed0e3468632fffa113d46ddcf8aea Author: Herton R. Krzesinski <herton@redhat.com> Date: Tue Jan 25 20:15:17 2022 -0300 redhat: switch the kernel package to use certs from system-sb-certs Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2045327 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2037084 Upstream Status: RHEL only Both redhat and centos are providing now the public certificates we use for secure boot signing through the redhat-sb-certs or centos-sb-certs packages. Those provides the system-sb-certs "virtual" package. Thus don't carry anymore the copy of the same certificates inside the kernel sources, instead switch to use the certificates provided by those packages. This will enable secure boot signing for centos too, as centos uses a different set of certificates for signing and we were not using them in the package yet. With this change, we also drop the usage of the beta certificates and the switch to the release certs: they aren't provided in the new scheme of system-sb-certs and anyway eg. grub2 isn't including/using those certs for signing. If there are still any switching of keys needed, ideally this should be done with the package providing system-sb-certs. While reviewing/doing this change, I also noted some missing signkernel macro guards were missing in the spec, which I added. Also, in the install part where we copy files to the kernel-doc package, I consolidated the logic and added missing signkernel/signmodules guards, with the existing code things would break if you disabled any of those options. v2: change pesign_name_0 for CentOS as reported by Brian Stinson Signed-off-by: Herton R. Krzesinski <herton@redhat.com> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
2022-08-29 19:46:18 +00:00
%if %{signkernel}
install -m 0644 %{secureboot_ca_0} $RPM_BUILD_ROOT%{_datadir}/doc/kernel-keys/$KernelVer/kernel-signing-ca.cer
%ifarch s390x ppc64le
redhat: switch the kernel package to use certs from system-sb-certs Bugzilla: INTERNAL Upstream Status: RHEL only commit ff5d8e5c949ed0e3468632fffa113d46ddcf8aea Author: Herton R. Krzesinski <herton@redhat.com> Date: Tue Jan 25 20:15:17 2022 -0300 redhat: switch the kernel package to use certs from system-sb-certs Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2045327 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2037084 Upstream Status: RHEL only Both redhat and centos are providing now the public certificates we use for secure boot signing through the redhat-sb-certs or centos-sb-certs packages. Those provides the system-sb-certs "virtual" package. Thus don't carry anymore the copy of the same certificates inside the kernel sources, instead switch to use the certificates provided by those packages. This will enable secure boot signing for centos too, as centos uses a different set of certificates for signing and we were not using them in the package yet. With this change, we also drop the usage of the beta certificates and the switch to the release certs: they aren't provided in the new scheme of system-sb-certs and anyway eg. grub2 isn't including/using those certs for signing. If there are still any switching of keys needed, ideally this should be done with the package providing system-sb-certs. While reviewing/doing this change, I also noted some missing signkernel macro guards were missing in the spec, which I added. Also, in the install part where we copy files to the kernel-doc package, I consolidated the logic and added missing signkernel/signmodules guards, with the existing code things would break if you disabled any of those options. v2: change pesign_name_0 for CentOS as reported by Brian Stinson Signed-off-by: Herton R. Krzesinski <herton@redhat.com> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
2022-08-29 19:46:18 +00:00
if [ -x /usr/bin/rpm-sign ]; then
install -m 0644 %{secureboot_key_0} $RPM_BUILD_ROOT%{_datadir}/doc/kernel-keys/$KernelVer/%{signing_key_filename}
redhat: switch the kernel package to use certs from system-sb-certs Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2045327 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2037084 Upstream Status: RHEL only Both redhat and centos are providing now the public certificates we use for secure boot signing through the redhat-sb-certs or centos-sb-certs packages. Those provides the system-sb-certs "virtual" package. Thus don't carry anymore the copy of the same certificates inside the kernel sources, instead switch to use the certificates provided by those packages. This will enable secure boot signing for centos too, as centos uses a different set of certificates for signing and we were not using them in the package yet. With this change, we also drop the usage of the beta certificates and the switch to the release certs: they aren't provided in the new scheme of system-sb-certs and anyway eg. grub2 isn't including/using those certs for signing. If there are still any switching of keys needed, ideally this should be done with the package providing system-sb-certs. While reviewing/doing this change, I also noted some missing signkernel macro guards were missing in the spec, which I added. Also, in the install part where we copy files to the kernel-doc package, I consolidated the logic and added missing signkernel/signmodules guards, with the existing code things would break if you disabled any of those options. v2: change pesign_name_0 for CentOS as reported by Brian Stinson Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
2022-01-25 23:15:17 +00:00
fi
%endif
redhat: switch the kernel package to use certs from system-sb-certs Bugzilla: INTERNAL Upstream Status: RHEL only commit ff5d8e5c949ed0e3468632fffa113d46ddcf8aea Author: Herton R. Krzesinski <herton@redhat.com> Date: Tue Jan 25 20:15:17 2022 -0300 redhat: switch the kernel package to use certs from system-sb-certs Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2045327 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2037084 Upstream Status: RHEL only Both redhat and centos are providing now the public certificates we use for secure boot signing through the redhat-sb-certs or centos-sb-certs packages. Those provides the system-sb-certs "virtual" package. Thus don't carry anymore the copy of the same certificates inside the kernel sources, instead switch to use the certificates provided by those packages. This will enable secure boot signing for centos too, as centos uses a different set of certificates for signing and we were not using them in the package yet. With this change, we also drop the usage of the beta certificates and the switch to the release certs: they aren't provided in the new scheme of system-sb-certs and anyway eg. grub2 isn't including/using those certs for signing. If there are still any switching of keys needed, ideally this should be done with the package providing system-sb-certs. While reviewing/doing this change, I also noted some missing signkernel macro guards were missing in the spec, which I added. Also, in the install part where we copy files to the kernel-doc package, I consolidated the logic and added missing signkernel/signmodules guards, with the existing code things would break if you disabled any of those options. v2: change pesign_name_0 for CentOS as reported by Brian Stinson Signed-off-by: Herton R. Krzesinski <herton@redhat.com> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
2022-08-29 19:46:18 +00:00
%endif
%if 0%{?rhel}
# Red Hat IMA code-signing cert, which is used to authenticate package files
install -m 0644 %{ima_signing_cert} $RPM_BUILD_ROOT%{_datadir}/doc/kernel-keys/$KernelVer/%{ima_cert_name}
%endif
redhat: switch the kernel package to use certs from system-sb-certs Bugzilla: INTERNAL Upstream Status: RHEL only commit ff5d8e5c949ed0e3468632fffa113d46ddcf8aea Author: Herton R. Krzesinski <herton@redhat.com> Date: Tue Jan 25 20:15:17 2022 -0300 redhat: switch the kernel package to use certs from system-sb-certs Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2045327 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2037084 Upstream Status: RHEL only Both redhat and centos are providing now the public certificates we use for secure boot signing through the redhat-sb-certs or centos-sb-certs packages. Those provides the system-sb-certs "virtual" package. Thus don't carry anymore the copy of the same certificates inside the kernel sources, instead switch to use the certificates provided by those packages. This will enable secure boot signing for centos too, as centos uses a different set of certificates for signing and we were not using them in the package yet. With this change, we also drop the usage of the beta certificates and the switch to the release certs: they aren't provided in the new scheme of system-sb-certs and anyway eg. grub2 isn't including/using those certs for signing. If there are still any switching of keys needed, ideally this should be done with the package providing system-sb-certs. While reviewing/doing this change, I also noted some missing signkernel macro guards were missing in the spec, which I added. Also, in the install part where we copy files to the kernel-doc package, I consolidated the logic and added missing signkernel/signmodules guards, with the existing code things would break if you disabled any of those options. v2: change pesign_name_0 for CentOS as reported by Brian Stinson Signed-off-by: Herton R. Krzesinski <herton@redhat.com> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
2022-08-29 19:46:18 +00:00
%if %{signmodules}
if [ $DoModules -eq 1 ]; then
# Save the signing keys so we can sign the modules in __modsign_install_post
cp certs/signing_key.pem certs/signing_key.pem.sign${Variant:++${Variant}}
cp certs/signing_key.x509 certs/signing_key.x509.sign${Variant:++${Variant}}
%ifarch s390x ppc64le
if [ ! -x /usr/bin/rpm-sign ]; then
install -m 0644 certs/signing_key.x509.sign${Variant:++${Variant}} $RPM_BUILD_ROOT%{_datadir}/doc/kernel-keys/$KernelVer/kernel-signing-ca.cer
openssl x509 -in certs/signing_key.pem.sign${Variant:++${Variant}} -outform der -out $RPM_BUILD_ROOT%{_datadir}/doc/kernel-keys/$KernelVer/%{signing_key_filename}
chmod 0644 $RPM_BUILD_ROOT%{_datadir}/doc/kernel-keys/$KernelVer/%{signing_key_filename}
fi
%endif
fi
%endif
%if %{with_ipaclones}
MAXPROCS=$(echo %{?_smp_mflags} | sed -n 's/-j\s*\([0-9]\+\)/\1/p')
if [ -z "$MAXPROCS" ]; then
MAXPROCS=1
fi
if [ "$Variant" == "" ]; then
mkdir -p $RPM_BUILD_ROOT/$DevelDir-ipaclones
find . -name '*.ipa-clones' | xargs -i{} -r -n 1 -P $MAXPROCS install -m 644 -D "{}" "$RPM_BUILD_ROOT/$DevelDir-ipaclones/{}"
fi
%endif
%if %{with_gcov}
popd
%endif
}
###
# DO it...
###
# prepare directories
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT/boot
mkdir -p $RPM_BUILD_ROOT%{_libexecdir}
cd linux-%{KVERREL}
%if %{with_debug}
BuildKernel %make_target %kernel_image %{_use_vdso} debug
%if %{with_arm64_64k}
BuildKernel %make_target %kernel_image %{_use_vdso} 64k-debug
%endif
%if %{with_realtime}
BuildKernel %make_target %kernel_image %{_use_vdso} rt-debug
%endif
%if %{with_realtime_arm64_64k}
BuildKernel %make_target %kernel_image %{_use_vdso} rt-64k-debug
%endif
%endif
%if %{with_zfcpdump}
BuildKernel %make_target %kernel_image %{_use_vdso} zfcpdump
%endif
%if %{with_arm64_64k}
BuildKernel %make_target %kernel_image %{_use_vdso} 64k
%endif
%if %{with_pae}
BuildKernel %make_target %kernel_image %{use_vdso} lpae
%endif
%if %{with_realtime}
BuildKernel %make_target %kernel_image %{use_vdso} rt
%endif
%if %{with_realtime_arm64_64k}
BuildKernel %make_target %kernel_image %{_use_vdso} rt-64k
%endif
%if %{with_up}
BuildKernel %make_target %kernel_image %{_use_vdso}
%endif
%ifnarch noarch i686
%if !%{with_debug} && !%{with_zfcpdump} && !%{with_pae} && !%{with_up} && !%{with_arm64_64k} && !%{with_realtime} && !%{with_realtime_arm64_64k}
# If only building the user space tools, then initialize the build environment
# and some variables so that the various userspace tools can be built.
InitBuildVars
%endif
%endif
%ifarch aarch64
%global perf_build_extra_opts CORESIGHT=1
%endif
%global perf_make \
%{__make} %{?make_opts} EXTRA_CFLAGS="${RPM_OPT_FLAGS}" EXTRA_CXXFLAGS="${RPM_OPT_FLAGS}" LDFLAGS="%{__global_ldflags} -Wl,-E" %{?cross_opts} -C tools/perf V=1 NO_PERF_READ_VDSO32=1 NO_PERF_READ_VDSOX32=1 WERROR=0 NO_LIBUNWIND=1 NO_GTK2=1 NO_STRLCPY=1 NO_BIONIC=1 LIBBPF_DYNAMIC=1 LIBTRACEEVENT_DYNAMIC=1 %{?perf_build_extra_opts} prefix=%{_prefix} PYTHON=%{__python3}
%if %{with_perf}
# perf
# make sure check-headers.sh is executable
chmod +x tools/perf/check-headers.sh
%{perf_make} DESTDIR=$RPM_BUILD_ROOT all
# libperf
make -C tools/lib/perf V=1
%endif
%global tools_make \
CFLAGS="${RPM_OPT_FLAGS}" LDFLAGS="%{__global_ldflags}" EXTRA_CFLAGS="${RPM_OPT_FLAGS}" %{make} %{?make_opts}
%ifarch %{cpupowerarchs}
# link against in-tree libcpupower for idle state support
%global rtla_make %{tools_make} LDFLAGS="%{__global_ldflags} -L../../power/cpupower" INCLUDES="-I../../power/cpupower/lib"
%else
%global rtla_make %{tools_make}
%endif
%if %{with_tools}
%ifarch %{cpupowerarchs}
# cpupower
# make sure version-gen.sh is executable.
chmod +x tools/power/cpupower/utils/version-gen.sh
%{tools_make} %{?_smp_mflags} -C tools/power/cpupower CPUFREQ_BENCH=false DEBUG=false
%ifarch x86_64
pushd tools/power/cpupower/debug/x86_64
%{tools_make} %{?_smp_mflags} centrino-decode powernow-k8-decode
popd
%endif
%ifarch x86_64
pushd tools/power/x86/x86_energy_perf_policy/
%{tools_make}
popd
pushd tools/power/x86/turbostat
%{tools_make}
popd
pushd tools/power/x86/intel-speed-select
redhat: change tools_make macro to avoid full override of variables in Makefile Bugzilla: INTERNAL Upstream Status: RHEL only, https://gitlab.com/cki-project/kernel-ark commit b9e1f362b08853fe65e96e0a954f645cd3271cd8 Author: Herton R. Krzesinski <herton@redhat.com> Date: Wed Jun 8 09:01:27 2022 -0300 redhat: change tools_make macro to avoid full override of variables in Makefile As was previously discussed in kernel-ark MR 1721, there is a difference of calling "CFLAGS=(...) make" and "make CFLAGS=(...)", the latter can end up overriding Makefile defined values even if the makefile have eg. "override CFLAGS +=". One example of such Makefile is tools/power/x86/intel-speed-select/Makefile, where I tested both invocations and indeed doing the second form overrides the cflags including the needed included (-I) directives, which will make the build fail. So when building the tools, we don't want to ovewrite entirely the value the Makefile provides. Instead, we want the default distro flags to be added to the current defined values. This changes tools_make macro to do that. With this we can also remove the workaround of having to specify same CFLAGS again with intel-speed-select build. Unfortunately, intel_sdsi tool Makefile overrides CFLAGS from the environment entirely with a 'CFLAGS =' setting at its beginning. So until it's fixed, we have to still do an workaround setting CFLAGS after make, otherwise build fails with a relocation error when using the now provided LDFLAGS from the distro. Verified the changes here by doing a verbose eln build and checking CFLAGS/LDFLAGS are being passed: https://koji.fedoraproject.org/koji/taskinfo?taskID=88001746 Signed-off-by: Herton R. Krzesinski <herton@redhat.com> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
2022-08-29 17:59:09 +00:00
%{tools_make}
popd
pushd tools/arch/x86/intel_sdsi
redhat: change tools_make macro to avoid full override of variables in Makefile Bugzilla: INTERNAL Upstream Status: RHEL only, https://gitlab.com/cki-project/kernel-ark commit b9e1f362b08853fe65e96e0a954f645cd3271cd8 Author: Herton R. Krzesinski <herton@redhat.com> Date: Wed Jun 8 09:01:27 2022 -0300 redhat: change tools_make macro to avoid full override of variables in Makefile As was previously discussed in kernel-ark MR 1721, there is a difference of calling "CFLAGS=(...) make" and "make CFLAGS=(...)", the latter can end up overriding Makefile defined values even if the makefile have eg. "override CFLAGS +=". One example of such Makefile is tools/power/x86/intel-speed-select/Makefile, where I tested both invocations and indeed doing the second form overrides the cflags including the needed included (-I) directives, which will make the build fail. So when building the tools, we don't want to ovewrite entirely the value the Makefile provides. Instead, we want the default distro flags to be added to the current defined values. This changes tools_make macro to do that. With this we can also remove the workaround of having to specify same CFLAGS again with intel-speed-select build. Unfortunately, intel_sdsi tool Makefile overrides CFLAGS from the environment entirely with a 'CFLAGS =' setting at its beginning. So until it's fixed, we have to still do an workaround setting CFLAGS after make, otherwise build fails with a relocation error when using the now provided LDFLAGS from the distro. Verified the changes here by doing a verbose eln build and checking CFLAGS/LDFLAGS are being passed: https://koji.fedoraproject.org/koji/taskinfo?taskID=88001746 Signed-off-by: Herton R. Krzesinski <herton@redhat.com> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
2022-08-29 17:59:09 +00:00
%{tools_make} CFLAGS="${RPM_OPT_FLAGS}"
popd
%endif
%endif
pushd tools/thermal/tmon/
%{tools_make}
popd
pushd tools/bootconfig/
%{tools_make}
popd
pushd tools/iio/
%{tools_make}
popd
pushd tools/gpio/
%{tools_make}
popd
# build VM tools
pushd tools/mm/
redhat: fix elf got hardening for vm tools Bugzilla: INTERNAL Upstream Status: RHEL only Tested: rpminspect -T elf -c ~/work/centos-stream-9/redhat/rpminspect.yaml kernel-tools-5.14.0-171.el9.x86_64.rpm kernel-tools-5.14.0-172.test.el9.x86_64.rpm MR 1308 synced redhat/ dir with ark and the following commit commit 693b6dde0c13dd50c7c2a2318098c67af5c28580 Author: Prarit Bhargava <prarit@redhat.com> Date: Mon Aug 29 13:59:09 2022 -0400 redhat: change tools_make macro to avoid full override of variables in Makefile changed behavior of tools_make macro %global tools_make \ - %{make} CFLAGS="${RPM_OPT_FLAGS}" LDFLAGS="%{__global_ldflags}" %{?make_opts} + CFLAGS="${RPM_OPT_FLAGS}" LDFLAGS="%{__global_ldflags}" %{make} %{?make_opts} Since tools/vm/Makefile assigns CFLAGS and LDFLAGS, it overrides the env variables from tools_make command and we lose some hardening options. For example GOT RO about which rpmispect is complaining. Result: BAD 1) /usr/bin/page_owner_sort lost full GNU_RELRO security protection on aarch64 Waiver Authorization: Security Suggested Remedy: Ensure executables are linked with with '-z relro -z now' Result: BAD 2) /usr/bin/slabinfo lost full GNU_RELRO security protection on aarch64 Waiver Authorization: Security Suggested Remedy: Ensure executables are linked with with '-z relro -z now' Fix this by explicitly overwrite CFLAGS and LDFLAGS for tools/vm/Makefile with command arguments. This basically brings back the previous behavior of tools_make for vm tools. This is ugly, because page-types actually needs the LDFLAGS defined in the makefile, because it links against libapi.a. But we are not building this and the problem was there before this change too. Probably best way would be to fix the tools/vm/Makefile. Signed-off-by: Frantisek Hrbata <fhrbata@redhat.com>
2022-10-04 14:32:40 +00:00
%{tools_make} CFLAGS="${RPM_OPT_FLAGS}" LDFLAGS="%{__global_ldflags}" slabinfo page_owner_sort
popd
pushd tools/verification/rv/
%{tools_make}
popd
pushd tools/tracing/rtla
%{rtla_make}
popd
%endif
if [ -f $DevelDir/vmlinux.h ]; then
RPM_VMLINUX_H=$DevelDir/vmlinux.h
fi
echo "${RPM_VMLINUX_H}" > ../vmlinux_h_path
%if %{with_selftests}
# Unfortunately, samples/bpf/Makefile expects that the headers are installed
# in the source tree. We installed them previously to $RPM_BUILD_ROOT/usr
# but there's no way to tell the Makefile to take them from there.
%{make} %{?_smp_mflags} headers_install
# If we re building only tools without kernel, we need to generate config
# headers and prepare tree for modules building. The modules_prepare target
# will cover both.
if [ ! -f include/generated/autoconf.h ]; then
%{make} %{?_smp_mflags} modules_prepare
fi
%{make} %{?_smp_mflags} ARCH=$Arch V=1 M=samples/bpf/ VMLINUX_H="${RPM_VMLINUX_H}" || true
kernel.spec: avoid building bpftool repeatedly Backport of RHEL8 commit. commit 334cd6472196835d71a4eb0479822e73fa364498 Author: Jiri Benc <jbenc@redhat.com> Date: Tue Aug 18 13:38:55 2020 -0400 [redhat] redhat: avoid building bpftool repeatedly Message-id: <5d080c5b61399ad635a271a7ff28a3c63f67d6ff.1597757857.git.jbenc@redhat.com> Patchwork-id: 324292 Patchwork-instance: patchwork O-Subject: [RHEL8.3 64/63] redhat: avoid building bpftool repeatedly Bugzilla: 1866908 RH-Acked-by: Bruno Meneguele <bmeneg@redhat.com> RH-Acked-by: Frantisek Hrbata <fhrbata@redhat.com> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1866908 Brew: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=30777253 Currently, tools/testing/selftests/bpf/Makefile builds bpftool twice, even though it has already been built. It is first built as tools/testing/selftests/bpf/tools/build/bpftool/bpftool and then a build of runqslower is invoked, which builds bpftool again as tools/testing/selftests/bpf/tools/bpftool. This is not only waste of time and resources, it's also prone to build errors: the two additional bpftool builds are run in parallel from the same base directory. As the result, they both try to create profiler.skel.h, which, depending on timing, may lead to gcc seeing a truncated include file and failing with weird errors. There's a mechanism in the makefile to use an already built bpftool. Let's just use it. Tested: built and run selftests, everything seems working as it should. According to brew logs, bpftool is not built anymore from selftests. Signed-off-by: Jiri Benc <jbenc@redhat.com> Signed-off-by: Frantisek Hrbata <fhrbata@redhat.com> Signed-off-by: Jiri Benc <jbenc@redhat.com> Signed-off-by: Jiri Olsa <jolsa@redhat.com>
2021-04-23 08:15:24 +00:00
pushd tools/testing/selftests
# We need to install here because we need to call make with ARCH set which
# doesn't seem possible to do in the install section.
%{make} %{?_smp_mflags} ARCH=$Arch V=1 TARGETS="bpf cgroup mm livepatch net net/forwarding net/mptcp net/netfilter tc-testing memfd drivers/net/bonding iommu cachestat drivers/net" SKIP_TARGETS="" FORCE_TARGETS=1 INSTALL_PATH=%{buildroot}%{_libexecdir}/kselftests VMLINUX_H="${RPM_VMLINUX_H}" DEFAULT_INSTALL_HDR_PATH=0 install
# 'make install' for bpf is broken and upstream refuses to fix it.
# Install the needed files manually.
for dir in bpf bpf/no_alu32 bpf/cpuv4 bpf/progs; do
# In ARK, the rpm build continues even if some of the selftests
# cannot be built. It's not always possible to build selftests,
# as upstream sometimes dependens on too new llvm version or has
# other issues. If something did not get built, just skip it.
test -d $dir || continue
mkdir -p %{buildroot}%{_libexecdir}/kselftests/$dir
find $dir -maxdepth 1 -type f \( -executable -o -name '*.py' -o -name settings -o \
-name 'btf_dump_test_case_*.c' -o -name '*.ko' -o \
-name '*.o' -exec sh -c 'readelf -h "{}" | grep -q "^ Machine:.*BPF"' \; \) -print0 | \
xargs -0 cp -t %{buildroot}%{_libexecdir}/kselftests/$dir || true
done
ln -sr %{buildroot}%{_libexecdir}/kselftests/bpf/bpftool %{buildroot}%{_libexecdir}/kselftests/bpf/no_alu32/bpftool
# CKI clang does not support cpuv4 so it skips this variant
ln -sr %{buildroot}%{_libexecdir}/kselftests/bpf/bpftool %{buildroot}%{_libexecdir}/kselftests/bpf/cpuv4/bpftool || echo "selftests/bpf: no cpuv4 variant"
%buildroot_save_unstripped "usr/libexec/kselftests/bpf/test_progs"
%buildroot_save_unstripped "usr/libexec/kselftests/bpf/test_progs-no_alu32"
%buildroot_save_unstripped "usr/libexec/kselftests/bpf/test_progs-cpuv4"
popd
%endif
%if %{with_doc}
# Make the HTML pages.
%{__make} PYTHON=/usr/bin/python3 htmldocs || %{doc_build_fail}
# sometimes non-world-readable files sneak into the kernel source tree
chmod -R a=rX Documentation
find Documentation -type d | xargs chmod u+w
%endif
# In the modsign case, we do 3 things. 1) We check the "variant" and hard
# code the value in the following invocations. This is somewhat sub-optimal
# but we're doing this inside of an RPM macro and it isn't as easy as it
# could be because of that. 2) We restore the .tmp_versions/ directory from
# the one we saved off in BuildKernel above. This is to make sure we're
# signing the modules we actually built/installed in that variant. 3) We
# grab the arch and invoke mod-sign.sh command to actually sign the modules.
#
# We have to do all of those things _after_ find-debuginfo runs, otherwise
# that will strip the signature off of the modules.
#
# Don't sign modules for the zfcpdump variant as it is monolithic.
%define __modsign_install_post \
if [ "%{signmodules}" -eq "1" ]; then \
if [ "%{with_pae}" -ne "0" ]; then \
%{modsign_cmd} certs/signing_key.pem.sign+lpae certs/signing_key.x509.sign+lpae $RPM_BUILD_ROOT/lib/modules/%{KVERREL}+lpae/ \
fi \
if [ "%{with_realtime}" -ne "0" ]; then \
%{modsign_cmd} certs/signing_key.pem.sign+rt certs/signing_key.x509.sign+rt $RPM_BUILD_ROOT/lib/modules/%{KVERREL}+rt/ \
fi \
if [ "%{with_debug}" -ne "0" ]; then \
%{modsign_cmd} certs/signing_key.pem.sign+debug certs/signing_key.x509.sign+debug $RPM_BUILD_ROOT/lib/modules/%{KVERREL}+debug/ \
fi \
if [ "%{with_arm64_64k}" -ne "0" ]; then \
%{modsign_cmd} certs/signing_key.pem.sign+64k certs/signing_key.x509.sign+64k $RPM_BUILD_ROOT/lib/modules/%{KVERREL}+64k/ \
fi \
if [ "%{with_arm64_64k}" -ne "0" ] && [ "%{with_debug}" -ne "0" ]; then \
%{modsign_cmd} certs/signing_key.pem.sign+64k-debug certs/signing_key.x509.sign+64k-debug $RPM_BUILD_ROOT/lib/modules/%{KVERREL}+64k-debug/ \
fi \
if [ "%{with_realtime}" -ne "0" ] && [ "%{with_debug}" -ne "0" ]; then \
%{modsign_cmd} certs/signing_key.pem.sign+rt-debug certs/signing_key.x509.sign+rt-debug $RPM_BUILD_ROOT/lib/modules/%{KVERREL}+rt-debug/ \
fi \
if [ "%{with_realtime_arm64_64k}" -ne "0" ]; then \
%{modsign_cmd} certs/signing_key.pem.sign+rt-64k certs/signing_key.x509.sign+rt-64k $RPM_BUILD_ROOT/lib/modules/%{KVERREL}+rt-64k/ \
fi \
if [ "%{with_realtime_arm64_64k}" -ne "0" ] && [ "%{with_debug}" -ne "0" ]; then \
%{modsign_cmd} certs/signing_key.pem.sign+rt-64k-debug certs/signing_key.x509.sign+rt-64k-debug $RPM_BUILD_ROOT/lib/modules/%{KVERREL}+rt-64k-debug/ \
fi \
if [ "%{with_up}" -ne "0" ]; then \
%{modsign_cmd} certs/signing_key.pem.sign certs/signing_key.x509.sign $RPM_BUILD_ROOT/lib/modules/%{KVERREL}/ \
fi \
fi \
if [ "%{zipmodules}" -eq "1" ]; then \
echo "Compressing kernel modules ..." \
find $RPM_BUILD_ROOT/lib/modules/ -type f -name '*.ko' | xargs -n 16 -P${RPM_BUILD_NCPUS} -r %compression %compression_flags; \
fi \
%{nil}
###
### Special hacks for debuginfo subpackages.
###
# This macro is used by %%install, so we must redefine it before that.
%define debug_package %{nil}
%if %{with_debuginfo}
%ifnarch noarch
%global __debug_package 1
%files -f debugfiles.list debuginfo-common-%{_target_cpu}
%endif
%endif
# We don't want to package debuginfo for self-tests and samples but
# we have to delete them to avoid an error messages about unpackaged
# files.
# Delete the debuginfo for kernel-devel files
%define __remove_unwanted_dbginfo_install_post \
if [ "%{with_selftests}" -ne "0" ]; then \
rm -rf $RPM_BUILD_ROOT/usr/lib/debug/usr/libexec/ksamples; \
rm -rf $RPM_BUILD_ROOT/usr/lib/debug/usr/libexec/kselftests; \
fi \
rm -rf $RPM_BUILD_ROOT/usr/lib/debug/usr/src; \
%{nil}
#
# Disgusting hack alert! We need to ensure we sign modules *after* all
# invocations of strip occur, which is in __debug_install_post if
# find-debuginfo.sh runs, and __os_install_post if not.
#
%define __spec_install_post \
%{?__debug_package:%{__debug_install_post}}\
%{__arch_install_post}\
%{__os_install_post}\
%{__remove_unwanted_dbginfo_install_post}\
%{__restore_unstripped_root_post}\
%{__modsign_install_post}
###
### install
###
%install
cd linux-%{KVERREL}
# re-define RPM_VMLINUX_H, because it doesn't carry over from %build
RPM_VMLINUX_H="$(cat ../vmlinux_h_path)"
%if %{with_doc}
docdir=$RPM_BUILD_ROOT%{_datadir}/doc/kernel-doc-%{specversion}-%{pkgrelease}
# copy the source over
mkdir -p $docdir
tar -h -f - --exclude=man --exclude='.*' -c Documentation | tar xf - -C $docdir
cat %{SOURCE2} | xz > $docdir/kernel.changelog.xz
chmod 0644 $docdir/kernel.changelog.xz
# with_doc
%endif
# We have to do the headers install before the tools install because the
# kernel headers_install will remove any header files in /usr/include that
# it doesn't install itself.
%if %{with_headers}
# Install kernel headers
%{__make} ARCH=%{hdrarch} INSTALL_HDR_PATH=$RPM_BUILD_ROOT/usr headers_install
find $RPM_BUILD_ROOT/usr/include \
\( -name .install -o -name .check -o \
-name ..install.cmd -o -name ..check.cmd \) -delete
%endif
%if %{with_cross_headers}
%if 0%{?fedora}
HDR_ARCH_LIST='arm arm64 powerpc s390 x86'
%else
HDR_ARCH_LIST='arm64 powerpc s390 x86'
%endif
mkdir -p $RPM_BUILD_ROOT/usr/tmp-headers
for arch in $HDR_ARCH_LIST; do
mkdir $RPM_BUILD_ROOT/usr/tmp-headers/arch-${arch}
%{__make} ARCH=${arch} INSTALL_HDR_PATH=$RPM_BUILD_ROOT/usr/tmp-headers/arch-${arch} headers_install
done
find $RPM_BUILD_ROOT/usr/tmp-headers \
\( -name .install -o -name .check -o \
-name ..install.cmd -o -name ..check.cmd \) -delete
# Copy all the architectures we care about to their respective asm directories
for arch in $HDR_ARCH_LIST ; do
mkdir -p $RPM_BUILD_ROOT/usr/${arch}-linux-gnu/include
mv $RPM_BUILD_ROOT/usr/tmp-headers/arch-${arch}/include/* $RPM_BUILD_ROOT/usr/${arch}-linux-gnu/include/
done
rm -rf $RPM_BUILD_ROOT/usr/tmp-headers
%endif
%if %{with_kernel_abi_stablelists}
# kabi directory
INSTALL_KABI_PATH=$RPM_BUILD_ROOT/lib/modules/
mkdir -p $INSTALL_KABI_PATH
# install kabi releases directories
tar xjvf %{SOURCE300} -C $INSTALL_KABI_PATH
# with_kernel_abi_stablelists
%endif
%if %{with_perf}
# perf tool binary and supporting scripts/binaries
%{perf_make} DESTDIR=$RPM_BUILD_ROOT lib=%{_lib} install-bin
# remove the 'trace' symlink.
rm -f %{buildroot}%{_bindir}/trace
# For both of the below, yes, this should be using a macro but right now
# it's hard coded and we don't actually want it anyway right now.
# Whoever wants examples can fix it up!
# remove examples
rm -rf %{buildroot}/usr/lib/perf/examples
rm -rf %{buildroot}/usr/lib/perf/include
# python-perf extension
%{perf_make} DESTDIR=$RPM_BUILD_ROOT install-python_ext
# perf man pages (note: implicit rpm magic compresses them later)
mkdir -p %{buildroot}/%{_mandir}/man1
%{perf_make} DESTDIR=$RPM_BUILD_ROOT install-man
# remove any tracevent files, eg. its plugins still gets built and installed,
# even if we build against system's libtracevent during perf build (by setting
# LIBTRACEEVENT_DYNAMIC=1 above in perf_make macro). Those files should already
# ship with libtraceevent package.
rm -rf %{buildroot}%{_libdir}/traceevent
# libperf
make -C tools/lib/perf DESTDIR=%{buildroot} prefix=%{_prefix} libdir=%{_libdir} V=1 install
rm -f %{buildroot}%{_libdir}/libperf.a
%endif
%if %{with_tools}
%ifarch %{cpupowerarchs}
%{make} -C tools/power/cpupower DESTDIR=$RPM_BUILD_ROOT libdir=%{_libdir} mandir=%{_mandir} CPUFREQ_BENCH=false install
rm -f %{buildroot}%{_libdir}/*.{a,la}
%find_lang cpupower
mv cpupower.lang ../
%ifarch x86_64
pushd tools/power/cpupower/debug/x86_64
install -m755 centrino-decode %{buildroot}%{_bindir}/centrino-decode
install -m755 powernow-k8-decode %{buildroot}%{_bindir}/powernow-k8-decode
popd
%endif
chmod 0755 %{buildroot}%{_libdir}/libcpupower.so*
mkdir -p %{buildroot}%{_unitdir} %{buildroot}%{_sysconfdir}/sysconfig
install -m644 %{SOURCE2000} %{buildroot}%{_unitdir}/cpupower.service
install -m644 %{SOURCE2001} %{buildroot}%{_sysconfdir}/sysconfig/cpupower
%endif
%ifarch x86_64
mkdir -p %{buildroot}%{_mandir}/man8
pushd tools/power/x86/x86_energy_perf_policy
%{tools_make} DESTDIR=%{buildroot} install
popd
pushd tools/power/x86/turbostat
%{tools_make} DESTDIR=%{buildroot} install
popd
pushd tools/power/x86/intel-speed-select
redhat: change tools_make macro to avoid full override of variables in Makefile Bugzilla: INTERNAL Upstream Status: RHEL only, https://gitlab.com/cki-project/kernel-ark commit b9e1f362b08853fe65e96e0a954f645cd3271cd8 Author: Herton R. Krzesinski <herton@redhat.com> Date: Wed Jun 8 09:01:27 2022 -0300 redhat: change tools_make macro to avoid full override of variables in Makefile As was previously discussed in kernel-ark MR 1721, there is a difference of calling "CFLAGS=(...) make" and "make CFLAGS=(...)", the latter can end up overriding Makefile defined values even if the makefile have eg. "override CFLAGS +=". One example of such Makefile is tools/power/x86/intel-speed-select/Makefile, where I tested both invocations and indeed doing the second form overrides the cflags including the needed included (-I) directives, which will make the build fail. So when building the tools, we don't want to ovewrite entirely the value the Makefile provides. Instead, we want the default distro flags to be added to the current defined values. This changes tools_make macro to do that. With this we can also remove the workaround of having to specify same CFLAGS again with intel-speed-select build. Unfortunately, intel_sdsi tool Makefile overrides CFLAGS from the environment entirely with a 'CFLAGS =' setting at its beginning. So until it's fixed, we have to still do an workaround setting CFLAGS after make, otherwise build fails with a relocation error when using the now provided LDFLAGS from the distro. Verified the changes here by doing a verbose eln build and checking CFLAGS/LDFLAGS are being passed: https://koji.fedoraproject.org/koji/taskinfo?taskID=88001746 Signed-off-by: Herton R. Krzesinski <herton@redhat.com> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
2022-08-29 17:59:09 +00:00
%{tools_make} DESTDIR=%{buildroot} install
popd
pushd tools/arch/x86/intel_sdsi
redhat: change tools_make macro to avoid full override of variables in Makefile Bugzilla: INTERNAL Upstream Status: RHEL only, https://gitlab.com/cki-project/kernel-ark commit b9e1f362b08853fe65e96e0a954f645cd3271cd8 Author: Herton R. Krzesinski <herton@redhat.com> Date: Wed Jun 8 09:01:27 2022 -0300 redhat: change tools_make macro to avoid full override of variables in Makefile As was previously discussed in kernel-ark MR 1721, there is a difference of calling "CFLAGS=(...) make" and "make CFLAGS=(...)", the latter can end up overriding Makefile defined values even if the makefile have eg. "override CFLAGS +=". One example of such Makefile is tools/power/x86/intel-speed-select/Makefile, where I tested both invocations and indeed doing the second form overrides the cflags including the needed included (-I) directives, which will make the build fail. So when building the tools, we don't want to ovewrite entirely the value the Makefile provides. Instead, we want the default distro flags to be added to the current defined values. This changes tools_make macro to do that. With this we can also remove the workaround of having to specify same CFLAGS again with intel-speed-select build. Unfortunately, intel_sdsi tool Makefile overrides CFLAGS from the environment entirely with a 'CFLAGS =' setting at its beginning. So until it's fixed, we have to still do an workaround setting CFLAGS after make, otherwise build fails with a relocation error when using the now provided LDFLAGS from the distro. Verified the changes here by doing a verbose eln build and checking CFLAGS/LDFLAGS are being passed: https://koji.fedoraproject.org/koji/taskinfo?taskID=88001746 Signed-off-by: Herton R. Krzesinski <herton@redhat.com> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
2022-08-29 17:59:09 +00:00
%{tools_make} CFLAGS="${RPM_OPT_FLAGS}" DESTDIR=%{buildroot} install
popd
%endif
pushd tools/thermal/tmon
%{tools_make} INSTALL_ROOT=%{buildroot} install
popd
pushd tools/bootconfig
%{tools_make} DESTDIR=%{buildroot} install
popd
pushd tools/iio
%{tools_make} DESTDIR=%{buildroot} install
popd
pushd tools/gpio
%{tools_make} DESTDIR=%{buildroot} install
popd
install -m644 -D %{SOURCE2002} %{buildroot}%{_sysconfdir}/logrotate.d/kvm_stat
pushd tools/kvm/kvm_stat
%{__make} INSTALL_ROOT=%{buildroot} install-tools
%{__make} INSTALL_ROOT=%{buildroot} install-man
install -m644 -D kvm_stat.service %{buildroot}%{_unitdir}/kvm_stat.service
popd
# install VM tools
pushd tools/mm/
install -m755 slabinfo %{buildroot}%{_bindir}/slabinfo
install -m755 page_owner_sort %{buildroot}%{_bindir}/page_owner_sort
popd
pushd tools/verification/rv/
%{tools_make} DESTDIR=%{buildroot} install
popd
pushd tools/tracing/rtla/
%{tools_make} DESTDIR=%{buildroot} install
rm -f %{buildroot}%{_bindir}/hwnoise
rm -f %{buildroot}%{_bindir}/osnoise
rm -f %{buildroot}%{_bindir}/timerlat
(cd %{buildroot}
ln -sf rtla ./%{_bindir}/hwnoise
ln -sf rtla ./%{_bindir}/osnoise
ln -sf rtla ./%{_bindir}/timerlat
)
popd
%endif
%if %{with_selftests}
pushd samples
install -d %{buildroot}%{_libexecdir}/ksamples
# install bpf samples
pushd bpf
install -d %{buildroot}%{_libexecdir}/ksamples/bpf
find -type f -executable -exec install -m755 {} %{buildroot}%{_libexecdir}/ksamples/bpf \;
install -m755 *.sh %{buildroot}%{_libexecdir}/ksamples/bpf
# test_lwt_bpf.sh compiles test_lwt_bpf.c when run; this works only from the
# kernel tree. Just remove it.
rm %{buildroot}%{_libexecdir}/ksamples/bpf/test_lwt_bpf.sh
install -m644 *_kern.o %{buildroot}%{_libexecdir}/ksamples/bpf || true
install -m644 tcp_bpf.readme %{buildroot}%{_libexecdir}/ksamples/bpf
popd
# install pktgen samples
pushd pktgen
install -d %{buildroot}%{_libexecdir}/ksamples/pktgen
find . -type f -executable -exec install -m755 {} %{buildroot}%{_libexecdir}/ksamples/pktgen/{} \;
find . -type f ! -executable -exec install -m644 {} %{buildroot}%{_libexecdir}/ksamples/pktgen/{} \;
popd
popd
# install mm selftests
pushd tools/testing/selftests/mm
find -type d -exec install -d %{buildroot}%{_libexecdir}/kselftests/mm/{} \;
find -type f -executable -exec install -D -m755 {} %{buildroot}%{_libexecdir}/kselftests/mm/{} \;
find -type f ! -executable -exec install -D -m644 {} %{buildroot}%{_libexecdir}/kselftests/mm/{} \;
popd
# install cgroup selftests
pushd tools/testing/selftests/cgroup
find -type d -exec install -d %{buildroot}%{_libexecdir}/kselftests/cgroup/{} \;
find -type f -executable -exec install -D -m755 {} %{buildroot}%{_libexecdir}/kselftests/cgroup/{} \;
find -type f ! -executable -exec install -D -m644 {} %{buildroot}%{_libexecdir}/kselftests/cgroup/{} \;
popd
# install drivers/net/mlxsw selftests
pushd tools/testing/selftests/drivers/net/mlxsw
find -type d -exec install -d %{buildroot}%{_libexecdir}/kselftests/drivers/net/mlxsw/{} \;
find -type f -executable -exec install -D -m755 {} %{buildroot}%{_libexecdir}/kselftests/drivers/net/mlxsw/{} \;
find -type f ! -executable -exec install -D -m644 {} %{buildroot}%{_libexecdir}/kselftests/drivers/net/mlxsw/{} \;
popd
# install drivers/net/netdevsim selftests
pushd tools/testing/selftests/drivers/net/netdevsim
find -type d -exec install -d %{buildroot}%{_libexecdir}/kselftests/drivers/net/netdevsim/{} \;
find -type f -executable -exec install -D -m755 {} %{buildroot}%{_libexecdir}/kselftests/drivers/net/netdevsim/{} \;
find -type f ! -executable -exec install -D -m644 {} %{buildroot}%{_libexecdir}/kselftests/drivers/net/netdevsim/{} \;
popd
# install drivers/net/bonding selftests
pushd tools/testing/selftests/drivers/net/bonding
find -type d -exec install -d %{buildroot}%{_libexecdir}/kselftests/drivers/net/bonding/{} \;
find -type f -executable -exec install -D -m755 {} %{buildroot}%{_libexecdir}/kselftests/drivers/net/bonding/{} \;
find -type f ! -executable -exec install -D -m644 {} %{buildroot}%{_libexecdir}/kselftests/drivers/net/bonding/{} \;
popd
# install net/forwarding selftests
pushd tools/testing/selftests/net/forwarding
find -type d -exec install -d %{buildroot}%{_libexecdir}/kselftests/net/forwarding/{} \;
find -type f -executable -exec install -D -m755 {} %{buildroot}%{_libexecdir}/kselftests/net/forwarding/{} \;
find -type f ! -executable -exec install -D -m644 {} %{buildroot}%{_libexecdir}/kselftests/net/forwarding/{} \;
popd
# install net/mptcp selftests
pushd tools/testing/selftests/net/mptcp
find -type d -exec install -d %{buildroot}%{_libexecdir}/kselftests/net/mptcp/{} \;
find -type f -executable -exec install -D -m755 {} %{buildroot}%{_libexecdir}/kselftests/net/mptcp/{} \;
find -type f ! -executable -exec install -D -m644 {} %{buildroot}%{_libexecdir}/kselftests/net/mptcp/{} \;
popd
# install tc-testing selftests
pushd tools/testing/selftests/tc-testing
find -type d -exec install -d %{buildroot}%{_libexecdir}/kselftests/tc-testing/{} \;
find -type f -executable -exec install -D -m755 {} %{buildroot}%{_libexecdir}/kselftests/tc-testing/{} \;
find -type f ! -executable -exec install -D -m644 {} %{buildroot}%{_libexecdir}/kselftests/tc-testing/{} \;
popd
# install livepatch selftests
pushd tools/testing/selftests/livepatch
find -type d -exec install -d %{buildroot}%{_libexecdir}/kselftests/livepatch/{} \;
find -type f -executable -exec install -D -m755 {} %{buildroot}%{_libexecdir}/kselftests/livepatch/{} \;
find -type f ! -executable -exec install -D -m644 {} %{buildroot}%{_libexecdir}/kselftests/livepatch/{} \;
popd
# install net/netfilter selftests
pushd tools/testing/selftests/net/netfilter
find -type d -exec install -d %{buildroot}%{_libexecdir}/kselftests/net/netfilter/{} \;
find -type f -executable -exec install -D -m755 {} %{buildroot}%{_libexecdir}/kselftests/net/netfilter/{} \;
find -type f ! -executable -exec install -D -m644 {} %{buildroot}%{_libexecdir}/kselftests/net/netfilter/{} \;
popd
# install memfd selftests
pushd tools/testing/selftests/memfd
find -type d -exec install -d %{buildroot}%{_libexecdir}/kselftests/memfd/{} \;
find -type f -executable -exec install -D -m755 {} %{buildroot}%{_libexecdir}/kselftests/memfd/{} \;
find -type f ! -executable -exec install -D -m644 {} %{buildroot}%{_libexecdir}/kselftests/memfd/{} \;
popd
# install iommu selftests
pushd tools/testing/selftests/iommu
find -type d -exec install -d %{buildroot}%{_libexecdir}/kselftests/iommu/{} \;
find -type f -executable -exec install -D -m755 {} %{buildroot}%{_libexecdir}/kselftests/iommu/{} \;
find -type f ! -executable -exec install -D -m644 {} %{buildroot}%{_libexecdir}/kselftests/iommu/{} \;
popd
# install cachestat selftests
pushd tools/testing/selftests/cachestat
find -type d -exec install -d %{buildroot}%{_libexecdir}/kselftests/cachestat/{} \;
find -type f -executable -exec install -D -m755 {} %{buildroot}%{_libexecdir}/kselftests/cachestat/{} \;
find -type f ! -executable -exec install -D -m644 {} %{buildroot}%{_libexecdir}/kselftests/cachestat/{} \;
popd
%endif
###
### clean
###
###
### scripts
###
%if %{with_tools}
%post -n kernel-tools
%systemd_post cpupower.service
%preun -n kernel-tools
%systemd_preun cpupower.service
%postun -n kernel-tools
%systemd_postun cpupower.service
%post -n kernel-tools-libs
/sbin/ldconfig
%postun -n kernel-tools-libs
/sbin/ldconfig
%endif
#
# This macro defines a %%post script for a kernel*-devel package.
# %%kernel_devel_post [<subpackage>]
# Note we don't run hardlink if ostree is in use, as ostree is
# a far more sophisticated hardlink implementation.
# https://github.com/projectatomic/rpm-ostree/commit/58a79056a889be8814aa51f507b2c7a4dccee526
#
# The deletion of *.hardlink-temporary files is a temporary workaround
# for this bug in the hardlink binary (fixed in util-linux 2.38):
# https://github.com/util-linux/util-linux/issues/1602
#
%define kernel_devel_post() \
%{expand:%%post %{?1:%{1}-}devel}\
if [ -f /etc/sysconfig/kernel ]\
then\
. /etc/sysconfig/kernel || exit $?\
fi\
if [ "$HARDLINK" != "no" -a -x /usr/bin/hardlink -a ! -e /run/ostree-booted ] \
then\
(cd /usr/src/kernels/%{KVERREL}%{?1:+%{1}} &&\
/usr/bin/find . -type f | while read f; do\
hardlink -c /usr/src/kernels/*%{?dist}.*/$f $f > /dev/null\
done;\
/usr/bin/find /usr/src/kernels -type f -name '*.hardlink-temporary' -delete\
)\
fi\
%if %{with_cross}\
echo "Building scripts and resolve_btfids"\
env --unset=ARCH make -C /usr/src/kernels/%{KVERREL}%{?1:+%{1}} prepare_after_cross\
%endif\
%{nil}
#
# This macro defines a %%post script for a kernel*-modules-extra package.
# It also defines a %%postun script that does the same thing.
# %%kernel_modules_extra_post [<subpackage>]
#
%define kernel_modules_extra_post() \
%{expand:%%post %{?1:%{1}-}modules-extra}\
/sbin/depmod -a %{KVERREL}%{?1:+%{1}}\
%{nil}\
%{expand:%%postun %{?1:%{1}-}modules-extra}\
/sbin/depmod -a %{KVERREL}%{?1:+%{1}}\
%{nil}
#
# This macro defines a %%post script for a kernel*-modules-internal package.
# It also defines a %%postun script that does the same thing.
# %%kernel_modules_internal_post [<subpackage>]
#
%define kernel_modules_internal_post() \
%{expand:%%post %{?1:%{1}-}modules-internal}\
/sbin/depmod -a %{KVERREL}%{?1:+%{1}}\
%{nil}\
%{expand:%%postun %{?1:%{1}-}modules-internal}\
/sbin/depmod -a %{KVERREL}%{?1:+%{1}}\
%{nil}
#
# This macro defines a %%post script for a kernel*-modules-partner package.
# It also defines a %%postun script that does the same thing.
# %%kernel_modules_partner_post [<subpackage>]
#
%define kernel_modules_partner_post() \
%{expand:%%post %{?1:%{1}-}modules-partner}\
/sbin/depmod -a %{KVERREL}%{?1:+%{1}}\
%{nil}\
%{expand:%%postun %{?1:%{1}-}modules-partner}\
/sbin/depmod -a %{KVERREL}%{?1:+%{1}}\
%{nil}
#
# This macro defines a %%post script for a kernel*-modules package.
# It also defines a %%postun script that does the same thing.
# %%kernel_modules_post [<subpackage>]
#
%define kernel_modules_post() \
%{expand:%%post %{?1:%{1}-}modules}\
/sbin/depmod -a %{KVERREL}%{?1:+%{1}}\
if [ ! -f %{_localstatedir}/lib/rpm-state/%{name}/installing_core_%{KVERREL}%{?1:+%{1}} ]; then\
mkdir -p %{_localstatedir}/lib/rpm-state/%{name}\
touch %{_localstatedir}/lib/rpm-state/%{name}/need_to_run_dracut_%{KVERREL}%{?1:+%{1}}\
fi\
%{nil}\
%{expand:%%postun %{?1:%{1}-}modules}\
/sbin/depmod -a %{KVERREL}%{?1:+%{1}}\
%{nil}\
%{expand:%%posttrans %{?1:%{1}-}modules}\
if [ -f %{_localstatedir}/lib/rpm-state/%{name}/need_to_run_dracut_%{KVERREL}%{?1:+%{1}} ]; then\
rm -f %{_localstatedir}/lib/rpm-state/%{name}/need_to_run_dracut_%{KVERREL}%{?1:+%{1}}\
echo "Running: dracut -f --kver %{KVERREL}%{?1:+%{1}}"\
dracut -f --kver "%{KVERREL}%{?1:+%{1}}" || exit $?\
fi\
%{nil}
#
# This macro defines a %%post script for a kernel*-modules-core package.
# %%kernel_modules_core_post [<subpackage>]
#
%define kernel_modules_core_post() \
%{expand:%%posttrans %{?1:%{1}-}modules-core}\
/sbin/depmod -a %{KVERREL}%{?1:+%{1}}\
%{nil}
# This macro defines a %%posttrans script for a kernel package.
# %%kernel_variant_posttrans [-v <subpackage>] [-u uki-suffix]
# More text can follow to go at the end of this variant's %%post.
#
%define kernel_variant_posttrans(v:u:) \
%{expand:%%posttrans %{?-v:%{-v*}-}%{!?-u*:core}%{?-u*:uki-%{-u*}}}\
%if 0%{!?fedora:1}\
if [ -x %{_sbindir}/weak-modules ]\
then\
%{_sbindir}/weak-modules --add-kernel %{KVERREL}%{?-v:+%{-v*}} || exit $?\
fi\
%endif\
rm -f %{_localstatedir}/lib/rpm-state/%{name}/installing_core_%{KVERREL}%{?-v:+%{-v*}}\
/bin/kernel-install add %{KVERREL}%{?-v:+%{-v*}} /lib/modules/%{KVERREL}%{?-v:+%{-v*}}/vmlinuz%{?-u:-%{-u*}.efi} || exit $?\
if [[ ! -e "/boot/symvers-%{KVERREL}%{?-v:+%{-v*}}.gz" ]]; then\
ln -s "/lib/modules/%{KVERREL}%{?-v:+%{-v*}}/symvers.gz" "/boot/symvers-%{KVERREL}%{?-v:+%{-v*}}.gz"\
command -v restorecon &>/dev/null && restorecon "/boot/symvers-%{KVERREL}%{?-v:+%{-v*}}.gz" \
fi\
%{nil}
#
# This macro defines a %%post script for a kernel package and its devel package.
# %%kernel_variant_post [-v <subpackage>] [-r <replace>]
# More text can follow to go at the end of this variant's %%post.
#
%define kernel_variant_post(v:r:) \
%{expand:%%kernel_devel_post %{?-v*}}\
%{expand:%%kernel_modules_post %{?-v*}}\
%{expand:%%kernel_modules_core_post %{?-v*}}\
%{expand:%%kernel_modules_extra_post %{?-v*}}\
%{expand:%%kernel_modules_internal_post %{?-v*}}\
%if 0%{!?fedora:1}\
%{expand:%%kernel_modules_partner_post %{?-v*}}\
%endif\
%{expand:%%kernel_variant_posttrans %{?-v*:-v %{-v*}}}\
%{expand:%%post %{?-v*:%{-v*}-}core}\
%{-r:\
if [ `uname -i` == "x86_64" -o `uname -i` == "i386" ] &&\
[ -f /etc/sysconfig/kernel ]; then\
/bin/sed -r -i -e 's/^DEFAULTKERNEL=%{-r*}$/DEFAULTKERNEL=kernel%{?-v:-%{-v*}}/' /etc/sysconfig/kernel || exit $?\
fi}\
mkdir -p %{_localstatedir}/lib/rpm-state/%{name}\
touch %{_localstatedir}/lib/rpm-state/%{name}/installing_core_%{KVERREL}%{?-v:+%{-v*}}\
%{nil}
#
# This macro defines a %%preun script for a kernel package.
# %%kernel_variant_preun [-v <subpackage>] [-u uki-suffix]
#
%define kernel_variant_preun(v:u:) \
%{expand:%%preun %{?-v:%{-v*}-}%{!?-u*:core}%{?-u*:uki-%{-u*}}}\
/bin/kernel-install remove %{KVERREL}%{?-v:+%{-v*}} || exit $?\
if [ -x %{_sbindir}/weak-modules ]\
then\
%{_sbindir}/weak-modules --remove-kernel %{KVERREL}%{?-v:+%{-v*}} || exit $?\
fi\
%{nil}
redhat: Add sub-RPM with a EFI unified kernel image for virtual machines Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2142102 Upstream Status: RHEL only The new 'kernel-unified-virt' sub-RPM is added on x86_64 targets. This contains an EFI application that provides a combined vmlinux, initrd and cmdline, as a so called 'unified kernel image'. The spec for this is defined by the boot loader specification https://uapi-group.org/specifications/specs/boot_loader_specification/ The key benefit of a unified kernel is that its secure boot signature covers the initrd and cmdline contents, allowing a trustworthy measured boot process with attestation, which is not practical with locally generated initrds/cmdlines. Since the initrd is pre-generated its contents have to be very generic, to be usable on a wide variety of deployments. To make this problem tractable, the sub-RPM targets only usage in virtual machines. With such a restriction, the initrd only needs a very small set of block driver modules present, in order to be usable across KVM, Hyper-V and Xen hypervisors which will cover essentially all common public and private clouds. Similarly the kernel cmdline cannot contain any host specific data, which means the root filesystem to mount needs to be able to be automatically detected. A virtual machine image intending to use this unified kernel package thus needs to comply with the discoverable partitions specification: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/ Based-on-patch-by: Daniel P. Berrangé <berrange@redhat.com> Based-on-patch-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
2022-11-07 09:21:43 +00:00
%if %{efiuki}
%kernel_variant_posttrans -u virt
%kernel_variant_preun -u virt
redhat: Add sub-RPM with a EFI unified kernel image for virtual machines Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2142102 Upstream Status: RHEL only The new 'kernel-unified-virt' sub-RPM is added on x86_64 targets. This contains an EFI application that provides a combined vmlinux, initrd and cmdline, as a so called 'unified kernel image'. The spec for this is defined by the boot loader specification https://uapi-group.org/specifications/specs/boot_loader_specification/ The key benefit of a unified kernel is that its secure boot signature covers the initrd and cmdline contents, allowing a trustworthy measured boot process with attestation, which is not practical with locally generated initrds/cmdlines. Since the initrd is pre-generated its contents have to be very generic, to be usable on a wide variety of deployments. To make this problem tractable, the sub-RPM targets only usage in virtual machines. With such a restriction, the initrd only needs a very small set of block driver modules present, in order to be usable across KVM, Hyper-V and Xen hypervisors which will cover essentially all common public and private clouds. Similarly the kernel cmdline cannot contain any host specific data, which means the root filesystem to mount needs to be able to be automatically detected. A virtual machine image intending to use this unified kernel package thus needs to comply with the discoverable partitions specification: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/ Based-on-patch-by: Daniel P. Berrangé <berrange@redhat.com> Based-on-patch-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
2022-11-07 09:21:43 +00:00
%endif
%kernel_variant_preun
%kernel_variant_post -r kernel-smp
%if %{with_pae}
%kernel_variant_preun -v lpae
%kernel_variant_post -v lpae -r (kernel|kernel-smp)
%endif
%if %{with_zfcpdump}
%kernel_variant_preun -v zfcpdump
%kernel_variant_post -v zfcpdump
%endif
%if %{with_arm64_64k}
%kernel_variant_preun -v 64k
%kernel_variant_post -v 64k
%endif
%if %{with_debug} && %{with_arm64_64k}
%kernel_variant_preun -v 64k-debug
%kernel_variant_post -v 64k-debug
%endif
%if %{with_realtime}
%kernel_variant_preun -v rt
%kernel_variant_post -v rt
%endif
%if %{with_debug} && %{with_realtime}
%kernel_variant_preun -v rt-debug
%kernel_variant_post -v rt-debug
%endif
%if %{with_realtime_arm64_64k}
%kernel_variant_preun -v rt-64k
%kernel_variant_post -v rt-64k
%endif
%if %{with_debug} && %{with_realtime_arm64_64k}
%kernel_variant_preun -v rt-64k-debug
%kernel_variant_post -v rt-64k-debug
%endif
%if %{with_debug}
redhat: Add sub-RPM with a EFI unified kernel image for virtual machines Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2142102 Upstream Status: RHEL only The new 'kernel-unified-virt' sub-RPM is added on x86_64 targets. This contains an EFI application that provides a combined vmlinux, initrd and cmdline, as a so called 'unified kernel image'. The spec for this is defined by the boot loader specification https://uapi-group.org/specifications/specs/boot_loader_specification/ The key benefit of a unified kernel is that its secure boot signature covers the initrd and cmdline contents, allowing a trustworthy measured boot process with attestation, which is not practical with locally generated initrds/cmdlines. Since the initrd is pre-generated its contents have to be very generic, to be usable on a wide variety of deployments. To make this problem tractable, the sub-RPM targets only usage in virtual machines. With such a restriction, the initrd only needs a very small set of block driver modules present, in order to be usable across KVM, Hyper-V and Xen hypervisors which will cover essentially all common public and private clouds. Similarly the kernel cmdline cannot contain any host specific data, which means the root filesystem to mount needs to be able to be automatically detected. A virtual machine image intending to use this unified kernel package thus needs to comply with the discoverable partitions specification: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/ Based-on-patch-by: Daniel P. Berrangé <berrange@redhat.com> Based-on-patch-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
2022-11-07 09:21:43 +00:00
%if %{efiuki}
%kernel_variant_posttrans -v debug -u virt
%kernel_variant_preun -v debug -u virt
redhat: Add sub-RPM with a EFI unified kernel image for virtual machines Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2142102 Upstream Status: RHEL only The new 'kernel-unified-virt' sub-RPM is added on x86_64 targets. This contains an EFI application that provides a combined vmlinux, initrd and cmdline, as a so called 'unified kernel image'. The spec for this is defined by the boot loader specification https://uapi-group.org/specifications/specs/boot_loader_specification/ The key benefit of a unified kernel is that its secure boot signature covers the initrd and cmdline contents, allowing a trustworthy measured boot process with attestation, which is not practical with locally generated initrds/cmdlines. Since the initrd is pre-generated its contents have to be very generic, to be usable on a wide variety of deployments. To make this problem tractable, the sub-RPM targets only usage in virtual machines. With such a restriction, the initrd only needs a very small set of block driver modules present, in order to be usable across KVM, Hyper-V and Xen hypervisors which will cover essentially all common public and private clouds. Similarly the kernel cmdline cannot contain any host specific data, which means the root filesystem to mount needs to be able to be automatically detected. A virtual machine image intending to use this unified kernel package thus needs to comply with the discoverable partitions specification: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/ Based-on-patch-by: Daniel P. Berrangé <berrange@redhat.com> Based-on-patch-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
2022-11-07 09:21:43 +00:00
%endif
%kernel_variant_preun -v debug
%kernel_variant_post -v debug
%endif
if [ -x /sbin/ldconfig ]
then
/sbin/ldconfig -X || exit $?
fi
###
### file lists
###
%if %{with_headers}
%files headers
/usr/include/*
%exclude %{_includedir}/cpufreq.h
%exclude %{_includedir}/internal/
%exclude %{_includedir}/perf/
%endif
%if %{with_cross_headers}
%files cross-headers
/usr/*-linux-gnu/include/*
%endif
%if %{with_kernel_abi_stablelists}
%files -n kernel-abi-stablelists
/lib/modules/kabi-*
%endif
%if %{with_kabidw_base}
%ifarch x86_64 s390x ppc64 ppc64le aarch64
%files kernel-kabidw-base-internal
%defattr(-,root,root)
/kabidw-base/%{_target_cpu}/*
%endif
%endif
# only some architecture builds need kernel-doc
%if %{with_doc}
%files doc
%defattr(-,root,root)
%{_datadir}/doc/kernel-doc-%{specversion}-%{pkgrelease}/Documentation/*
%dir %{_datadir}/doc/kernel-doc-%{specversion}-%{pkgrelease}/Documentation
%dir %{_datadir}/doc/kernel-doc-%{specversion}-%{pkgrelease}
%{_datadir}/doc/kernel-doc-%{specversion}-%{pkgrelease}/kernel.changelog.xz
%endif
%if %{with_perf}
%files -n perf
%{_bindir}/perf
%{_libdir}/libperf-jvmti.so
%dir %{_libexecdir}/perf-core
%{_libexecdir}/perf-core/*
%{_datadir}/perf-core/*
%{_mandir}/man[1-8]/perf*
%{_sysconfdir}/bash_completion.d/perf
%doc linux-%{KVERREL}/tools/perf/Documentation/examples.txt
%{_docdir}/perf-tip/tips.txt
%files -n python3-perf
%{python3_sitearch}/*
%files -n libperf
%{_libdir}/libperf.so.0
%{_libdir}/libperf.so.0.0.1
%files -n libperf-devel
%{_libdir}/libperf.so
%{_libdir}/pkgconfig/libperf.pc
%{_includedir}/perf/
%{_includedir}/internal/
%{_mandir}/man3/libperf.*
%{_mandir}/man7/libperf-counting.*
%{_mandir}/man7/libperf-sampling.*
%{_docdir}/libperf/
%if %{with_debuginfo}
%files -f perf-debuginfo.list -n perf-debuginfo
%files -f python3-perf-debuginfo.list -n python3-perf-debuginfo
%files -f libperf-debuginfo.list -n libperf-debuginfo
%endif
# with_perf
%endif
%if %{with_tools}
%ifnarch %{cpupowerarchs}
%files -n kernel-tools
%else
%files -n kernel-tools -f cpupower.lang
%{_bindir}/cpupower
%{_datadir}/bash-completion/completions/cpupower
%ifarch x86_64
%{_bindir}/centrino-decode
%{_bindir}/powernow-k8-decode
%endif
%{_unitdir}/cpupower.service
%{_mandir}/man[1-8]/cpupower*
%config(noreplace) %{_sysconfdir}/sysconfig/cpupower
%ifarch x86_64
%{_bindir}/x86_energy_perf_policy
%{_mandir}/man8/x86_energy_perf_policy*
%{_bindir}/turbostat
%{_mandir}/man8/turbostat*
%{_bindir}/intel-speed-select
%{_sbindir}/intel_sdsi
%endif
# cpupowerarchs
%endif
%{_bindir}/tmon
%{_bindir}/bootconfig
%{_bindir}/iio_event_monitor
%{_bindir}/iio_generic_buffer
%{_bindir}/lsiio
%{_bindir}/lsgpio
%{_bindir}/gpio-hammer
%{_bindir}/gpio-event-mon
%{_bindir}/gpio-watch
%{_mandir}/man1/kvm_stat*
%{_bindir}/kvm_stat
%{_unitdir}/kvm_stat.service
%config(noreplace) %{_sysconfdir}/logrotate.d/kvm_stat
%{_bindir}/page_owner_sort
%{_bindir}/slabinfo
%if %{with_debuginfo}
%files -f kernel-tools-debuginfo.list -n kernel-tools-debuginfo
%endif
%ifarch %{cpupowerarchs}
%files -n kernel-tools-libs
%{_libdir}/libcpupower.so.1
%{_libdir}/libcpupower.so.0.0.1
%files -n kernel-tools-libs-devel
%{_libdir}/libcpupower.so
%{_includedir}/cpufreq.h
%endif
%files -n rtla
%{_bindir}/rtla
%{_bindir}/hwnoise
%{_bindir}/osnoise
%{_bindir}/timerlat
%{_mandir}/man1/rtla-hwnoise.1.gz
%{_mandir}/man1/rtla-osnoise-hist.1.gz
%{_mandir}/man1/rtla-osnoise-top.1.gz
%{_mandir}/man1/rtla-osnoise.1.gz
%{_mandir}/man1/rtla-timerlat-hist.1.gz
%{_mandir}/man1/rtla-timerlat-top.1.gz
%{_mandir}/man1/rtla-timerlat.1.gz
%{_mandir}/man1/rtla.1.gz
%files -n rv
%{_bindir}/rv
%{_mandir}/man1/rv-list.1.gz
%{_mandir}/man1/rv-mon-wip.1.gz
%{_mandir}/man1/rv-mon-wwnr.1.gz
%{_mandir}/man1/rv-mon.1.gz
%{_mandir}/man1/rv.1.gz
# with_tools
%endif
%if %{with_selftests}
%files selftests-internal
%{_libexecdir}/ksamples
%{_libexecdir}/kselftests
%endif
# empty meta-package
%if %{with_up}
%ifnarch %nobuildarches noarch
%files
%endif
%endif
# This is %%{image_install_path} on an arch where that includes ELF files,
# or empty otherwise.
%define elf_image_install_path %{?kernel_image_elf:%{image_install_path}}
#
# This macro defines the %%files sections for a kernel package
# and its devel and debuginfo packages.
# %%kernel_variant_files [-k vmlinux] <use_vdso> <condition> <subpackage>
#
%define kernel_variant_files(k:) \
%if %{2}\
%{expand:%%files %{?1:-f kernel-%{?3:%{3}-}ldsoconf.list} %{?3:%{3}-}core}\
%{!?_licensedir:%global license %%doc}\
%%license linux-%{KVERREL}/COPYING-%{version}-%{release}\
/lib/modules/%{KVERREL}%{?3:+%{3}}/%{?-k:%{-k*}}%{!?-k:vmlinuz}\
%ghost /%{image_install_path}/%{?-k:%{-k*}}%{!?-k:vmlinuz}-%{KVERREL}%{?3:+%{3}}\
/lib/modules/%{KVERREL}%{?3:+%{3}}/.vmlinuz.hmac \
%ghost /%{image_install_path}/.vmlinuz-%{KVERREL}%{?3:+%{3}}.hmac \
%ifarch %{arm} aarch64\
/lib/modules/%{KVERREL}%{?3:+%{3}}/dtb \
%ghost /%{image_install_path}/dtb-%{KVERREL}%{?3:+%{3}} \
%endif\
rpmspec: correct the ghost initramfs attributes Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1977056 This is a cherry pick from the following rhel-8 change into kernel-ark: commit 88049ff66893839cb85731db809b1ba47a3a23f3 Author: Rafael Aquini <aquini@redhat.com> Date: Tue Jun 25 19:25:09 2019 -0400 [rpmspec] correct the ghost initramfs attributes Message-id: <0d44bbb391ffd1cee003581ffffb93ad315b4e27.1561490617.git.aquini@redhat.com> Patchwork-id: 265851 O-Subject: [RHEL8 PATCH] redhat: spec: correct the ghost initramfs attributes Bugzilla: 1678881 RH-Acked-by: Jarod Wilson <jarod@redhat.com> RH-Acked-by: Jan Stancek <jstancek@redhat.com> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1678881 Upstream Status: RHEL only Build Info: http://brewweb.devel.redhat.com/brew/taskinfo?taskID=22353984 This patch is a forward port of the following RHEL-7 commit: commit f9e549645b10405f8b12f07649327ea293a5a78a Author: Kyle Walker <kwalker@redhat.com> Date: Mon Feb 4 19:11:11 2019 -0500 [redhat] spec: Correct the ghost initramfs attributes Message-id: <20190204191110.4217-1-kwalker@redhat.com> Patchwork-id: 239860 O-Subject: [RHEL7 BZ 1571909] spec: Correct the ghost initramfs attributes Bugzilla: 1571909 RH-Acked-by: Tony Camuso <tcamuso@redhat.com> RH-Acked-by: Jarod Wilson <jarod@redhat.com> RH-Acked-by: Patrick Talbert <ptalbert@redhat.com> Bugzilla: 1571909 Message-id: <20190204191110.4217-1-kwalker@redhat.com> Patchwork-id: 239860 O-Subject: [RHEL7 BZ 1571909] spec: Correct the ghost initramfs attributes Bugzilla: 1571909 RH-Acked-by: Tony Camuso <tcamuso@redhat.com> RH-Acked-by: Jarod Wilson <jarod@redhat.com> RH-Acked-by: Patrick Talbert <ptalbert@redhat.com> Bugzilla: 1571909 Upstream Status: RHEL only Build Info: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=20067072 The initramfs ghost directive doesn't include the necessary attributes macro. When generating the initramfs, dracut sets the umask to 0077, which will result in 0600 as shown below. # dracut -f 2>/dev/null 1>&2 # ls -l /boot/initramfs-3.10.0-957.1.3.el7.x86_64.img -rw-------. 1 root root 21266044 Feb 4 12:09 /boot/initramfs-3.10.0-957.1.3.el7.x86_64.img But this doesn't match the specfile which currently assumes 0644 and results in RPM verification failures. # rpm -V kernel .M....... g /boot/initramfs-3.10.0-957.1.3.el7.x86_64.img The issue was masked in previous releases as ghost directives were never properly verified as indicated in BZ1395818. Resolved by applying a 0600 attribute set for ghost initramfs entries. Signed-off-by: Kyle Walker <kwalker@redhat.com> Signed-off-by: Jan Stancek <jstancek@redhat.com> Signed-off-by: Rafael Aquini <aquini@redhat.com> Signed-off-by: Herton R. Krzesinski <herton@redhat.com> Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
2021-07-20 20:12:32 +00:00
%attr(0600, root, root) /lib/modules/%{KVERREL}%{?3:+%{3}}/System.map\
%ghost %attr(0600, root, root) /boot/System.map-%{KVERREL}%{?3:+%{3}}\
%dir /lib/modules\
%dir /lib/modules/%{KVERREL}%{?3:+%{3}}\
/lib/modules/%{KVERREL}%{?3:+%{3}}/symvers.gz\
/lib/modules/%{KVERREL}%{?3:+%{3}}/config\
/lib/modules/%{KVERREL}%{?3:+%{3}}/modules.builtin*\
rpmspec: correct the ghost initramfs attributes Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1977056 This is a cherry pick from the following rhel-8 change into kernel-ark: commit 88049ff66893839cb85731db809b1ba47a3a23f3 Author: Rafael Aquini <aquini@redhat.com> Date: Tue Jun 25 19:25:09 2019 -0400 [rpmspec] correct the ghost initramfs attributes Message-id: <0d44bbb391ffd1cee003581ffffb93ad315b4e27.1561490617.git.aquini@redhat.com> Patchwork-id: 265851 O-Subject: [RHEL8 PATCH] redhat: spec: correct the ghost initramfs attributes Bugzilla: 1678881 RH-Acked-by: Jarod Wilson <jarod@redhat.com> RH-Acked-by: Jan Stancek <jstancek@redhat.com> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1678881 Upstream Status: RHEL only Build Info: http://brewweb.devel.redhat.com/brew/taskinfo?taskID=22353984 This patch is a forward port of the following RHEL-7 commit: commit f9e549645b10405f8b12f07649327ea293a5a78a Author: Kyle Walker <kwalker@redhat.com> Date: Mon Feb 4 19:11:11 2019 -0500 [redhat] spec: Correct the ghost initramfs attributes Message-id: <20190204191110.4217-1-kwalker@redhat.com> Patchwork-id: 239860 O-Subject: [RHEL7 BZ 1571909] spec: Correct the ghost initramfs attributes Bugzilla: 1571909 RH-Acked-by: Tony Camuso <tcamuso@redhat.com> RH-Acked-by: Jarod Wilson <jarod@redhat.com> RH-Acked-by: Patrick Talbert <ptalbert@redhat.com> Bugzilla: 1571909 Message-id: <20190204191110.4217-1-kwalker@redhat.com> Patchwork-id: 239860 O-Subject: [RHEL7 BZ 1571909] spec: Correct the ghost initramfs attributes Bugzilla: 1571909 RH-Acked-by: Tony Camuso <tcamuso@redhat.com> RH-Acked-by: Jarod Wilson <jarod@redhat.com> RH-Acked-by: Patrick Talbert <ptalbert@redhat.com> Bugzilla: 1571909 Upstream Status: RHEL only Build Info: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=20067072 The initramfs ghost directive doesn't include the necessary attributes macro. When generating the initramfs, dracut sets the umask to 0077, which will result in 0600 as shown below. # dracut -f 2>/dev/null 1>&2 # ls -l /boot/initramfs-3.10.0-957.1.3.el7.x86_64.img -rw-------. 1 root root 21266044 Feb 4 12:09 /boot/initramfs-3.10.0-957.1.3.el7.x86_64.img But this doesn't match the specfile which currently assumes 0644 and results in RPM verification failures. # rpm -V kernel .M....... g /boot/initramfs-3.10.0-957.1.3.el7.x86_64.img The issue was masked in previous releases as ghost directives were never properly verified as indicated in BZ1395818. Resolved by applying a 0600 attribute set for ghost initramfs entries. Signed-off-by: Kyle Walker <kwalker@redhat.com> Signed-off-by: Jan Stancek <jstancek@redhat.com> Signed-off-by: Rafael Aquini <aquini@redhat.com> Signed-off-by: Herton R. Krzesinski <herton@redhat.com> Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
2021-07-20 20:12:32 +00:00
%ghost %attr(0600, root, root) /boot/symvers-%{KVERREL}%{?3:+%{3}}.gz\
%ghost %attr(0600, root, root) /boot/initramfs-%{KVERREL}%{?3:+%{3}}.img\
%ghost %attr(0644, root, root) /boot/config-%{KVERREL}%{?3:+%{3}}\
%{expand:%%files -f kernel-%{?3:%{3}-}modules-core.list %{?3:%{3}-}modules-core}\
%dir /lib/modules\
%dir /lib/modules/%{KVERREL}%{?3:+%{3}}\
%dir /lib/modules/%{KVERREL}%{?3:+%{3}}/kernel\
/lib/modules/%{KVERREL}%{?3:+%{3}}/build\
/lib/modules/%{KVERREL}%{?3:+%{3}}/source\
/lib/modules/%{KVERREL}%{?3:+%{3}}/updates\
/lib/modules/%{KVERREL}%{?3:+%{3}}/weak-updates\
/lib/modules/%{KVERREL}%{?3:+%{3}}/systemtap\
%{_datadir}/doc/kernel-keys/%{KVERREL}%{?3:+%{3}}\
%if %{1}\
/lib/modules/%{KVERREL}%{?3:+%{3}}/vdso\
%endif\
/lib/modules/%{KVERREL}%{?3:+%{3}}/modules.block\
/lib/modules/%{KVERREL}%{?3:+%{3}}/modules.drm\
/lib/modules/%{KVERREL}%{?3:+%{3}}/modules.modesetting\
/lib/modules/%{KVERREL}%{?3:+%{3}}/modules.networking\
/lib/modules/%{KVERREL}%{?3:+%{3}}/modules.order\
%ghost %attr(0644, root, root) /lib/modules/%{KVERREL}%{?3:+%{3}}/modules.alias\
%ghost %attr(0644, root, root) /lib/modules/%{KVERREL}%{?3:+%{3}}/modules.alias.bin\
%ghost %attr(0644, root, root) /lib/modules/%{KVERREL}%{?3:+%{3}}/modules.builtin.alias.bin\
%ghost %attr(0644, root, root) /lib/modules/%{KVERREL}%{?3:+%{3}}/modules.builtin.bin\
%ghost %attr(0644, root, root) /lib/modules/%{KVERREL}%{?3:+%{3}}/modules.dep\
%ghost %attr(0644, root, root) /lib/modules/%{KVERREL}%{?3:+%{3}}/modules.dep.bin\
%ghost %attr(0644, root, root) /lib/modules/%{KVERREL}%{?3:+%{3}}/modules.devname\
%ghost %attr(0644, root, root) /lib/modules/%{KVERREL}%{?3:+%{3}}/modules.softdep\
%ghost %attr(0644, root, root) /lib/modules/%{KVERREL}%{?3:+%{3}}/modules.symbols\
%ghost %attr(0644, root, root) /lib/modules/%{KVERREL}%{?3:+%{3}}/modules.symbols.bin\
%{expand:%%files -f kernel-%{?3:%{3}-}modules.list %{?3:%{3}-}modules}\
%{expand:%%files %{?3:%{3}-}devel}\
%defverify(not mtime)\
/usr/src/kernels/%{KVERREL}%{?3:+%{3}}\
%{expand:%%files %{?3:%{3}-}devel-matched}\
kernel packaging: Fix extra namespace collision commit b2819ae00d4cd6380e1151dd0628f32e19a85d6f Author: Prarit Bhargava <prarit@redhat.com> Date: Fri Jun 7 18:00:37 2019 -0400 [rpmspec] kernel packaging: Fix extra namespace collision Message-id: <20190607180038.20685-4-prarit@redhat.com> Patchwork-id: 263188 O-Subject: [RHEL8.1 BZ 1699868 v4 3/4] kernel packaging: Fix extra namespace collision Bugzilla: 1699868 RH-Acked-by: Marcelo Leitner <mleitner@redhat.com> RH-Acked-by: Laura Abbott <labbott@redhat.com> Bugzilla: http://bugzilla.redhat.com/1699868 The kernel-modules-extra package collides with the 3rd party driver location, /lib/modules/'uname -r'/extra. When the kernel-modules-extra package has already been installed and a new kernel is installed, the result is a significant increase to the install time of a kernel and the wrong kernel modules being loaded into the new kernel. The /lib/modules/'uname -r'/extra directory is designated as a spot where 3rd party vendors can place their out-of-box drivers. When a new kernel is installed (specifically the kernel-core package) a call is made to /usr/sbin/weak-modules (from the kmod package) to examine drivers in the previously installed kernels' extra directories to bring those drivers forward into the new kernel. The kernel-modules-extra package installs modules into the /extra directory. As a result, when /usr/sbin/weak-modules is executed it brings the modules from kernel-modules-extra forward into the new kernel as well. This is a critical mistake as the wrong modules have now been brought forward. Additionally, /usr/sbin/weak-modules takes longer to execute every time a new kernel is installed. After five kernels are installed the time to install the kernel-core package climbs to approximately 10 minutes. After some code investigation and discussion with the authors of the original Fedora code, and input from Herton, this can be avoided by installing the kernel-modules-extra modules to their original directories in 8.0.z. The existing build process copies all the modules into a temporary area called restore, and leaving the original modules directory as a work area. The modules listed in mod-extra.list are copied to extra/ and removed from the work area, and core.list and modules.list files are created. The restore area is then copied back, and the rpm build process continues. My changes create a mod-extra.list and a mod-internal.list (similar to core.list and modules.list), and remove the files from the work area so that the core.list and modules.list can be created. The list files are used later on to create dynamic %files sections for the subpackages. Remove the /lib/modules/'uname -r'/extra installation path from the kernel-modules-extra package and install the modules in their original directories. v4: Make modules-internal.list and modules-extra.list use consistent (mleitner). Fix cat usage in spec file and scripts (jbenc). Signed-off-by: Prarit Bhargava <prarit@redhat.com> Cc: Herton R. Krzesinski <herton@redhat.com> Cc: Prarit Bhargava <prarit@redhat.com> Cc: Marcelo Leitner <mleitner@redhat.com> Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
2020-03-31 17:22:23 +00:00
%{expand:%%files -f kernel-%{?3:%{3}-}modules-extra.list %{?3:%{3}-}modules-extra}\
%config(noreplace) /etc/modprobe.d/*-blacklist.conf\
redhat/kernel.spec.template: Fix internal "File listed twice" errors JIRA: INTERNAL Conflicts: kernel-rt code conflicts with the original patch, but code has been modified to represent the orignal commit's intent. commit f17e62acbe2908e2b45ef7dc7e6f47ce25bd3cf6 Author: Prarit Bhargava <prarit@redhat.com> Date: Sat Jan 21 21:21:31 2023 -0500 redhat/kernel.spec.template: Fix internal "File listed twice" errors Executing an rpm build results in a "File listed twice" error for every file in the modules-internal subpackage. The modules-internal subpackage's file list is created by mod-denylist.sh. The file contains both the path to the internal directory and separately lists out each file. ie) the contents of the file list are <snip> /lib/modules/6.2.0-0.rc4.7287904c8771.33.test.fc36.x86_64/internal/net/mptcp/mptcp_crypto_test.ko.xz/lib/modules/6.2.0-0.rc4.7287904c8771.33.test.fc36.x86_64/internal/net/mptcp/mptcp_token_test.ko.xz /lib/modules/6.2.0-0.rc4.7287904c8771.33.test.fc36.x86_64/internal/sound/soc/soc-topology-test.ko.xz/lib/modules/6.2.0-0.rc4.7287904c8771.33.test.fc36.x86_64/internal/sound/soc/soc-utils-test.ko.xz /lib/modules/6.2.0-0.rc4.7287904c8771.33.test.fc36.x86_64/internal The rpm build interprets this as including each file individually and also recursively including the files below the internal directory, ie) each file is listed twice. The rpm build then throws errors for each file: File listed twice: /lib/modules/6.2.0-0.rc4.7287904c8771.33.test.fc36.x86_64/internal/net/mptcp/mptcp_crypto_test.ko.xz File listed twice: /lib/modules/6.2.0-0.rc4.7287904c8771.33.test.fc36.x86_64/internal/net/mptcp/mptcp_token_test.ko.xz File listed twice: /lib/modules/6.2.0-0.rc4.7287904c8771.33.test.fc36.x86_64/internal/sound/soc/soc-topology-test.ko.xz File listed twice: /lib/modules/6.2.0-0.rc4.7287904c8771.33.test.fc36.x86_64/internal/sound/soc/soc-utils-test.ko.xz Fix the "File listed twice" errors by only including the internal directory in the modules-internal subpackage file list. Additional fix: Make the same fix for the modules-partner subpackge. Signed-off-by: Prarit Bhargava <prarit@redhat.com> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
2023-09-26 18:58:10 +00:00
%{expand:%%files %{?3:%{3}-}modules-internal}\
/lib/modules/%{KVERREL}%{?3:+%{3}}/internal\
%if 0%{!?fedora:1}\
redhat/kernel.spec.template: Fix internal "File listed twice" errors JIRA: INTERNAL Conflicts: kernel-rt code conflicts with the original patch, but code has been modified to represent the orignal commit's intent. commit f17e62acbe2908e2b45ef7dc7e6f47ce25bd3cf6 Author: Prarit Bhargava <prarit@redhat.com> Date: Sat Jan 21 21:21:31 2023 -0500 redhat/kernel.spec.template: Fix internal "File listed twice" errors Executing an rpm build results in a "File listed twice" error for every file in the modules-internal subpackage. The modules-internal subpackage's file list is created by mod-denylist.sh. The file contains both the path to the internal directory and separately lists out each file. ie) the contents of the file list are <snip> /lib/modules/6.2.0-0.rc4.7287904c8771.33.test.fc36.x86_64/internal/net/mptcp/mptcp_crypto_test.ko.xz/lib/modules/6.2.0-0.rc4.7287904c8771.33.test.fc36.x86_64/internal/net/mptcp/mptcp_token_test.ko.xz /lib/modules/6.2.0-0.rc4.7287904c8771.33.test.fc36.x86_64/internal/sound/soc/soc-topology-test.ko.xz/lib/modules/6.2.0-0.rc4.7287904c8771.33.test.fc36.x86_64/internal/sound/soc/soc-utils-test.ko.xz /lib/modules/6.2.0-0.rc4.7287904c8771.33.test.fc36.x86_64/internal The rpm build interprets this as including each file individually and also recursively including the files below the internal directory, ie) each file is listed twice. The rpm build then throws errors for each file: File listed twice: /lib/modules/6.2.0-0.rc4.7287904c8771.33.test.fc36.x86_64/internal/net/mptcp/mptcp_crypto_test.ko.xz File listed twice: /lib/modules/6.2.0-0.rc4.7287904c8771.33.test.fc36.x86_64/internal/net/mptcp/mptcp_token_test.ko.xz File listed twice: /lib/modules/6.2.0-0.rc4.7287904c8771.33.test.fc36.x86_64/internal/sound/soc/soc-topology-test.ko.xz File listed twice: /lib/modules/6.2.0-0.rc4.7287904c8771.33.test.fc36.x86_64/internal/sound/soc/soc-utils-test.ko.xz Fix the "File listed twice" errors by only including the internal directory in the modules-internal subpackage file list. Additional fix: Make the same fix for the modules-partner subpackge. Signed-off-by: Prarit Bhargava <prarit@redhat.com> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
2023-09-26 18:58:10 +00:00
%{expand:%%files %{?3:%{3}-}modules-partner}\
/lib/modules/%{KVERREL}%{?3:+%{3}}/partner\
%endif\
%if %{with_debuginfo}\
%ifnarch noarch\
%{expand:%%files -f debuginfo%{?3}.list %{?3:%{3}-}debuginfo}\
%endif\
%endif\
redhat: Add sub-RPM with a EFI unified kernel image for virtual machines Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2142102 Upstream Status: RHEL only The new 'kernel-unified-virt' sub-RPM is added on x86_64 targets. This contains an EFI application that provides a combined vmlinux, initrd and cmdline, as a so called 'unified kernel image'. The spec for this is defined by the boot loader specification https://uapi-group.org/specifications/specs/boot_loader_specification/ The key benefit of a unified kernel is that its secure boot signature covers the initrd and cmdline contents, allowing a trustworthy measured boot process with attestation, which is not practical with locally generated initrds/cmdlines. Since the initrd is pre-generated its contents have to be very generic, to be usable on a wide variety of deployments. To make this problem tractable, the sub-RPM targets only usage in virtual machines. With such a restriction, the initrd only needs a very small set of block driver modules present, in order to be usable across KVM, Hyper-V and Xen hypervisors which will cover essentially all common public and private clouds. Similarly the kernel cmdline cannot contain any host specific data, which means the root filesystem to mount needs to be able to be automatically detected. A virtual machine image intending to use this unified kernel package thus needs to comply with the discoverable partitions specification: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/ Based-on-patch-by: Daniel P. Berrangé <berrange@redhat.com> Based-on-patch-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
2022-11-07 09:21:43 +00:00
%if %{efiuki}\
%if "%{3}" != "rt" && "%{3}" != "rt-debug" && "%{3}" != "rt-64k" && "%{3}" != "rt-64k-debug"\
redhat: Add sub-RPM with a EFI unified kernel image for virtual machines Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2142102 Upstream Status: RHEL only The new 'kernel-unified-virt' sub-RPM is added on x86_64 targets. This contains an EFI application that provides a combined vmlinux, initrd and cmdline, as a so called 'unified kernel image'. The spec for this is defined by the boot loader specification https://uapi-group.org/specifications/specs/boot_loader_specification/ The key benefit of a unified kernel is that its secure boot signature covers the initrd and cmdline contents, allowing a trustworthy measured boot process with attestation, which is not practical with locally generated initrds/cmdlines. Since the initrd is pre-generated its contents have to be very generic, to be usable on a wide variety of deployments. To make this problem tractable, the sub-RPM targets only usage in virtual machines. With such a restriction, the initrd only needs a very small set of block driver modules present, in order to be usable across KVM, Hyper-V and Xen hypervisors which will cover essentially all common public and private clouds. Similarly the kernel cmdline cannot contain any host specific data, which means the root filesystem to mount needs to be able to be automatically detected. A virtual machine image intending to use this unified kernel package thus needs to comply with the discoverable partitions specification: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/ Based-on-patch-by: Daniel P. Berrangé <berrange@redhat.com> Based-on-patch-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
2022-11-07 09:21:43 +00:00
%{expand:%%files %{?3:%{3}-}uki-virt}\
%dir /lib/modules\
%dir /lib/modules/%{KVERREL}%{?3:+%{3}}\
%attr(0600, root, root) /lib/modules/%{KVERREL}%{?3:+%{3}}/System.map\
/lib/modules/%{KVERREL}%{?3:+%{3}}/symvers.gz\
/lib/modules/%{KVERREL}%{?3:+%{3}}/config\
/lib/modules/%{KVERREL}%{?3:+%{3}}/modules.builtin*\
%attr(0644, root, root) /lib/modules/%{KVERREL}%{?3:+%{3}}/%{?-k:%{-k*}}%{!?-k:vmlinuz}-virt.efi\
%attr(0644, root, root) /lib/modules/%{KVERREL}%{?3:+%{3}}/.%{?-k:%{-k*}}%{!?-k:vmlinuz}-virt.efi.hmac\
%ghost /%{image_install_path}/efi/EFI/Linux/%{?-k:%{-k*}}%{!?-k:*}-%{KVERREL}%{?3:+%{3}}.efi\
%{expand:%%files %{?3:%{3}-}uki-virt-addons}\
/lib/modules/%{KVERREL}%{?3:+%{3}}/%{?-k:%{-k*}}%{!?-k:vmlinuz}-virt.efi.extra.d/ \
/lib/modules/%{KVERREL}%{?3:+%{3}}/%{?-k:%{-k*}}%{!?-k:vmlinuz}-virt.efi.extra.d/*.addon.efi\
redhat: Add sub-RPM with a EFI unified kernel image for virtual machines Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2142102 Upstream Status: RHEL only The new 'kernel-unified-virt' sub-RPM is added on x86_64 targets. This contains an EFI application that provides a combined vmlinux, initrd and cmdline, as a so called 'unified kernel image'. The spec for this is defined by the boot loader specification https://uapi-group.org/specifications/specs/boot_loader_specification/ The key benefit of a unified kernel is that its secure boot signature covers the initrd and cmdline contents, allowing a trustworthy measured boot process with attestation, which is not practical with locally generated initrds/cmdlines. Since the initrd is pre-generated its contents have to be very generic, to be usable on a wide variety of deployments. To make this problem tractable, the sub-RPM targets only usage in virtual machines. With such a restriction, the initrd only needs a very small set of block driver modules present, in order to be usable across KVM, Hyper-V and Xen hypervisors which will cover essentially all common public and private clouds. Similarly the kernel cmdline cannot contain any host specific data, which means the root filesystem to mount needs to be able to be automatically detected. A virtual machine image intending to use this unified kernel package thus needs to comply with the discoverable partitions specification: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/ Based-on-patch-by: Daniel P. Berrangé <berrange@redhat.com> Based-on-patch-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
2022-11-07 09:21:43 +00:00
%endif\
%endif\
%if %{?3:1} %{!?3:0}\
%{expand:%%files %{3}}\
%endif\
%if %{with_gcov}\
%ifnarch %nobuildarches noarch\
%{expand:%%files -f kernel-%{?3:%{3}-}gcov.list %{?3:%{3}-}gcov}\
%endif\
%endif\
%endif\
%{nil}
%kernel_variant_files %{_use_vdso} %{with_up}
%kernel_variant_files %{_use_vdso} %{with_debug} debug
%if %{with_arm64_64k}
%kernel_variant_files %{_use_vdso} %{with_debug} 64k-debug
%endif
%kernel_variant_files %{_use_vdso} %{with_realtime} rt
%if %{with_realtime}
%kernel_variant_files %{_use_vdso} %{with_debug} rt-debug
%endif
%if %{with_realtime_arm64_64k}
%kernel_variant_files %{_use_vdso} %{with_debug} rt-64k-debug
%endif
%if %{with_debug_meta}
%files debug
%files debug-core
%files debug-devel
%files debug-devel-matched
%files debug-modules
%files debug-modules-core
%files debug-modules-extra
%if %{with_arm64_64k}
%files 64k-debug
%files 64k-debug-core
%files 64k-debug-devel
%files 64k-debug-devel-matched
%files 64k-debug-modules
%files 64k-debug-modules-extra
%endif
%endif
%kernel_variant_files %{use_vdso} %{with_pae} lpae
%kernel_variant_files %{_use_vdso} %{with_zfcpdump} zfcpdump
%kernel_variant_files %{_use_vdso} %{with_arm64_64k} 64k
%kernel_variant_files %{_use_vdso} %{with_realtime_arm64_64k} rt-64k
%define kernel_variant_ipaclones(k:) \
%if %{1}\
%if %{with_ipaclones}\
%{expand:%%files %{?2:%{2}-}ipaclones-internal}\
%defattr(-,root,root)\
%defverify(not mtime)\
/usr/src/kernels/%{KVERREL}%{?2:+%{2}}-ipaclones\
%endif\
%endif\
%{nil}
%kernel_variant_ipaclones %{with_up}
# plz don't put in a version string unless you're going to tag
# and build.
#
#
%changelog
%%SPECCHANGELOG%%
###
# The following Emacs magic makes C-c C-e use UTC dates.
# Local Variables:
# rpm-change-log-uses-utc: t
# End:
###