[arch-releng] [PATCH 1/1] concatenate initramfs images for early microcode update

[Dave Reisner]

On Wed, Oct 29, 2014 at 07:11:28PM +0100, Thomas Bächler wrote:
> Am 29.10.2014 um 16:48 schrieb Christian Hesse:
> > Christian Hesse <list at eworm.de> on Wed, 2014/10/29 16:18:
> >> As said before... This does not work. Please prove me wrong!
> > 
> > This explains the details:
> > 
> > https://lists.debian.org/debian-user/2013/07/msg00383.html
> > 
> > Henrique de Moraes Holschuh wrote:
> > 
> > 	it will read any mix of compressed and uncompressed cpio archives
> > 	appended one after the other.  However, the early initramfs for
> > 	firmware and microcode update *must* be uncompressed, and it *must*
> > 	be the first cpio image in the initramfs
> > 
> 
> This is wrong - it will read any number of uncompressed initramfs until
> it finds a compressed one. You can add two initramfs (one for AMD and
> one for Intel) in any order and it will find the ucode. This works
> because the concatenation of two uncompressed cpio images looks just
> like a single cpio image AFAIK.

Sorry to be pedantic, but because I spent this past weekend writing a
CPIO library...

The end of any CPIO archive has a valid CPIO header for the filename
"TRAILER!!!". Upon finding this entry, the kernel will reset some
internal state and continue to read the file, expecting that if the
following read doesn't return EOF, it's the start of a new CPIO archive.
Userspace tools see the "TRAILER!!!" entry and stop reading, even if
there's more data beyond the trailer record.

hey man, man 5 cpio.

d