Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Dec 20, 2022 at 07:22:34PM +0000, Daniel P. Berrangé wrote:
> On Tue, Dec 20, 2022 at 01:56:57PM -0500, Chris Murphy wrote:
> > Or if we could do enough strict standardization in
> > the boot chain with a possibly larger kernel to avoid
> > needing an initrd, i.e. get to sysroot mount faster
> > thereby obviating the need for a large initrd.
> 
> Completely eliminating the need for an initrd is an
> interesting option. I'm not sure that would be a thing
> that can be delivered in a practical timeframe though,
> given its potential impact on the distro as a whole.
> UKIs have the benefit that they have near zero impact
> on anything that's done today. They're just enabling
> new use cases that aren't possible today. The main
> burden of course is the need to support them as a
> concept in parallel with existing local initrds. I
> think that burden is quite modest though, and offset
> by the use cases they unlock.

There might be some specialized cases where initrd-less boot can be done,
but in general I think those will be even more of a minority in the future
than now.

Without an initrd we immediately have the following limitations:
- all kernel modules needed to mount root must be compiled in
- all that code is always loaded and remains in unswappable memory
- root= syntax is limited to what the kernel understands, i.e.
  no root=UUID=… o root=/dev/disk/by-path/… or other udev links,
  no encryption or dm-verity.
- no bluetooth keyboards or other fancy peripherals
- recovery is pretty hard

Initrd are now more complicated and costly (e.g. in the sense of time
required for installation) than they need to be. We should make them
simpler and cheaper, but trying to eliminate them, and thus also
forbid any userspace code from running before root is mounted, is a
red herring.

Zbyszek
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux