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@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