If I rebuild the initramfs on the f24 system, it drops to 20M.
dracut -f --hostonly

Looks like dracut-config-generic-044-18.git20160108.fc24 is making this happen? It's installed on f24 systems, but not f23 systems.

Proposed as a Freeze Exception for 24-beta by Fedora user chrismurphy using the blocker tracking app because:

 Best if this doesn't carry forward into beta, since many beta users don't do clean installs of final.

So, I'm not actually fully clear on the fix here. 

We could remove the dracut-config-generic from the live's kickstarts, but does that mean livemedia-creator would make a hostonly initramfs for the live media itself? 

If so, we would need to remove it in the installed system before it generates it's initramfs. Probibly best to consult with bcl here.

Removing dracut-config-generic from the ks is the right thing to do.

livemedia-creator rebuilds the initrd anyway, making sure livenet, etc. are included and passes it --no-hostonly when it does that. Anaconda regenerates the system initrd after copying over the live image so it will use whatever config is included in the ks. Removing dracut-config-generic results in a hostonly initrd.

I just did a full test and the iso initrd is 36M and the installed system's is 19M.

Why did it get pulled in? Is it serving another purpose? Mucking with the generation of initrd while we're already a week slipped makes me wary. It's not producing *incorrect* output, just overlarge.

Of course, we also hit the other side of the equation which is that we can't realistically fix it with an update (since we probably don't want to force the removal of dracut-config-generic from all systems).

I guess my main concern is whether what I heard in IRC the other day is provably true: Does this cause the /boot partition to fill up if we have three kernels installed? If it does, then I'd actually argue that we should treat this as a blocker, because it's going to interfere with the Alpha criterion:

"The installed system must be able to download and install updates with the default console package manager."


If it doesn't cause that behavior, I think I'm a weak -1 FE simply because I don't like introducing risk during a slip.

On i686, both PAE and non-PAE kernels are installed, each gets a 50M initrams, and a rescue kernel and initramfs. On clean install with 1 kernel, /boot is 189MB used. I don't know if updates will continue to update both pae and non-pae kernels, but if so /boot will hit ~430MB used with three kernels installed, and the fourth will fail (four are installed briefly and then the oldest is removed leaving three again).

On x86_64 it's a non-factor.

It may be a gray area that can be dealt with by documenting it as a common bug for Beta. Strictly speaking the system does update, and more than once.

That's pretty nasty for i686 though. We don't *block* on i686-only issues, but I guess I'd be okay with +1 FE to protect against that (since we can't fix it with an update).

i686 live images are 400 MB larger than x86_64 images. Cutting down the initramfs size will help with this. (For lives I think we can probably remove the initramfs images, because I don't think they get used and have added that suggestion to a bug I have filed about the large size difference.)

Unless we slip another week, I think an FE is too risky. If there is time for more than one build to revert the change if necessary, then I think it is worth taking a chance on.

(In reply to Bruno Wolff III from comment #9)
> i686 live images are 400 MB larger than x86_64 images. Cutting down the
> initramfs size will help with this.

? I don't see how a hostonly initramfs on media is even workable, it's not generic enough to boot almost anything, which is what's needed on the media.

> (For lives I think we can probably
> remove the initramfs images, because I don't think they get used and have
> added that suggestion to a bug I have filed about the large size difference.)

I don't understand this at all.

Live iamges don't use the initramfs for booting. It does get copied over on install to hard drive. Appearantly if they are there it confuses grub. They used to be removed but got added back for bug 1214441. There really should be a better fix for that, the doesn't waste a bunch of space.

Discussed during the 2016-05-02 blocker review meeting:

Accepted as a beta freeze exception for F24 and we're willing to run a compose with this change but *only* if there's sufficient time before the go/no-go date to test it and unwind if things go bad, i.e. on a Monday or earlier. we acknowledge the likely inconvenience for i686 installs

This is still a problem with Fedora-Workstation-Live-x86_64-24-20160531.n.0.iso. The initramfs is 50MB. And this is what I get for df -h after a new installation in a VM.

/dev/vda1       477M  142M  306M  32% /boot

Chances are this will accept three more kernels and initramfs, at ~60MB for the lot. (It needs to hold four, the fourth must be installed before the first is removed, with our default limit of three). But it's kinda tight. In the life of Fedora 24 what are the chances the initramfs gets much bigger and we start seeing failures? Or more likely Fedora 24 to Fedora 25 upgrades?

I don't really know the right way to do this to renominate for final freeze exception. I'm going to wipe the Blocks and Whiteboard fields, and put in the bug id for final FE.

$ rpm -qa | grep dracut
dracut-config-generic-044-18.git20160108.fc24.x86_64
dracut-live-044-18.git20160108.fc24.x86_64
dracut-044-18.git20160108.fc24.x86_64
dracut-network-044-18.git20160108.fc24.x86_64
dracut-config-rescue-044-18.git20160108.fc24.x86_64

I dropped the dracut-config-generic in rawhide branch a while back: 

commit b63ab022d7511670d757a66ade9c9cec0dd4a08d
Author: Kevin Fenzi <kevin>
Date:   Fri Apr 29 15:31:52 2016 -0600

    Drop dracut-config-generic since we don't want the larger generic initramfses on all installed from live instances.

Can someone check rawhide lives and see that their initramfs'es function and that if installed they default to host only? If that looks good, we can just cherry pick this one commit to the f24 branch.

bcl and I think this may possibly be causing https://bugzilla.redhat.com/show_bug.cgi?id=1318045 (which is an F24 Final blocker) too.

PR to pull the change into f24 branch: 

https://pagure.io/fedora-kickstarts/pull-request/26

*** Bug 1318045 has been marked as a duplicate of this bug. ***

so bcl and I are pretty sure that #1318045 - the wrong keymap being used for decryption of encrypted system partitions - is actually just a consequence of this bug. I tested the last Rawhide live nightly that was actually installable - 20160519.n.0 - and indeed found that there is a etc/vconsole.conf in the installed system's initramfs, and the correct keymap is used for system partition decryption.

Let's just hope that fixing this doesn't break anything else :/

the dupe was an accepted blocker, copying that status here.

We've merged nirik's change here:

https://pagure.io/fedora-kickstarts/c/cd2ff0eea2db55947c9826e81b8b001f4fb17223

so this should be ON_QA, the next compose should address it.

The fact that openQA's Cyrillic install test is now passing indicates that this is resolved.

The spin-kickstarts package has been updated and this fix is in RC-1.2 compose, so I believe we can close this.