kernel.spec kernel-install integration
Harald Hoyer
harald at redhat.com
Thu Apr 4 13:53:11 UTC 2013
Am 04.04.2013 15:12, schrieb Josh Boyer:
> On Thu, Apr 04, 2013 at 07:48:14AM +0200, Harald Hoyer wrote:
>> Hi Josh,
>>
>> as mentioned on IRC, here is the patch for the rawhide kernel.spec.
>
> I'm on PTO the rest of the week, but I wanted to ask a few quick
> questions.
>
>> This patch is part of an upstream coordination, intended to unify the various
>> ways distributions handle:
>
> Has the change to the kernel makefiles to use this been sent upstream
> yet? I've been keeping an eye out for it and haven't seen it.
>
>> - installation of kernels in the system
>> - create the matching initrds; hooking up the various implementations of
>> initramfs generators into the kernel package installation process
>> - optionally/automatically create bootable rescue images to be able to recover
>> from failures:
>> https://fedoraproject.org/wiki/Features/DracutHostOnly
>
> DracutHostOnly is targeted at F19, but the switch to kernel-install is
> something we're discussing for F20, correct?
Yes, but the current (F19) infrastructure does not support plugging in well, so
the new one will be an improvement here.
>
>> All the above functionality is provided by the “kernel-install” tool:
>> http://www.freedesktop.org/software/systemd/man/kernel-install.html
>>
>> It features:
>> - flexible hookup/plugin directories to manage kernel installation and
>> uninstallation. initrd, bootloader, rescue image management, all plug into
>> that facility.
>>
>> - strict separation of distribution-supplied logic and local customization
>> logic; system administrators are able to overwrite and replace/extend any part
>> of the default logic if needed
>>
>> - hide distribution-specific logic behind a standardized command line interface
>>
>> - unify the custom kernel installation from the source tree with the usual
>> kernel package installation; like the current /sbin/installkernel
>
> We had briefly discussed systemd providing /sbin/installkernel to
> facilitate the transition from grubby to kernel-install. Is that
> something that's being done for now?
We want to eat our dogfood first before providing a patch to the kernel-ML, so
they can't say: "Hey, your own kernel.spec does not use this, so why should we?"
>
>> diff --git a/kernel.spec b/kernel.spec
>> index a2f1f25..09aef02 100644
>> --- a/kernel.spec
>> +++ b/kernel.spec
>> @@ -456,7 +456,7 @@ Summary: The Linux kernel
>> # Packages that need to be installed before the kernel is, because the %%post
>> # scripts use them.
>> #
>> -%define kernel_prereq fileutils, module-init-tools >= 3.16-4, initscripts >= 8.11.1-1, grubby >= 8.3-1
>> +%define kernel_prereq fileutils, module-init-tools >= 3.16-4, initscripts >= 8.11.1-1, systemd >= 200
>> %define initrd_prereq dracut >= 001-7
>
> I'm curious if kernel-install depends on anything in dracut in a version
> newer than 001-7. That's pretty old at this point.
Well, yes... good point.
%define initrd_prereq dracut >= 027
>
>> #
>> @@ -479,8 +479,7 @@ Provides: kernel-omap-uname-r = %{KVERREL}%{?1:.%{1}}\
>> Requires(pre): %{kernel_prereq}\
>> Requires(pre): %{initrd_prereq}\
>> Requires(pre): linux-firmware >= 20120206-0.1.git06c8f81\
>> -Requires(post): /sbin/new-kernel-pkg\
>> -Requires(preun): /sbin/new-kernel-pkg\
>> +Requires(preun): systemd >= 200\
>
> We still need the Requires(post) here, don't we? We're using
> kernel-install in posttrans.
No..
1. posttrans is after the rpm transaction, so (pre) is not needed
2. and we also already have
Requires(pre): %{kernel_prereq}
which includes systemd >= 200
>
>> Conflicts: %{kernel_dot_org_conflicts}\
>> Conflicts: %{package_conflicts}\
>> %{expand:%%{?kernel%{?1:_%{1}}_conflicts:Conflicts: %%{kernel%{?1:_%{1}}_conflicts}}}\
>> @@ -2064,8 +2063,8 @@ fi\
>> #
>> %define kernel_variant_posttrans() \
>> %{expand:%%posttrans %{?1}}\
>> -/sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --mkinitrd --dracut --depmod --update %{KVERREL}%{?-v:.%{-v*}} || exit $?\
>> -/sbin/new-kernel-pkg --package kernel%{?1:-%{1}} --rpmposttrans %{KVERREL}%{?1:.%{1}} || exit $?\
>> +/sbin/depmod -a %{KVERREL}%{?1:.%{1}} || exit $?;\
>> +/bin/kernel-install add %{KVERREL}%{?1:.%{1}} /%{image_install_path}/vmlinuz-%{KVERREL}%{?1:.%{1}} || exit $?\
>> %{nil}
>
> Is there a reason kernel-install doesn't run depmod itself?
We can do that, too .. true. And even plug that in the callout structure.
/usr/lib/kernel/install.d/49-depmod.install
/usr/lib/kernel/install.d/50-dracut.install
/usr/lib/kernel/install.d/51-dracut-rescue.install
Thanks for the comments!
More information about the kernel
mailing list