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_specification/

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
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to