On Di, 09.05.23 15:22, Chris Murphy (lists@colorremedies.com) 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@colorremedies.com 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