build: remove harmful -nopad option from mksquashfs
authorChristian Lamparter <chunkeey@gmail.com>
Fri, 30 Aug 2019 14:52:25 +0000 (16:52 +0200)
committerRISCi_ATOM <bob@bobcall.me>
Fri, 13 Sep 2019 20:12:34 +0000 (16:12 -0400)
commit1826ad1eee9b941ebba5d7b5455578448eca11b4
tree451cb2f8e97b98437ef79340d3b736897f8f4d93
parente407bb7a089b0ee2b76c3ef4e9c69ccad1a6a020
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