On Di, 09.05.23 15:22, Chris Murphy (lists@xxxxxxxxxxxxxxxxx) wrote: > > > On Tue, May 9, 2023, at 2:47 PM, Zbigniew Jędrzejewski-Szmek wrote: > > On Tue, May 09, 2023 at 01:31:01PM -0500, Chris Adams wrote: > >> Once upon a time, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> said: > >> > What about the increasing growth in linux-firmware and in particular the NVIDIA firmware requirements? My reading suggests it's significant and the future growth also significant. > >> > >> Could we use a dumb framebuffer in initrd and get rid of all the GPU > >> firmware from the image? > > > > Maybe, probably, who knows… But it's not just the video. The pressure > > to add more stuff and more drivers will only grow: bluetooth for keyboards > > and FIDO2, sound support for voice assistance, network for remote attestation > > or clevis, etc. We can push this can down the road, but it seems we need > > to be ready to add move stuff before root is available anyway. > > I still think we need less kernel and initramfs in order to get more > by having `/` available faster. Fast enough that the user isn't > looking for or expecting interactivity in the few seconds it should > take to get to `/` being mounted. Aren't you the one who just proposed LinuxBoot, i.e. having one kernel with initrd that includes complex storage, crypto, drivers, auth and things chainload a second kernel with initrd that includes all that? If you want fast boots and minimal disk space usage, then maybe have tiny boot loader and a single UKI element after that and not play games of setting up complex storage to load a secondary kernel that then has to set up complex storage again. You are arguing here into two opposing directions. One one hand you want to chainload multiple kernels+initrd (claiming this was a good idea out of the problem of sizing ESP/XBOOTLDR sufficientlly), and then on the other hand you claim there's too much kernel+initrd in the boot process? What is it now? Pick one: more initrd or less initrd? Lennart -- Lennart Poettering, Berlin _______________________________________________ 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
