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