Comment 3 for bug 1507443

Ok, there are no changes between 4.1 and 4.2 (actually, between 4.1 and 4.2.8) re. either the earlycpio or the initramfs loaders.

So, the problem lies elsewhere.

That said, since I bothered to research this:

EARLY cpio loader (lib/earlycpio.c, loads the microcode data): always skips zero DWORDs (4 bytes) before any cpio header, so it will just concatenate every non-compressed cpio archive and skip any dword-aligned zero padding before, after, or between cpio archive headers. There is one header per file/directory inside the cpio archive.

Note: the early cpio loader does not care for subdirectories, it can find data by the whole path, and that's how microcode is loaded. This means the cpio archive with microcode does not need to have any of the subdirectories inside, it doesn't matter to the kernel.

LATE cpio loader (init/initramfs.c, loads the real initramfs):
  1. Skips any zero bytes before the compressed or uncompressed data (thus, skips any padding between cpio archives).
  2. Unpacks any compressed or uncompressed cpio archive it finds, concatenating the contents (thus, it *will* also unpack
      the microcode in the first cpio archive, and this file will be available inside the initramfs).
  3. It *depends* on subdirectories being created *first* before any files inside them. If this is not done, it will ignore the file.
  4. It does NOT skip inital zero-padding on the *decompressed* data (i.e. if you compress a cpio archive, it must not have
      any initial zero padding).
  5. It skips any zero padding at the end (compressed or not), but the zeros must *end* at a DWORD boundary.

So, we need more data to debug this. Because the kernel should have been able to read and unpack that initramfs just fine. The boot log (with the exact error message) or a better description of exactly where (and how) things went wrong during the boot would help.