Hi,
> > Sure. Having a feature page drawing that big picture would
be helpful
> > for these discussions I think ...
>
> Definitely a system wide change. While there are some logistics to
> work out on the kernel side, most of the work is packaging. I would
> guess timelines will need to be defined by the teams where code is
> needed.
https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1
Resuming that discussion. State of affairs:
Test packages are available:
https://copr.fedorainfracloud.org/coprs/kraxel/unified.kernel/
Kickstart install files and helper scripts:
https://gitlab.com/kraxel/fedora-uki
Prebuilt qemu VM test images:
https://www.kraxel.org/fedora-uki/
Right now I'm trying to figure how to handle kernel installs best.
Currently the kickstart files use ...
touch /etc/kernel/install.d/20-grub.install
touch /etc/kernel/install.d/50-dracut.install
.. to avoid kernel-core post-install creating a loader/entries/*.conf
snippet and dracut creating an (unused) initrd. Which is ok for a
Proof-of-Concept, but clearly a non-starter as long-term solution.
I've played around a bit with kernel-install script plugins trying to
detect the presence of a unified kernel image and change behavior then.
That feels a bit hackish though, and I suspect making that robust and
covering all corner cases (like switching between unified and
non-unified kernels) will be next to impossible.
I think a better way forward is to have strictly separate rpms for
kernels and modules. Today 'kernel-core' has both the (non-unified)
kernel binary and the essential modules. Due to the modules being in
there it must be installed even if we don't want use the kernel binary.
So how about splitting 'kernel-core' into a modules and a kernel binary
package? Like this:
kernel-modules-core - the modules from current 'kernel-core'
kernel-modules-standard - current 'kernel-modules' renamed (maybe
skip rename, but I think it'll be less
confusing that way).
kernel-modules-{extra,internal} - no changes
kernel-binary-bare - the kernel binary from current 'kernel-core'
kernel-binary-uki-virt - unified kernel (same as 'kernel-unified-virt'
in the test package repo).
kernel-{doc,tools*,headers,...} - no changes
With that in place kernel-binary-* packages are self-contained. They
just install/remove the kernel from /boot and/or ESP on install/remove.
No need to check whenever *other* packages are present and change
behavior based on that.
Comments?
take care,
Gerd