jbbletterman's questions

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.

Okay, so I have a problem with Fedora 34. More specifically, I have a problem with a custom built image that is part of the services that we deliver.

The Problem

The problem has to do with initramfs. See, we've been using initrd up until now, but the amount of packages and binaries have increased since our last upgrade from Fedora 32 to Fedora 34. Without manually adding new packages, the base, release and dependency packages have now increased to a point where initrd has become over 500MB in size.

The size of this initrd makes this image very unstable: legacy PXE doesn't work for instance, because this image is too big for TFTP and will freeze on most networks. However, the biggest, most crucial issue we have, is that GRUB2 is not allowing this initrd to boot anymore, mainly on HP laptops. Whenever we go back to Fedora 32, the images seem to be more stable. We think it's because of initrd being smaller here. The default Fedora Workstation (34) images also work on systems where our custom image is getting kernel panics.

Our image uses a /vmlinuz and /initrd file to boot into a RAMDisk using either USB (GRUB2) or PXE (iPXE). This is by design: Our application is a Chromium-based, integrated kiosk web browser, running on Fedora (34). It is supposed to be volatile and stateless.

Initramfs

I've been looking into initramfs as a replacement to initrd, since it's much newer, much lighter, and the size of this file may not trigger any bugs in GRUB2. Perhaps this will also enable us the use of legacy PXE implementations like PXELINUX and Windows Deployment Services. I figured I could easily replace the use of CPIO + XZ with Dracut. But I've been stuck on an issue I can't really wrap my head around...

The Paradox

Replacing initrd with initramfs in GRUB2 isn't that hard. If I use the same name for both files (not at the same time), it would look for the file name in the config and find the file. Easy, right? But then, the kernel messages pop up, and it fails to boot reading something like: Failed to switch root: Specified switch root path /sysroot does not seem to be an OS tree. os-release file is missing.

Needless to say, I checked out the contents of /sysroot: empty. There should be an os-release file in /etc. Reading up on "Sysroot", it's supposed to mount the OS directory structure, which is probably why it's telling me that it's missing some files.

Sysroot

Here's where I got lost: The directory structure is inside initramfs, right? But in order to run initramfs through GRUB2, I need to mount the directory structure to Sysroot. That means I can only reach /sysroot from inside initramfs. But I can't mount initramfs, because I need the OS-release file in /sysroot. I also can't mount the directories inside initramfs, because it's an image file. Can you see my paradox? How am I supposed to mount to /sysroot, when this requires something inside initramfs itself? I've already tried the root= kernel parameter with a PARTUUID or LABEL, but I can't use UUIDs since it's vFAT over UEFI.

Did I miss something here? Am I even supposed to use initramfs, when using bootable USB RAMDisks? If not, should I look into splitting up initrd into multiple files? How do I even do this?

NOTE: We are already using the highest possible compression (XZ level 9). I've tried splitting initrd before, but I have not been able to do it properly.

I personally don't like asking for help, but when all the Google search results are in purple, I may need a point in the right direction. A lot of systems are not working after our upgrade to F:34 and I would really like to get this fixed. Does anybody know how to use Dracut properly? Anyone with experience in generating initramfs images? Why is my /sysroot not already mounted?

Help is much appreciated, thank you.