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.
--
Peter