On Mon, 12 Jun 2017, Marcin Szewczyk wrote: > during my experiments with initramfs I have noticed there is something > that looks like a bug in the 9-year old code[1] of the clean_rootfs() > function in init/initramfs.c. An inconsistent behaviour appears when > I have both the built-in initramfs and the one in the external file but > the latter is somehow damaged (e.g. wrong padding).
... > I am aware that this is not a serious bug (if a bug at all) but I would > like this note to last in the mailing list archive because debugging it > took me some time and possibly some could stumble upon it as well. Then, here is another very minor gotcha (or feature?) people might want to be aware of. When using *early* initramfs images (e.g. for microcode updates), the files are searched for using the full path. You do *not* have to include the directories a, then a/b, then a/b/c in that exact order, to finally have a file a/b/c/d. It is enough to just have file a/b/c/d. So, you can just have /kernel/x86/microcode/<processor_vendor>.bin (without leading /kernel, /kernel/x86, /kernel/x86/microcode) in an early initramfs, and it will *work* for early microcode update purposes. However, the kernel will attempt to merge the contents of these early initramfs images into the final initramfs. For that to work, you need the leading directories (path components) to be created before their children and in the correct order, because the kernel will not supply any that are missing: instead, it will drop objects it can't create when their parent directories were not created beforehand. So, if the early initramfs has a/, a/b, and e/f/g/h, the kernel can use a/b and e/f/g/h for early initramfs purposes (e.g. microcode updates, ACPI table overrides, etc), but only a/ and a/b are likely to be present in the final initramfs. e/f/g/h will likely be dropped, because some leading path components are missing (e/, e/f, e/f/g)... *unless* they were created by a previously-loaded initramfs segment. I am not aware of anything that makes use of this behavior, but it is there since early initramfs images were introduced. -- Henrique Holschuh