[OpenWrt-Devel] Squashfs breakage lottery with UBI WAS: [PATCH RFC 2/2] amp821xx: use newly added pad-squashfs for Meraki MR24

[Christian Lamparter]

On Friday, August 30, 2019 11:10:54 PM CEST Russell Senior wrote:
> >>>>> "Christian" == Christian Lamparter <chunkeey at gmail.com> writes:
> 
> Christian> Ok.
> 
> Christian> I did push a patch titled: "build: remove harmful -nopad
> Christian> option from mksquashfs"
> Christian> <https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=1c0290c5cc6258c48b8ba46b4f9c85a21de4f875>
> 
> Christian> so, let's see if this triggers more undefined behaviour and
> Christian> exposes more hidden broken code.
> 
> Just to re-iterate my earlier worry, if for example:
> 
>   kernel_size + rootfs_with_padding_size
> 
> crosses an erase block boundary that:
> 
>   kernel_size + rootfs_without_padding_size
> 
> does not, then we'll be wasting an erase block of flash space on NOR.
Not to worry. I guess that part of the magic is also explained in the wiki:
<https://openwrt.org/docs/techref/flash.layout#example_flash_partitioning>
<https://openwrt.org/docs/techref/flash.layout#explanations>
In case my attempt now gets too confusing :-/.

The "rootfs" partition also contains the rootfs_data inside. It should
be possible to verify this with any of the routers that use the "firmware"
parition label.

Please check /proc/mtd. For example on my WNDR3700v2 (which is very similar
to your WNDR3800). It looks like this

|# cat /proc/mtd
|dev:    size   erasesize  name
|mtd0: 00050000 00010000 "u-boot"
|mtd1: 00020000 00010000 "u-boot-env"
|mtd2: 00f80000 00010000 "firmware"
|mtd3: 0018c440 00010000 "kernel"
|mtd4: 00df3bc0 00010000 "rootfs"
|mtd5: 00620000 00010000 "rootfs_data"
|mtd6: 00010000 00010000 "art
 
The rootfs is 14629824 Bytes = 13.95 MiB. (The kernel + uboot + env + art
fills out the remaining ~2MiB to a total of 16 MiB). So the padding we both
are talking about already has to exists between the squashfs portion and the
jffs2/overlay portion inside the "rootfs" partition and it's a full erase-size
block. Sadly, OpenWrt does not readily print the "end" of just the squashfs
partition (as it does with the kernel partition above) and your message from 
earlier with the three routers didn't include the "squashfs-split" and its
results. (I think that maybe this is the missing information that got lost?)

|[    0.655975] m25p80 spi0.0: mx25l12805d (16384 Kbytes)
|[    0.661058] 4 fixed-partitions partitions found on MTD device spi0.0
|[    0.667448] Creating 4 MTD partitions on "spi0.0":
|[    0.672234] 0x000000000000-0x000000050000 : "u-boot"
|[    0.677910] 0x000000050000-0x000000070000 : "u-boot-env"
|[    0.683834] 0x000000070000-0x000000ff0000 : "firmware"
|[    0.691804] 2 netgear-fw partitions found on MTD device firmware
|[    0.697856] Creating 2 MTD partitions on "firmware":
|[    0.702818] 0x000000000000-0x00000018c440 : "kernel"
|[    0.708443] 0x00000018c440-0x000000f80000 : "rootfs"
|[    0.713960] mtd: device 4 (rootfs) set to be root filesystem
|[    0.719688] 1 squashfs-split partitions found on MTD device rootfs
|[    0.725870] 0x000000960000-0x000000f80000 : "rootfs_data"
|[    0.731896] 0x000000ff0000-0x000001000000 : "art"


That is of course, you don't max-out the rootfs completely (to the last byte)
and leave no space for the overlay/jffs2... But in that case, mksquashfs 
should not need to add any padding since the partition is ending at a 4k block
already. (However, I don't think padjffs2 will be happy.)

> On a side note, I noticed that there were some checks[1] added to
> kernels about a year ago (early august 2018) to squashfs code[1], to
> protect against malformed squash filesystems that might have started
> triggering the boot loop. This might explain why we haven't seen the
> problem earlier (it might have been silently ignored).
> 
> [1] e.g. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=71755ee5350b63fb1f283de8561cdb61b47f4d1d
It's more of an edge case for sure. I think I've must have hit it during
the development as well. I remember having a bad squashfs after a build 
that I just could not read even with the userspace unsquashfs utils either
on my PC. So I think we really want to provide "unsquashfs"/"binwalk" able
root.squashfs for debugging as well.

Cheers,
Christian



_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel