Major increase in initramfs size with 3.6.0-1 kernel

[DBelton]

Has anybody else had this issue? Or know why it may have happened?

Previous kernels when installed had a much smaller initramfs than the latest 3.6.0-1 kernel.

-rw-r--r--.  1 root root 18722312 Sep 23 12:07 initramfs-3.6.0-0.rc6.git0.2.fc18.x86_64.img
-rw-r--r--.  1 root root 18818805 Sep 27 17:43 initramfs-3.6.0-0.rc7.git1.4.fc18.x86_64.img
-rw-r--r--.  1 root root 31054495 Oct  3 01:25 initramfs-3.6.0-1.fc18.x86_64.img

It's not just a small increase, either. It is a very large (almost double) increase in size.

[jpollard]

Looks like they threw in every driver imaginable.

Or maybe they added X + gnome....

[DBelton]

Heck if I know what they changed (They better not have Gnome in them! The Evil Gnome has been banished from my machines )

And for comparison, the initramfs for the current F17 kernels:

-rw-r--r--. 1 root root 21711056 Aug 31 01:01 initramfs-3.5.3-1.fc17.x86_64.img
-rw-r--r--. 1 root root 21711203 Sep 25 11:14 initramfs-3.5.4-1.fc17.x86_64.img
-rw-------. 1 root root 21716558 Oct  2 10:46 initramfs-3.5.4-2.fc17.x86_64.img

It's growing exponentially (the F18 versions). Geezzzzz..

BTW, these are on the very same hardware that the F18 initramfs above are on, so same modules, etc... should be getting loaded.

Edit:

Interesting.. The config files for the F18 kernel are much larger than the F17 kernels as well.

-rw-r--r--.  1 root root   123124 Sep 17 12:54 config-3.6.0-0.rc6.git0.2.fc18.x86_64
-rw-r--r--.  1 root root   123089 Sep 25 15:14 config-3.6.0-0.rc7.git1.4.fc18.x86_64
-rw-r--r--.  1 root root   122466 Oct  1 11:20 config-3.6.0-1.fc18.x86_64

-rw-r--r--. 1 root root   119103 Aug 29 14:03 config-3.5.3-1.fc17.x86_64
-rw-r--r--. 1 root root   119103 Sep 17 10:24 config-3.5.4-1.fc17.x86_64
-rw-r--r--. 1 root root   119103 Sep 26 17:18 config-3.5.4-2.fc17.x86_64

[jpollard]

To be fair, it has to include nearly every device - network, disk, infiniband, iscsi, NFS, filesystems of nearly every type (and some can be fairly large), plus all the runtime necessary to initialize them if they are used.

That can add up quite a bit.

---------- Post added at 10:22 PM ---------- Previous post was at 10:21 PM ----------

To be fair, it has to include nearly every device - network, disk, infiniband, iscsi, NFS, filesystems of nearly every type (and some can be fairly large), plus all the runtime necessary to initialize them if they are used.

That can add up quite a bit.

[DBelton]

I was thinking that dracut pretty much pared it down and built the initramfs for what was needed on the particular machine it's on, but maybe I am wrong about that. I can see it having some modules included on all systems by default, but most of them should only be included if the particular hardware has to have them.

It's built for a particular machine anyway, so I would hope it excludes some modules not necessary.

There were some dracut issues in F18 recently, maybe something got changed in how the build the initramfs to fix those issues.

[vallimar]

Just as a mention, you can save the output of lsinitrd and compare to see the differences
between various initramfs files. You can also try to regenerate by hand running dracut and
making sure you set the host-only flag to see if that shrinks it.

[DBelton]

I had completely forgotten about the lsinitrd command. Thanks vallimar

And I guess by default they do build the initramfs with everything but the kitchen sink in it

Here are two initramfs files I generated with dracut. one using the default, and the other using the host-only option.

-rw-r--r--.  1 root root  9167985 Oct  4 09:36 initramfs.3.6.0-1.fc18.x86_64.1.test
-rw-r--r--.  1 root root 31171241 Oct  4 09:35 initramfs.3.6.0-1.fc18.x86_64.test

The default gives me one that is over 3 times larger than the host-only.

But, now to find out what changed in the last kernel update to cause the initramfs to grow so much in just one update.

[roelj]

It's not really a kernel thing.. I compile my own kernel which is pretty similar to the fedora configuration (except for all stuff I don't need). I haven't noticed an increase with the 3.6.0 kernel (compared to 3.5.x).

[DBelton]

The increase wasn't from the 3.5.x to 3.6.x versions.

The difference is in different 3.6.x versions of the kernel. In fact, the first two 3.6.x kernels I have, the initramfs is actually smaller than the 3.5.x F17 initramfs.

But something changed in the last kernel update so that the resulting intiramfs is nearly twice the size of the previous one.

[srs5694]

Whatever you're seeing must be Fedora-specific. I just compiled and installed a 3.6.0 kernel on my Gentoo box, and it's about the same size as other recent kernels; likewise for the initrd files:

-rw-r--r-- 1 root     root  2063840 Jun  9 10:11 /boot/bzImage-3.4.1.efi
-rw-r--r-- 1 rodsmith users 2069376 Oct  3 19:11 /boot/bzImage-x86_64-3.5.5.efi
-rw-r--r-- 1 rodsmith users 2048416 Oct  4 13:36 /boot/bzImage-x86_64-3.6.0.efi
-rw-r--r-- 1 root     root  4183354 Jun  9 10:14 /boot/initramfs-genkernel-3.4.1
-rw-r--r-- 1 root     root  4405603 Oct  3 19:57 /boot/initramfs-genkernel-x86_64-3.5.5
-rw-r--r-- 1 root     root  4377243 Oct  4 13:37 /boot/initramfs-genkernel-x86_64-3.6.0

Those initrd file sizes are also much smaller than the ones posted for Fedora; presumably Gentoo doesn't include nearly as much stuff in their initrds.

FWIW, I ran into a problem some time ago related to initrd size. It turned out that I'd accidentally enabled a kernel debugging option. I think it was DEBUG_INFO ("Compile the kernel with debug info" in the "Kernel hacking" area), but I'm not 100% positive of that. This created something like a 5x increase in the size of the Fedora initrd, although the main kernel file didn't increase that much. Given that my memory of this is a much bigger increase than you're seeing, I doubt if it's the exact same cause; but it could be that the 3.6.0 kernel you've tried has some other debugging option enabled.

[secipolla]

If it helps, here are mine:

-rw-r--r--. 1 root root 14865081 Sep  8 07:29 initramfs-3.5.3-1.fc17.i686.img
-rw-r--r--. 1 root root 14868434 Sep 22 11:39 initramfs-3.5.4-1.fc17.i686.img
-rw-r--r--  1 root root 14865073 Oct  3 16:55 initramfs-3.5.4-2.fc17.i686.img

Also, IDK if it interferes or not but the F18 are debug kernels, right?

[nonamedotc]

Originally Posted by secipolla

Also, IDK if it interferes or not but the F18 are debug kernels, right?

I think not.

From the changelog in Koji,

Mon Oct 01 2012 Justin M. Forbes <jforbes@redhat.com>
3.6.0-1 - Linux 3.6.0 - Disable debugging options.

Here - http://koji.fedoraproject.org/koji/b...buildID=357607

Or, am I not understanding it right?

[DBelton]

So the one with the larger initramfs size what the one where they disabled the debugging options? That really doesn't make a lot of sense to me.

If it increased with debugging options enabled, I would expect that. But to increase when the debugging options are disabled is crazy.

And yes, you are understanding it correctly, nonamedotc... They disabled the debugging options in the 3.6.0-1 kernel.

[AdamW]

debug/release status I don't think should make any difference to the size of the initramfs, but IMBW. I dunno what's going on for you, dbelton, but here's what I've got:

-rw-r--r--. 1 root root 19268902 Sep 28 12:07 /boot/initramfs-3.6.0-0.rc7.git1.4.1.fc18.x86_64.img
-rw-r--r--. 1 root root 19505081 Sep 27 10:05 /boot/initramfs-3.6.0-0.rc7.git1.4.fc18.x86_64.img
-rw-r--r--. 1 root root 19264997 Oct 4 13:44 /boot/initramfs-3.6.0-2.fc18.x86_64.img

so...it didn't happen to me. though I happened to skip 3.6.0-1.