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!