On Wed, May 10, 2023, at 2:24 PM, Owen Taylor wrote: > > > On Wed, May 10, 2023 at 12:02 PM Neal Gompa <ngomp...@gmail.com> wrote: >> > Now, there's a second problem with reading everything from the ESP - it's > slow for two reasons. First, because read speeds when going through the > firmware are much slower than the Linux NVMe stack. And second, because we > have to read everything in order to checksum and verify it. > > For that reason, Demi's suggestion of moving things onto a dm-verity > protected partition is intriguing. Could that even be a loopback file on the > ESP? It would be like a lazy-read system extension. > > The performance geek in me thinks "we could see exciting speedups from that!" > - the practical side of me thinks "it might be a few second faster. And much > more complex! Let's just go with efifb, keep the initramfs small, and accept > any minor regressions".
GRUB doesn't support dm-verity, but I don't know if it would make a difference if it did. Once the kernel has the ability to interact with physical storage, understand partitions, initialize dm-verity, and read a file systemt... it could just mount `/` . I think the only way the current initial root file system works with the kernel is for the bootloader to read an entire initrd file into RAM, and then the kernel can randomly access things in that RAM disk. It's early still for UKI details but I assume we will need both a universal UKI (all use cases), and much smaller use case focused UKIs. I say that because the desktops in the default installation configuration are the largest single use case. With Btrfs built-into the kernel, we don't need that much in the initrd to setup block devices, discover their contents, and perform switch root. The next most common use case(s), device-mapper and md based, require a pile of user space programs running to do all the work setting things up. Maybe we can just get away with two images, a simple fast one and the universal. -- Chris Murphy
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
