build: remove harmful -nopad option from mksquashfs
authorChristian Lamparter <chunkeey@gmail.com>
Fri, 30 Aug 2019 14:52:25 +0000 (16:52 +0200)
committerChristian Lamparter <chunkeey@gmail.com>
Fri, 30 Aug 2019 18:45:40 +0000 (20:45 +0200)
commit1c0290c5cc6258c48b8ba46b4f9c85a21de4f875
tree915cd6e2fdf61886c39519893e95e8a455d9a6af
parentdb97cb814cc842b287c54397c3fc145ef5a8f286
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>
include/image.mk