Just want to document this often asked problem: what is the maximum size allowed, for an initramfs? Obviously this will be related to how much RAM you have, but what is exactly the relationship?
I have answered the question here, but I didn't explain why the numbers are what they are. This post attempts to correct that, if you're interested.
When considering this question, there are two things to remember:
a) initramfs will be uncompressed to memory during boot-up, so the amount of RAM needed would be the size of the initial initramfs + size of uncompressed initramfs
b) how much RAM the kernel will want to allocate for holding initramfs.
For the system to successfully boot, (a) must be the same or less than (b).
(a) is easy - by rule of thumb, it is twice the uncompressed size of initramfs. It is exact for uncompressed initramfs, and approximate for compressed initramfs; in either way it will give you the upper bound.
(b) is a bit more complicated. Traditionally the kernel will use "ramfs" for initramfs (that's why it is called init-ramfs ... ), and it will happily allocate all of your RAM for it, which is unwise, so you should at least subtract about 0.5GB from your RAM size if you want a usable system (unless your idea of fun is dealing with kernel OOM-killer that kills your important system services right after boot - not me).
But somewhere around kernel 3.x (circa 2012), the kernel merged "inittmpfs" patch from Rob Landley (of busybox and toybox and aboriginal Linux fame). It means that from that day onwards, initramfs will use "tmpfs" as opposed to "ramfs" by default (you can still switch back to using ramfs by specifying "rootfstype=ramfs" on your kernel command line). In case you're not familiar with the difference, "tmpfs" is "ramfs" with a size-limit (among others); and by default the limit is 50% of your RAM.
But wait, you say, doesn't "tmpfs" come with knobs to specify the maximum size? Yes, it does, but not at boot-time, no. Sure, you can re-mount it and changes it size, but we're talking here the situation during initramfs loading, *before* any code in initramfs itself is started ...
Rob actually has a patch to do exactly this, using "rootfsflags", but don't count on it going to mainline kernel soon.
But I digress. So, to come back to the subject, with "ramfs" you get all of your RAM (minus your 0.5GB), and with "inittmpfs" you get 50% of your RAM. This is (b). And since (a) is twice the size of your initramfs, it means that the maximum allowable size of your initramfs is 1/2 of (b).
Which means, if you use "inittmpfs" (which is the default in modern kernels), your initramfs size is limited to 1/2 of 50% of your RAM, or 25% of your RAM. If you use "ramfs" by specifying "rootfstype=ramfs" in your kernel boot command line, when this limit can increase to 1/2 of your RAM (minus 0.5GB), or, about 40%-45% of your RAM (depending on how big it is). Q.E.D.
Edit - Delete
Comments:Posted on 18 Jun 2017, 14:20 by Mark999
I recently deleted the embedded command line in one of my kernel configs (containing rootfstype=ext4 ), then encountered a surprise in the form of my initramfs running out of memory when it never had before.
Now that I've read your post, I think I know what happened: rootfstype=ext4 was mostly ignored, but caused the kernel to use ramfs rather than tmpfs.
Removing it meant that the 50%-of-ram limit was enforced, and there wasn't enough space for the ~3.9GB file I try to temporarily store in rootfs.
 exactly why I had this is lost in the mists of time; I _thought_ it was important to another initramfs which is used with this kernel, so I left it. I've now thrown out dracut and the initramfs it rode in on (or vice versa?), so it should've been safe to remove everything it needed.