Bug 1331834 - initramfs are no longer hostonly by default
Summary: initramfs are no longer hostonly by default
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: spin-kickstarts
Version: 24
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jeroen van Meeuwen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
: 1318045 (view as bug list)
Depends On:
Blocks: F24FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2016-04-29 18:12 UTC by Chris Murphy
Modified: 2016-06-15 21:49 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-06-15 21:49:06 UTC


Attachments (Terms of Use)

Description Chris Murphy 2016-04-29 18:12:57 UTC
Description of problem:

Fedora 24 initramfs is ~50M, where on Fedora 23 initramfs is ~20M.


Version-Release number of selected component (if applicable):
dracut-044-18.git20160108.fc24
dracut-config-generic-044-18.git20160108.fc24
dracut-live-044-18.git20160108.fc24
dracut-network-044-18.git20160108.fc24
dracut-config-rescue-044-18.git20160108.fc24


How reproducible:
Always


Steps to Reproduce:
1. Do a new installation of Fedora 23
2. Do a new installation of Fedora 24
3. Compare initramfs's

Actual results:

f23 initramfs varies depending on the host but generally is 17-21M.
f24 initramfs is 49M-50M.

Expected results:

f23 and f24 initramfs's approximately the same size.

Additional info:

Comment 1 Chris Murphy 2016-04-29 18:14:00 UTC
If I rebuild the initramfs on the f24 system, it drops to 20M.
dracut -f --hostonly

Comment 2 Chris Murphy 2016-04-29 18:21:45 UTC
Looks like dracut-config-generic-044-18.git20160108.fc24 is making this happen? It's installed on f24 systems, but not f23 systems.

Comment 3 Fedora Blocker Bugs Application 2016-04-29 18:40:16 UTC
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.

Comment 4 Kevin Fenzi 2016-04-29 18:47:27 UTC
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.

Comment 5 Brian Lane 2016-04-29 21:33:35 UTC
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.

Comment 6 Stephen Gallagher 2016-05-02 12:15:54 UTC
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.

Comment 7 Chris Murphy 2016-05-02 14:55:13 UTC
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.

Comment 8 Stephen Gallagher 2016-05-02 15:24:11 UTC
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).

Comment 9 Bruno Wolff III 2016-05-02 16:03:26 UTC
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.

Comment 10 Chris Murphy 2016-05-02 16:08:14 UTC
(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.

Comment 11 Bruno Wolff III 2016-05-02 16:25:43 UTC
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.

Comment 12 Tim Flink 2016-05-02 16:34:59 UTC
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

Comment 13 Chris Murphy 2016-06-02 01:12:09 UTC
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?

Comment 14 Chris Murphy 2016-06-02 01:17:12 UTC
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.

Comment 15 Chris Murphy 2016-06-02 01:19:59 UTC
$ 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

Comment 16 Kevin Fenzi 2016-06-02 01:40:59 UTC
I dropped the dracut-config-generic in rawhide branch a while back: 

commit b63ab022d7511670d757a66ade9c9cec0dd4a08d
Author: Kevin Fenzi <kevin@scrye.com>
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.

Comment 17 Adam Williamson 2016-06-03 00:08:16 UTC
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.

Comment 18 Kevin Fenzi 2016-06-03 02:29:54 UTC
PR to pull the change into f24 branch: 

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

Comment 19 Adam Williamson 2016-06-03 04:18:06 UTC
*** Bug 1318045 has been marked as a duplicate of this bug. ***

Comment 20 Adam Williamson 2016-06-03 04:20:51 UTC
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 :/

Comment 21 Adam Williamson 2016-06-03 19:05:39 UTC
the dupe was an accepted blocker, copying that status here.

Comment 22 Adam Williamson 2016-06-03 19:11:25 UTC
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.

Comment 23 Adam Williamson 2016-06-13 22:14:55 UTC
The fact that openQA's Cyrillic install test is now passing indicates that this is resolved.

Comment 24 Adam Williamson 2016-06-15 21:49:06 UTC
The spin-kickstarts package has been updated and this fix is in RC-1.2 compose, so I believe we can close this.


Note You need to log in before you can comment on or make changes to this bug.