build: remove harmful -nopad option from mksquashfs
authorChristian Lamparter <chunkeey@gmail.com>
Fri, 30 Aug 2019 14:52:25 +0000 (16:52 +0200)
committerJo-Philipp Wich <jo@mein.io>
Wed, 4 Sep 2019 11:44:20 +0000 (13:44 +0200)
commit5a102a010fe6be82d5793104acefabbbc01d6b85
treec8df300c78fe4d24dcdf3d3383eb4a782b12ef20
parentf65080793ce9c92eb63432ddd940a4a950882331
build: remove harmful -nopad option from mksquashfs

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>
(cherry picked from commit 1c0290c5cc6258c48b8ba46b4f9c85a21de4f875)
include/image.mk