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
