On 05/02/2013 09:06 PM, Josh Boyer wrote:
> On Fri, Apr 05, 2013 at 02:13:18PM +0200, Harald Hoyer wrote:
>> Am 04.04.2013 22:17, schrieb Peter Jones:
>>> 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.
>>>>
>>>> This patch is part of an upstream coordination, intended to unify the
various
>>>> ways distributions handle:
>>>>
>>>> - 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
>>>>
>>>> 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
>>>
>>> Is there git repo for this other than just the normal systemd repo?
>>> When I look there right now I don't see very much - it looks like it
>>> only handles gummy-boot - before we do this, what's the plan for all
the
>>> architectures we support that /don't/ work with gummy-boot style
configs?
>>> Right now that's basically everything except x86, and even that
isn't
>>> really fully fleshed out yet.
>>>
>>> Too be honest, kernel-install as it stands is a bit distasteful -
what's
>>> the point of breaking everything out into plugin directories if you're
>>> not going to handle generation of /boot/loader/entries through a plugin?
>>> That means if you're hacking on it or just trying to figure out what
>>> happened on a machine, you have to go looking at both the plugin
>>> directory and the script that runs it. All of the stuff to manage
>>> /boot/loader/entries should be moved into a plugin to avoid that.
>>>
>>> It should be possible to re-factor new-kernel-package to be something we
>>> can run from your plugin directories, but we should talk about what that
>>> looks like before we do something like this to the kernel package and
>>> simply break everything.
>>>
>>
>> We want to have a distro agnostic API for installing the kernel. new-kernel-pkg
>> is fedora only and with systemd we provide tools for every distribution.
>>
>> dracut (also not fedora-only) already ships with a plugin for kernel-install.
>>
>> Other distributions start to make use of kernel-install right now.
>>
>> Changing the fedora kernel.spec today would not *break* anything, because
>> kernel-install is currently patched in fedora to call new-kernel-pkg.
>>
http://pkgs.fedoraproject.org/cgit/systemd.git/tree/kernel-install-grubby...
>>
>> It would be great to convert grubby to hook into the kernel-install callouts
>> instead of being called from new-kernel-package, but this is an optional next
>> step, that you would need to decide on, if you agree. It does not affect the
>> introduction of kernel-install at this point, nothing should break.
>
> So while things aren't going to break, this doesn't really address
> Peter's question of why the loader entries aren't also handled via
> plugins, does it?
>
> I'd like to get some resolution on this by 3.10-rc1 so we can get it
> into rawhide, but it does seem like a fair question. Maybe I missed the
> answer somewhere.
>
> josh
fixed
http://cgit.freedesktop.org/systemd/systemd/commit/?id=8f51399e75e5d0d074...
Great. I'm working on adding your kernel.spec patch today. The changes
I've included are the bump in the dracut version, prereq'ing systemd >=
203-2 instead of 200, and dropping the depmod call in the posttrans
macro.
Assuming it works fine in my testing on a rawhide VM, it should make
rawhide tomorrow. If I hit a problem, I'll reply here. If anyone else
has questions/comments, now would be the time to make them.
josh