Fedora Stakeholders Discuss Possibility Of Using Pre-Built Initramfs Images

[Djhg2000]

some storage drivers have userspace components. i.e. initramfs is the "compiled-in storage drivers"

This is a really late reply, but the idea was that the compiled in drivers would be enough to bootstrap the fancier drivers. E.g. the kernel finds the root partition with EXT4, loads the ZFS module, proceeds to mount ZFS drives, etc. The only real hard dependency is that the compiled in drivers must be enough to find other drivers.

[pal666]

What happened to the idea of removing initramfs entirely with compiled-in storage drivers

some storage drivers have userspace components. i.e. initramfs is the "compiled-in storage drivers"

[pal666]

I know and I don't necessarily disagree, but, still, there has to be some sort of alternative other than "wrapping it all up in an archive". Partition check-summing or something like that.

you can't put filesystem/storage driver into partition which can't be accessed until it's loaded

[HEX0]

What happened to the idea of removing initramfs entirely with compiled-in storage drivers and keeping kernel boot options in the bootloader? I tried this in Debian for a while and the performance advantage was very noticable from rotating media.

It's possible to live without initramfs, unless you need cryptsetup support to unlock root partition (and probably many other use cases). To my knowledge, currently there's no practical way to unlock root partition without having initramfs with cryptsetup on it. Also if initramfs would be same and static for everyone, they could build it into the "vmlinuz" kernel image file. Genkernel initramfs tool on gentoo can do this but it's not recommended because to change initramfs it requires recompiling the kernel.

[Djhg2000]

The kernel is lacking PARTUIID support, raid arrays and diverse other stuff, its way to fragile for desktop and just a last-resort solution.
What drivers do you want built-in ? Only storage (thats already a ton), filesystems, what about booting from USB-Sata adapters, network boot from NFS,NBD,CIFS?

I totally support static kernels for embedded, but for desktop the kernel "configuration code" is severely lacking.

Just keep the built-in to a sane default and enable initramfs in a post install trigger if the built-in drivers aren't enough for the current system. This way it can be automatically enabled/disabled for custom kernels with a different set of built-in drivers.

Not perfect but close enough for the majority and the relevant minority shouldn't have any issues fixing it for themselves.

[discordian]

What happened to the idea of removing initramfs entirely with compiled-in storage drivers and keeping kernel boot options in the bootloader? I tried this in Debian for a while and the performance advantage was very noticable from rotating media.

The kernel is lacking PARTUIID support, raid arrays and diverse other stuff, its way to fragile for desktop and just a last-resort solution.
What drivers do you want built-in ? Only storage (thats already a ton), filesystems, what about booting from USB-Sata adapters, network boot from NFS,NBD,CIFS?

I totally support static kernels for embedded, but for desktop the kernel "configuration code" is severely lacking.

[Britoid]

That is a silly idea... pre-built.. *scoff*

Systemd-initramfsd duh..

Dracut already has systemd inside of it.

[k1e0x]

That is a silly idea... pre-built.. *scoff*

Systemd-initramfsd duh..

[Etherman]

What happened to the idea of removing initramfs entirely with compiled-in storage drivers and keeping kernel boot options in the bootloader? I tried this in Debian for a while and the performance advantage was very noticable from rotating media.

AFAIK only thing missing in my kernel is the SATA driver since ext4 is already compiled in.
I will absolutely look into making this happen on my computer. :-)

[oleid]

What is the use case for such a setup? Probably stating the obvious but wouldn't "auto-decrypt" defeat the purpose of an encrypted hard drive?

Not really. I have a key embedded to initramfs to decrypt the different partitions, so that I don't have to enter the key multiple times during boot. That way I don't have to use lvm.

The initramfs, however, doesn't live on an unencrypted partition, but on the first encrypted one. Grub is clever enough to understand luks.