On Tue, Dec 20, 2022 at 08:42:14PM +0100, Björn Persson wrote:
> Main motivation for this move is to make the distro more robust
and more secure.
Improving security would be great, but it must be done in a way that
allows the sysadmin to configure and repair the system and authorize
the new configuration.
> Switching the whole distro over to unified kernels quickly is not
> realistic though. Too many features are depending on the current
> workflow with a host-specific initrd (and host-specific kernel command
> line), which is fundamentally incompatible with unified kernels where
> everybody will have the same initrd and command line. Thats why there
> is 'Phase 1' in title, so we can have more Phases in future releases
> 😃
Whew! So usable kernels won't go away in F38. I only have to worry
about being forced to build my own kernels in some unspecified future
phase. Doom is still coming but no one knows when. That's *such* a
relief.
Note the proposal talks about adding support for ukis, not about
removing support for current separate kernel+initrd setup.
It surely is the goal to incrementally improve uki support to cover more
use cases. I expect it will take quite some time to have ukis reach
feature parity, and only then it makes sense to start
thinking/discussing about eventually dropping support for non-uki
kernels. Which may very well never happen, for starters switching
existing installs automatically is a rather hard problem because the
local generated initrd may have unknown customizations.
> A host-specific initrd / command line is needed today for:
[...]
> * configuration being specified on the kernel command line.
> ** root filesystem being the most important one.
> [
https://systemd.io/DISCOVERABLE_PARTITIONS/ Discoverable partitions]
> allow to remove this.
Why link to a page that only contains a link to another page? Why not
link directly to
https://uapi-group.org/specifications/specs/discoverable_partitions_speci...
Oh, it moved. Didn't notice that yet, will update the link.
> Phase 2/3 goals (longer-term stuff which is not realistic to
complete for F38).
>
> * Move away from using the kernel command line for configuration.
I note that taking away the kernel command line is indeed a clearly
stated goal, which will limit Fedora to simple, appliance-like uses.
Ok, looks like I should clarify that. I want fedora not depend on the
kernel command line for configuration, so a unified kernel with the
compiled-in default command line boots the system fine without needing
any customization.
If you want change the command line you surely can do that (assuming
secure boot is disabled, otherwise systemd-stub ignores the command
line).
take care,
Gerd