0

I would like to know if it's possible to have a split initrd implementation. Our reason for doing this, is the fact that our Fedora based application uses a stripped version of Fedora underneath with an initrd file which has become so large (+500MB), that GRUB2 is giving us issues with said file on some computers (mainly cheap HP laptops our clients love to buy against our recommendations). We have established that the problem lies with GRUB2, initrd and HP laptops, because unpacking initrd allows these machines to boot. For our use case, however, we need to be able to boot into RAM, because our application is a bootable RAMDisk which runs our app in a kiosk environment.

We are already using the highest form of compression on initrd (XZ level 9). Serving the rootfs from a network share and forcing our clients to adjust their infrastructure is an undesirable solution. We would like to keep the option for our application to simply boot off a USB device, like they are already doing.

Diverging from GRUB2 would perhaps also be an option, but that would jeopardize our ability to be bootable on EFI-only Secure Boot enabled hardware (because GRUB2 packages are presigned by some vendors for Secure Boot).

Is it possible to simply split up our massive initrd? Or do we have other options?

Thank you.

EDIT: Unfortunately, we need to supply as many modules as possible. This image needs to be portable on as many different types of devices as possible, to reduce the chances of clients running into kernel panics.

jbbletterman
  • 1
  • 1
  • 1
    Have you tried removing not needed elements from initrd? – Tero Kilkanen Sep 18 '21 at 19:51
  • Unfortunately, we need to supply as many modules as possible. This image needs to be portable on as many different types of devices as possible, to reduce the chances of clients running into kernel panics. – jbbletterman Sep 20 '21 at 08:02
  • I think there might be kernel subsystems that you don't need for your product, and you could disable those. – Tero Kilkanen Sep 20 '21 at 14:17
  • You should look at the list of modules in dracut on the OS installation media. For the purpose of hardware compatibility it is unlikely you'll need much (or any) more of those. – Michael Hampton Sep 25 '21 at 23:00
  • Unfortunately, we need to supply as many modules as possible. This image needs to be portable on as many different types of devices as possible, to reduce the chances of clients running into kernel panics. – jbbletterman Sep 27 '21 at 10:47
  • So does the installation media. It also has to run on as many devices as possible. It's really worth a look before you just dismiss it out of hand. – Michael Hampton Sep 27 '21 at 10:55
  • Removing modules in Dracut on the OS installation media will increase hardware compatibility with more systems? You're going to have to explain this to me. – jbbletterman Sep 27 '21 at 10:59

0 Answers0