=======================initramfs buffer format======================= Al Viro, H. Peter Anvin With kernel 2.5.x, the old "initial ramdisk" protocol was complementedwith an "initial ramfs" protocol.  The initramfs content is passedusing the same memory buffer protocol used by initrd, but the contentis different.  The initramfs buffer contains an archive which isexpanded into a ramfs filesystem; this document details the initramfsbuffer format. The initramfs buffer format is based around the "newc" or "crc" CPIOformats, and can be created with the cpio(1) utility.  The cpioarchive can be compressed using gzip(1), or any other algorithm providedvia CONFIG_DECOMPRESS_*.  One valid version of an initramfs buffer isthus a single .cpio.gz file. The full format of the initramfs buffer is defined by the followinggrammar, where:: 	*	is used to indicate "0 or more occurrences of"	(|)	indicates alternatives	+	indicates concatenation	GZIP()	indicates gzip compression of the operand	BZIP2()	indicates bzip2 compression of the operand	LZMA()	indicates lzma compression of the operand	XZ()	indicates xz compression of the operand	LZO()	indicates lzo compression of the operand	LZ4()	indicates lz4 compression of the operand	ZSTD()	indicates zstd compression of the operand	ALGN(n)	means padding with null bytes to an n-byte boundary 	initramfs := ("\0" | cpio_archive | cpio_compressed_archive)* 	cpio_compressed_archive := (GZIP(cpio_archive) | BZIP2(cpio_archive)		| LZMA(cpio_archive) | XZ(cpio_archive) | LZO(cpio_archive)		| LZ4(cpio_archive) | ZSTD(cpio_archive)) 	cpio_archive := cpio_file* + (<nothing> | cpio_trailer) 	cpio_file := ALGN(4) + cpio_header + filename + "\0" + ALGN(4) + data 	cpio_trailer := ALGN(4) + cpio_header + "TRAILER!!!\0" + ALGN(4)  In human terms, the initramfs buffer contains a collection ofcompressed and/or uncompressed cpio archives (in the "newc" or "crc"formats); arbitrary amounts zero bytes (for padding) can be addedbetween members. The cpio "TRAILER!!!" entry (cpio end-of-archive) is optional, but isnot ignored; see "handling of hard links" below. The structure of the cpio_header is as follows (all fields containhexadecimal ASCII numbers fully padded with '0' on the left to thefull width of the field, for example, the integer 4780 is representedby the ASCII string "000012ac"): ============= ================== ==============================================Field name    Field size	 Meaning============= ================== ==============================================c_magic	      6 bytes		 The string "070701" or "070702"c_ino	      8 bytes		 File inode numberc_mode	      8 bytes		 File mode and permissionsc_uid	      8 bytes		 File uidc_gid	      8 bytes		 File gidc_nlink	      8 bytes		 Number of linksc_mtime	      8 bytes		 Modification timec_filesize    8 bytes		 Size of data fieldc_maj	      8 bytes		 Major part of file device numberc_min	      8 bytes		 Minor part of file device numberc_rmaj	      8 bytes		 Major part of device node referencec_rmin	      8 bytes		 Minor part of device node referencec_namesize    8 bytes		 Length of filename, including final \0c_chksum      8 bytes		 Checksum of data field if c_magic is 070702;				 otherwise zero============= ================== ============================================== The c_mode field matches the contents of st_mode returned by stat(2)on Linux, and encodes the file type and file permissions. c_mtime is ignored unless CONFIG_INITRAMFS_PRESERVE_MTIME=y is set. The c_filesize should be zero for any file which is not a regular fileor symlink. c_namesize may account for more than one trailing '\0', as long as thevalue doesn't exceed PATH_MAX.  This can be useful for ensuring that asubsequent file data segment is aligned, e.g. to a filesystem blockboundary. The c_chksum field contains a simple 32-bit unsigned sum of all thebytes in the data field.  cpio(1) refers to this as "crc", which isclearly incorrect (a cyclic redundancy check is a different andsignificantly stronger integrity check), however, this is thealgorithm used. If the filename is "TRAILER!!!" this is actually an end-of-archivemarker; the c_filesize for an end-of-archive marker must be zero.  Handling of hard links====================== When a nondirectory with c_nlink > 1 is seen, the (c_maj,c_min,c_ino)tuple is looked up in a tuple buffer.  If not found, it is entered inthe tuple buffer and the entry is created as usual; if found, a hardlink rather than a second copy of the file is created.  It is notnecessary (but permitted) to include a second copy of the filecontents; if the file contents is not included, the c_filesize fieldshould be set to zero to indicate no data section follows.  If data ispresent, the previous instance of the file is overwritten; this allowsthe data-carrying instance of a file to occur anywhere in the sequence(GNU cpio is reported to attach the data to the last instance of afile only.) c_filesize must not be zero for a symlink. When a "TRAILER!!!" end-of-archive marker is seen, the tuple buffer isreset.  This permits archives which are generated independently to beconcatenated. To combine file data from different sources (without having toregenerate the (c_maj,c_min,c_ino) fields), therefore, either one ofthe following techniques can be used: a) Separate the different file data sources with a "TRAILER!!!"   end-of-archive marker, or b) Make sure c_nlink == 1 for all nondirectory entries.