Bug 858840

User-Agent:       Mozilla/5.0 (X11; Linux i686; rv:26.0) Gecko/20100101 Firefox/26.0

For systems where more than one kernel (n kernels) is installed (e.g. multiple versions or flavors), mkinitrd creates an initrd for each. So far, so good.

Unfortunately a single "kernel" consists of two or more packages which are installed in a somewhat loose order. Each %post script of a kernel package calls mkinitrd, which in turn, re-creates the initrds for each kernel found.

Despite the fact that the "useless temporary" initrd updates waste time and CPU cycles, there is a danger associated with this: If you update your kernel (say from 2.6.x to 3.0.y), the first mkinitrd of the first kernel package created an initrd that does not fit to the rest of the kernel. If the system crashes or the power goes out (or a cluster node fences the server), the system may be unbootable (modules in initrd not matching the kernel image).

Reproducible: Always

Steps to Reproduce:
1. Watch kernel updates

Actual Results:  
Multiple mkinitd calls are observerd

Expected Results:  
mkinitrd should be deferred until all the kernel-related updates are on disk.

For example: I installed updates for kernel and multipath. multipath-update alone built the initrd several times:
2014-01-15 10:41:51 <1> pc(10330) [zypp] RpmDb.cc(doInstallPackage):1849 RpmDb::installPackage(/var/cache/zypp/packages/repo-update/i586/multipath-tools-0.4.9-7.5.1.i586.rpm,0x0000000c)
[...]
2014-01-15 10:52:46 <1> pc(10330) [zypp] RpmDb.cc(doInstallPackage):1849 RpmDb::installPackage(/var/cache/zypp/packages/repo-update/i586/parted-2.4-30.4.1.i586.rpm,0x0000000c)

That is 11 minutes to wait just for the update of multipath-tools!
Each of my 3 kernels got its initrd build at least two times during that.