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.
> 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...
That page makes it clear that omitting root= from the kernel command
line is only an *option* which is proposed only "for simpler,
appliance-like installations". My workstation and my laptop aren't
appliance-like in the slightest. And on appliances you want a stable,
reliable operating system, not a fast-moving, unstable one like Fedora.
** Troubleshooting being the second most important one. When the system
won't boot, it's necessary to remove "quiet" and "rhgb" from
the kernel
command line to see how far the boot process gets and what error
messages are printed. It may also be necessary to configure a serial
console for example.
Current UKIs only support a single embedded cmdline, but I've proposed
supporting multiple. The intent would be to ship with two cmdlines,
one for "normal" production usage which would be 'quiet rhgb' and one
for debug usage, which would omit 'quiet rhgb'. The bootloader would
need to allow the user to pick between the two options, but this
would allow SecureBoot to be sustained.
The root filesystem is also relevant for troubleshooting, when I take
a
storage device out of a broken computer and connect it to another
computer to inspect it. Suddenly there are two "discoverable" root
partitions, and the kernel parameter is necessary to specify which one
is the root filesystem, as stated under "Doesn’t this break multi-boot
scenarios?":
https://uapi-group.org/specifications/specs/discoverable_partitions_speci...
This proposal for UKIs is targetting VM usage where multi-boot is
not something that is important. You can take the guest disk image
and access it using tools like 'guestfish' to access data, and
discoverable partitions won't make that aspect of it harder.
Note that when systemd discovers partitions, it only discovers
partitions on the same physical disk that the kernel is booting
from. So even in the bare metal case, it wouldn't even consider
the discoverable partitions on your second disk. The problems
only arise if you have multiple OS installs on the same disk.
> 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.
That bullet point is a little open to mis-interpretation. If
it is possible to do something on the kernel command line today,
it isn't proposing to remove that ability. This point is rather
about providing an alternative way to achieve the same goal
without relying on the command line. IOW there would be a choice,
with the right answer picked depending on the usage scenario.
With regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|