[SOLVED] Bloated initramfs image sizes

fractal_sounds · 2025-02-20 15:13:23

When I was setting up my Arch system, I wanted to never have to worry about resizing the /boot partition. So I allocated 1 GiB for it, feeling confident at the time that this would be ample space for the foreseeable future. I had the following three kernels installed (as well as the fallback version for each):

linux (day-to-day use)
linux-lts (in case of problems with main kernel)
linux-hardened (installed out of curiosity, but never got around to exploring it)

To my surprise, during a recent system upgrade, the step for updating the linux initcpios failed due to /boot running out of space.

In my research, I found a forum topic about Linux 6.7 kernel creating very large initramfs. At the time this was determined to be due to a bug with mkinitcpio.

Unfortunately I don't know whether my initramfs images became so bloated only recently, or whether they had always been teetering on the brink of filling up the /boot partition, and a slight increase in file size during the recent update was enough to cross that threshold. I can only presume that the above mkinitcpio bug was not the culprit, given that it was fixed almost a year ago, and I would have long since upgraded to the patched version.

In one of the posts from the topic linked above, the suggestion was made to drop the kms hook and/or disable fallback image generation as a means of reducing the total footprint of the initramfs images. Not wanting to tinker too much with the hooks as a first step, I opted for the following solution:

Uninstalled the linux-hardened kernel entirely, given that I had never once used it. Upon some further research into its use cases, I also realised that I would be very unlikely to have any cause to use it in the future either.
Disabled fallback image generation for the linux kernel.
Still kept the fallback image for the linux-lts kernel, just in case I ever needed the full set of firmware for some reason.
sudo mkinitcpio -P

This allowed me to successfully complete the upgrade, and I am currently happy with the selection of kernels I have installed.

However, I would like to try and understand why it is that my initramfs images are so bloated. This is partly just for better knowledge and understanding, and partly to have the option of adding additional kernels in the future without having to worry about filling up /boot.

These are the current sizes of my three images, with the associated kernel versions in brackets:

200 MiB: initramfs-linux.img (6.13.3.arch1-1)
200 MiB: initramfs-linux-lts.img (6.12.15-1)
277 MiB: initramfs-linux-lts-fallback.img (6.12.15-1)

In trying to find the culprit, I noticed that the wiki article on KMS says:

For in-tree modules, make sure kms is included in the HOOKS array in /etc/mkinitcpio.conf (this is the default since mkinitcpio v33).
For out-of-tree modules, place the module names in the MODULES array,

whereas my /etc/mkinitcpio.conf currently has (I am running the propriety NVIDIA driver, incidentally):

MODULES=(nvidia nvidia_modeset nvidia_uvm nvidia_drm)
HOOKS=(base udev autodetect microcode modconf kms keyboard keymap consolefont block encrypt lvm2 filesystems fsck)

My questions at this stage are:

Could the fact that I have nvidia modules, as well as the kms hook, be responsible for this image size bloat?
If so, should I go ahead and remove kms as a hook?
When I was setting up my system, I also had to enable DRM kernel mode setting by including nvidia-drm.modeset=1 as a kernel module parameter in /etc/default/grub. This was needed because I was running Wayland on Plasma, and without it my external monitor wasn't being detected. Does the use of this kernel module parameter have any bearing on whether or not it is safe for me to remove the kms hook? Or is it the case that you never simultaneously need both nvidia modules and the kms hook, irrespective of any other kernel parameters you have set elsewhere?
From the information provided above (kernel versions, modules, hooks), is it possible to know approximately what sizes I should normally be expecting for my initramfs images? Or does that also depend on other factors that I have not discussed here?

Thank you in advance for your time and assistance.

Last edited by fractal_sounds (2025-02-22 00:52:25)

cryptearth · 2025-02-20 15:39:41

having both KMS and nvidia soubds wrong - according to wiki you're supposed to remove kms when using nvidia
but as for the overall question: it's likely that nvidia stuff - with grub and no fallback I'm able to fit both windows and linux within about 100-150 mb

tekstryder · 2025-02-20 18:03:28

fractal_sounds wrote:

I don't know whether my initramfs images became so bloated only recently

Recently with the 570 driver. We noted this on the nVidia forum:

• https://forums.developer.nvidia.com/t/5 … /321956/60

Thanks for the reminder to look into this further!

tekstryder · 2025-02-20 18:28:38

Been meaning to do this for a long while.

I removed the kms hook and rebuilt initramfs for all kernels. The ~50MB "bloat" is vanquished.

Rebooted into each of them to assure no shenanigans ensued. All systems nominal.

Before:

-rw-r-----  1 root root 197M Feb  3 10:37  initramfs-linux.img
-rw-r-----  1 root root 197M Feb  3 10:37  initramfs-linux-lts.img
-rw-r-----  1 root root 155M Feb  3 10:37  initramfs-linux-stable-mfm.img
-rw-r-----  1 root root 155M Feb  3 10:37  initramfs-linux-zen-mfm.img
-rw-r-----  1 root root  75M Jan 17 12:01  initrd.img-6.1.0-30-amd64

After:

-rw-r-----  1 root root 152M Feb 20 13:15  initramfs-linux.img
-rw-r-----  1 root root 152M Feb 20 13:09  initramfs-linux-lts.img
-rw-r-----  1 root root 152M Feb 20 13:19  initramfs-linux-stable-mfm.img
-rw-r-----  1 root root  75M Jan 17 12:01  initrd.img-6.1.0-30-amd64

V1del · 2025-02-20 18:47:51

AFAIK the KMS hook will pull in nouveau and nouveau firmware and you generally don't want that when using the prop driver. And if you happen to have an integrated iGPU or so where the driver is loaded, even if it's not in active use, then kms will pull firmware for that as well.

tekstryder · 2025-02-20 18:58:03

V1del wrote:

AFAIK the KMS hook will pull in nouveau and nouveau firmware

Right. I should have mentioned that.

The reason it only shrunk linux and linux-lts, but not my custom kernel is that nouveau is not compiled into the custom kernel.

cryptearth · 2025-02-20 19:42:37

wow - that's REALLY bloated - here's mine:

[main@main ~]$ LC_ALL=C ls -alFh /boot
total 58M
drwxr-xr-x  2 root root 4.0K Feb 19 21:05 ./
drwxr-xr-x 19 root root 4.0K Nov 26 01:42 ../
-rw-r--r--  1 root root 150K Feb 12 00:11 amd-ucode.img
-rw-------  1 root root  44M Feb 19 21:05 initramfs-linux.img
-rw-r--r--  1 root root  14M Feb 19 21:05 vmlinuz-linux
[main@main ~]$

along with about 40M on /efi (win10 + grub) it would just fit all on the standard 100M default ESP created by the windows installer - without grub (about 15M) but a UKI I would be able to maybe get it even less to fit easy on 100M

tekstryder · 2025-02-20 20:40:08

cryptearth wrote:

wow - that's REALLY bloated - here's mine:

So, is that with the nVidia proprietary driver installed or are you just showing off?

EDIT: also, is that with default compression?

Last edited by tekstryder (2025-02-20 20:42:06)

fractal_sounds · 2025-02-21 12:37:02

Thank you so much everyone for your assistance and advice.

Like tekstryder, I removed the kms hook from all kernels, then tested each to make sure it was loading with no issues. The file size savings were:

200 MiB --> 154MiB: initramfs-linux.img (6.13.3.arch1-1)
200 MiB --> 154MiB: initramfs-linux-lts.img (6.12.15-1)
277 MiB --> 189MiB: initramfs-linux-lts-fallback.img (6.12.15-1)

The fact that tekstryder and I both have very similar file sizes (both before and after the kms removal) is hopefully a sign that there isn't anything else out of the ordinary, and that the still comparatively bloated size (very envious of your lean initramfs, cryptearth!) is due to us running the proprietary Nvidia drivers. Of course it would be nice if it could be made even smaller, but at least now I have enough room to either install other kernels I might want to try later on, and still have enough buffer for other unforeseen sudden size jumps in the future.

I'll leave this thread as it is for now, in case anyone else sees it and has any ideas about other ways to further reduce the sizes even with Nvidia drivers. But I think the main issue seems to have been needlessly running both kms hook and nvidia modules, and so I'll mark the thread as solved in the next day or two if no other contributions are made.

Thank you again to everyone. As always, I truly appreciate the assistance and sharing of knowledge from this community.

Last edited by fractal_sounds (2025-02-21 12:40:57)

cryptearth · 2025-02-21 15:06:14

tekstryder wrote:

cryptearth wrote:
wow - that's REALLY bloated - here's mine:
So, is that with the nVidia proprietary driver installed or are you just showing off?
EDIT: also, is that with default compression?

it surely isn't to show off - but rather to point out that in fact it is possible to squeeze standard microsoft stuff + grub + kernel + initrd + ucode into the 100m esp created by the windows installer - although even I have only grub instslled onto esp and currently play with the idea to convert to additional XBOOTLDR partition
as for "how standard are these" exactly as

pacstrap linux

will build them but with the fallback removed - so with kms but without nvidia
the only out-of-tree module I use is ZFS - but I run root on ext4 and hence don't need zfs in initrd for booting

morguldir · 2025-05-01 21:56:26

Mine had rclone, which has been fixed, but it's not in a release yet: https://gitlab.archlinux.org/archlinux/ … issues/227 reduced the size by ~50mb

You can extract them into the current directory with `lsinitcpio -x`, the nvidia driver includes firmware blobs that don't compress too well, roughly 60mb with just those

It's not super large compared to the kms hook, especially since GSP intentionally has more firmware code than there normally would be

NuSkool · 2025-05-02 17:05:13

As an alternative, you might consider not putting your kernels, etc on the esp.
I setup my systems as follows more to have kernel, etc on a decent Linux fs, and as a consequence there are also no esp size constraints.
Here's my latest setup, where I just reused the Windows esp.

lsblk
nvme0n1                 931.5G                        /dev/nvme0n1   
├─nvme0n1p1 /boot/efi     100M vfat   SYSTEM          /dev/nvme0n1p1 447F-12B0
├─nvme0n1p2 /           122.9G ext4   Root            /dev/nvme0n1p2 5e307495-f996-48bf-90ab-940b1de1e452
├─nvme0n1p3 [SWAP]       31.7G swap   Swap            /dev/nvme0n1p3 0c1f5ebe-53a9-48d5-91a1-119cef6eaeec
└─nvme0n1p4 /home       776.7G ext4   Home            /dev/nvme0n1p4 d2dde27d-207c-4c7a-ad89-10dc73fecd57

ls -alFh /boot
total 255M
drwxr-xr-x  4 root root 4.0K May  2 09:57 ./
drwxr-xr-x 17 root root 4.0K Apr 26 23:00 ../
drwxr-xr-x  4 root root 1.0K Dec 31  1969 efi/
drwxr-xr-x  6 root root 4.0K Apr 30 11:17 grub/
-rw-r--r--  1 root root 150K Apr 10 06:22 amd-ucode.img
-rw-------  1 root root 115M Apr 26 16:17 initramfs-linux-fallback.img
-rw-------  1 root root  37M Apr 26 16:17 initramfs-linux.img
-rw-------  1 root root  38M May  2 09:57 initramfs-linux-stable-rc-fallback.img
-rw-------  1 root root  37M May  2 09:57 initramfs-linux-stable-rc.img
-rw-r--r--  1 root root  15M Apr 26 11:19 vmlinuz-linux
-rw-r--r--  1 root root  15M May  2 09:57 vmlinuz-linux-stable-rc

I'm pretty old school/conservative with my setups though, and not sure how this would translate with btrfs, etc...

Last edited by NuSkool (2025-05-02 17:22:00)

Arch Linux

#1 2025-02-20 15:13:23

[SOLVED] Bloated initramfs image sizes

#2 2025-02-20 15:39:41

Re: [SOLVED] Bloated initramfs image sizes

#3 2025-02-20 18:03:28

Re: [SOLVED] Bloated initramfs image sizes

#4 2025-02-20 18:28:38

Re: [SOLVED] Bloated initramfs image sizes

#5 2025-02-20 18:47:51

Re: [SOLVED] Bloated initramfs image sizes

#6 2025-02-20 18:58:03

Re: [SOLVED] Bloated initramfs image sizes

#7 2025-02-20 19:42:37

Re: [SOLVED] Bloated initramfs image sizes

#8 2025-02-20 20:40:08

Re: [SOLVED] Bloated initramfs image sizes

#9 2025-02-21 12:37:02

Re: [SOLVED] Bloated initramfs image sizes

#10 2025-02-21 15:06:14

Re: [SOLVED] Bloated initramfs image sizes

#11 2025-05-01 21:56:26

Re: [SOLVED] Bloated initramfs image sizes

#12 2025-05-02 17:05:13

Re: [SOLVED] Bloated initramfs image sizes

Board footer