The Wanderer wrote: > Henrique de Moraes Holschuh wrote: >> songbird wrote: >> >>> # cpio -i -v < /boot/initrd.img-3.18.0-trunk-686-pae >>> kernel >>> kernel/x86 >>> kernel/x86/microcode >>> kernel/x86/microcode/GenuineIntel.bin >>> 22 blocks >>=20 >> Yeah, well, you have a multi-segment initramfs. There's an >> uncompressed cpio archive first with the "early initramfs" (used for >> platform firmware such as processor microcode updates and ACPI table >> overrides). It is followed by a compressed cpio archive with the rest >> of the initramfs contents.
ah, good to know the name of it, now with google i can still find no way to take it apart to examine the parts. >> The Linux kernel definition of an initramfs image is: "one or more >> cpio archives, compressed or uncompressed, one after the other. Any >> of these cpio archives can be zero-padded to any lenght, as long as >> it is a multiple of 4". It only supports a very specific subset of >> the possible cpio archive formats, too. sure, makes sense. >> The kernel doesn't really care if you change compression type, or >> alternate compressed and uncompressed while loading the regular >> initramfs, but the early initramfs MUST be the first segment, and it >> MUST be uncompressed. > > Hm. That's informative, thanks. > > So how does one manually expand such a multi-segment archive, to examine > and possibly manipulate its contents? lsinitramfs will list them, lsinitramfs does work for such archives. https://wiki.debian.org/InitramfsDebug mentions them, but only to say that they exist and that described methods don't work on them. > The only method I can think of which seems likely to be effective is to > scan through the file for a gzip-or-suchlike header within the file, > then 'cat' the remainder of the file out to where gunzip can find it, > and proceed from there - but I don't know of any way to do that using > standard tools; if I wanted to try it, I'd have to write code for the > purpose myself. > > Presumably appropriate tools do exist, if only within the kernel tree... is it the kernel or the init script that initramfs-tools is using that is doing the work? i think the lsinitramfs source code may provide some interesting ideas too, but this is beyond me at the moment to look into. songbird -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/ln3v0c-h72....@id-306963.user.uni-berlin.de