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