Description of problem: The primary (hostonly) initramfs is generated twice on netinstalls.
Version-Release number of selected component (if applicable):
Always on netinstalls.
Steps to Reproduce:
1. Do a netinstall.
journal records dracut running twice for the same initramfs
Mar 17 04:44:18 localhost dracut: Executing: /sbin/dracut -f /boot/initramfs-4.0.0-0.rc3.git0.1.fc22.x86_64.img 4.0.0-0.rc3.git0.1.fc22.x86_64
Mar 17 04:46:07 localhost.localdomain dracut: Executing: /sbin/dracut -f /boot/initramfs-4.0.0-0.rc3.git0.1.fc22.x86_64.img 4.0.0-0.rc3.git0.1.fc22.x86_64
Seems like once is enough.
Because the kernel RPM package executes new-kernel-pkg it seems like anaconda doesn't need to do it also. This is what instigates the second execution:
22:45:57,566 INFO program: Running... new-kernel-pkg --mkinitrd --dracut --depmod --update 4.0.0-0.rc3.git0.1.fc22.x86_64
Created attachment 1002605 [details]
Created attachment 1002606 [details]
Created attachment 1002607 [details]
Created attachment 1002608 [details]
Created attachment 1002610 [details]
The second initrd regeneration is done after packages are installed and after Anaconda generated configuration files are installed. The regeneration is needed so that the Anaconda generated configuration files are taken into account when Dracut creates the initrd - users might have specified additional keymaps and want to use them to unlock LUKS, etc.
On the other hand, the first initrd creation triggered by the kernel package is indeed superfluous - it would make sense to skip it if we will create a new initrd once package installation is done anyway.
The new-kernel-pkg --update call needs an initrd to start from, so this isn't even superfluous.