Re: encryption, partitioning, was: Workstation WG meeting recap 2018-Dec-03

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



Hi,

On 06-12-18 20:00, Chris Murphy wrote:
On Thu, Dec 6, 2018 at 4:28 AM Alberto Ruiz <aruiz@xxxxxxxxxx> wrote:

I had a conversation with Harald Hoyer this week and he's not against the idea of the "deterministic" initramfs.

Host only initramfs is ~ 18MiB to 24MiB. Whereas a generic initramfs
is ~70MiB. That's 3x larger. Load time goes from 2.5s to 7.5s. And
/boot requires more storage since there are four initramfs files by
default.

For me it is 20MB normally, 50MB for a generic initramfs.

So I've taken a quick look at shrinking this, which turns out to not be
all that easy. A more interesting approach might be to figure out why
this takes so much time, AFAIK this time does not include the actual
loading from the disk as that happens before measurements start, so
for some reason the kernel is taking 7.5 seconds to unpack the initrd.

One possible solution would be to create a generic initrd for popular
hardware and a complete initrd for other hw, such a generic initrd
should be able to cover 90 - 95% of all hardware.

The tricky part with this would be to write code to decide which initrd
to use. But we could use a whitelist based approach here, where we check
that / is:

a) On a filesystem supported by the generic initrd
b) Backed by block layers (lvm / dmcrypt) which are supported by the
generic initrd
c) Backed by a "physical" blockdev supported by the generic initrd

And only then use the generic initrd, the code for this can be borrowed
from dracut's existing code to detect which modules to load. Thinking
more about this, we should probably have dracut itself provide a tool
which we can run at install time to decide which initrd to use.

This might be as simple as building a hostonly initrd and checking all
the files in the hostonly initrd are in the generic initrd.

Regards,

Hans
_______________________________________________
desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/desktop@xxxxxxxxxxxxxxxxxxxxxxx




[Index of Archives]     [Fedora Users]     [Fedora KDE]     [Fedora Announce]     [Fedora Docs]     [Fedora Config]     [PAM]     [Red Hat Development]     [Red Hat 9]     [Gimp]     [Yosemite News]

  Powered by Linux