While the -nopad option prevents mksquashfs from padding the
image to an arbitrary 4k. It does not take into consideration
that squashfs is programmed to have this 4k padding when it's
being used on on a block device... which is its main "use-case".
Now, after a week long discussion on the ML that included a
back-and-forth between some of the possible options.
But this is likely the best KISS patch to deal with the issue
right away given the limited resources.
From squashfs code point of view, be warned. The 4k padding is
not enough when dealing with devices that have a PAGE_SIZE
bigger than 4k.
if it turns out to be affecting you, then please look-up either:
"FS#2460 - kernel panic reading squashfs from ubi volume" bug
Or the discussion on the OpenWrt-Devel ML in
"amp821xx: use newly added pad-squashfs for Meraki MR24" and
"Squashfs breakage lottery with UBI..."
before making an educated guess.
Note: This will not affect the "tiny"/small flash devices as
much as it seems at first. This is because the the rootfs_data
partition that follows uses jffs2. And it requires to be aligned
to the flash block-size in order to work at all.
So either the involved FSes will meet in the middle as before,
or not at all. But in that latter case the image was already
hoping for the "undefined behaviour" gamble to turn out in its
favour and this is probably why this was unnoticed for so long.
Fixes: FS#2460
Reported-by: Russell Senior <russell@personaltelco.net>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
define Image/mkfs/squashfs
$(STAGING_DIR_HOST)/bin/mksquashfs4 $(call mkfs_target_dir,$(1)) $@ \
define Image/mkfs/squashfs
$(STAGING_DIR_HOST)/bin/mksquashfs4 $(call mkfs_target_dir,$(1)) $@ \
- -nopad -noappend -root-owned \
+ -noappend -root-owned \
-comp $(SQUASHFSCOMP) $(SQUASHFSOPT) \
-processors 1
endef
-comp $(SQUASHFSCOMP) $(SQUASHFSOPT) \
-processors 1
endef
projects / openwrt / openwrt.git / commitdiff