Message ID | 87a7c1qxl2.fsf@husum.klickitat.com |
---|---|
State | Superseded, archived |
Delegated to: | Christian Lamparter |
Headers | show |
Series | [OpenWrt-Devel,RFC,1/2] build: add squashfs padding infrastructure | expand |
diff --git a/include/image-commands.mk b/include/image-commands.mk index 89c17aec5b..59dcf4e429 100644 --- a/include/image-commands.mk +++ b/include/image-commands.mk @@ -242,6 +242,11 @@ define Build/pad-rootfs $(if $(BLOCKSIZE),$(BLOCKSIZE:%k=%),4 8 16 64 128 256) endef +define Build/pad-squashfs + dd if=$(KDIR)/root.squashfs of=$(KDIR)/root.squashfs.new bs=4k conv=sync + mv $(KDIR)/root.squashfs.new $(KDIR)/root.squashfs +endef + define Build/pad-offset let \ size="$$(stat -c%s $@)" \
Normally, root.squashfs should not be padded for alignment purposes, because particularly on NOR flash it is typically concatenated with other objects, like the kernel and device tree. However, in some cases we do want the root.squashfs to be padded, in particular when it is written into a ubi volume by itself. The kernel wants to read the squashfs in chunks, apparently either 1k or 4k bytes at a time. Because ubi volumes are allocated in logical erase blocks (LEBs) which are typically *not* powers of two (as some of the underlying space is used for metadata), a non-padded squashfs can align on the LEBs in such a way that a block read near the end of the squashfs can bleed into an area that is not part of the ubi volume, resulting in a kernel panic. One such kernel panic was recently observed in a corner case on Meraki MR24. On the MR24, the LEBs are 15.5 kiB in size. If rootfs sizes were uniformily distributed, it would be expected to see such a kernel panic for about 1/4 of the possible rootfs sizes. This commit adds some infrastucture to allow the padding of a root.squashfs to 4k boundaries. Signed-off-by: Russell Senior <russell@personaltelco.net> --- include/image-commands.mk | 5 +++++ 1 file changed, 5 insertions(+)