Announcement

Collapse
No announcement yet.

Fedora Stakeholders Discuss Possibility Of Using Pre-Built Initramfs Images

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by Djhg2000 View Post
    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.

    Comment


    • #22
      Originally posted by discordian View Post

      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.

      Comment


      • #23
        Originally posted by Djhg2000 View Post
        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.
        Last edited by HEX0; 31 January 2020, 05:16 PM.

        Comment


        • #24
          Originally posted by skeevy420 View Post
          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

          Comment


          • #25
            Originally posted by Djhg2000 View Post
            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"

            Comment


            • #26
              Originally posted by pal666 View Post
              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.

              Comment

              Working...
              X