[LEDE-DEV] Sysupgrade leads to SQUASHFS error: unable to read id index table

[Felix Fietkau]

On 2016-12-12 11:58, Petr Štetiar wrote:
> Hi,
> 
> I've found some issue with squashfs possibly related to mtdblock and mtdsplit
> usage. Before digging deeper into it, I would like to ask first for any
> pointers here.
> 
> I've recently rebased my Git tree to LEDE master and rebuilt my image (haven't
> done this for month or so). I've noticed, that the resulting rootfs image has
> grown from 5MB to 7MB(going to investigate this also soon), leading to the
> following error SQUASHFS error:
> 
>   mmcblk0: mmc1:0001 004GE0 3.69 GiB
>   mmcblk0boot0: mmc1:0001 004GE0 partition 1 2.00 MiB
>   mmcblk0boot1: mmc1:0001 004GE0 partition 2 2.00 MiB
>   mmcblk0rpmb: mmc1:0001 004GE0 partition 3 512 KiB
>   3 cmdlinepart partitions found on MTD device eMMC
>   Creating 3 MTD partitions on "eMMC":
>   0x000000000000-0x000000080000 : "dtb"
>   0x000000080000-0x000000480000 : "kernel"
>   0x000000480000-0x000008480000 : "rootfs"
>   mtd: device 2 (rootfs) set to be root filesystem
>   1 squashfs-split partitions found on MTD device rootfs
>   0x000000c80000-0x000008480000 : "rootfs_data"
>   block2mtd: mtd0: [eMMC] erase_size = 512KiB [524288]
>   squashfs: SQUASHFS error: unable to read id index table
>   List of all partitions:
>   b300         3866624 mmcblk0  driver: mmcblk
>   b318             512 mmcblk0rpmb  (driver?)
>   b310            2048 mmcblk0boot1  (driver?)
>   b308            2048 mmcblk0boot0  (driver?)
>   1f00             512 mtdblock0  (driver?)
>   1f01            4096 mtdblock1  (driver?)
>   1f02          131072 mtdblock2  (driver?)
>   1f03          122880 mtdblock3  (driver?)
>   No filesystem could mount root, tried:  ext3 ext4 ext2 squashfs
>   Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,2)
>   CPU0: stopping
>   CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.36 #0
>   Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
>   Backtrace:
>   [<800234c0>] (dump_backtrace) from [<800236b8>] (show_stack+0x18/0x1c)
> 
> My kernel commandline:
> 
>   block2mtd.block2mtd=/dev/mmcblk0,524288,eMMC,5 mtdparts=eMMC:512k(dtb),4M(kernel),128M(rootfs) rootwait console=ttymxc0,115200n8
> 
> Working MTD layout before sysupgrade (old 5M rootfs):
> 
>   Creating 3 MTD partitions on "eMMC":
>   0x000000000000-0x000000080000 : "dtb"
>   0x000000080000-0x000000480000 : "kernel"
>   0x000000480000-0x000008480000 : "rootfs"
>   mtd: device 2 (rootfs) set to be root filesystem
>   1 squashfs-split partitions found on MTD device rootfs
>   0x000000a00000-0x000008480000 : "rootfs_data"
> 
> My custom sysupgrade commands:
> 
>   tar -xOf "$1" sysupgrade-$board/dtb | mtd write - dtb
>   tar -xOf "$1" sysupgrade-$board/kernel | mtd write - kernel
>   tar -xOf "$1" sysupgrade-$board/rootfs | mtd write - rootfs
> 
>   if [ "$SAVE_CONFIG" -eq 1 ]; then
>     mtd -e rootfs_data jffs2write "$CONF_TAR" rootfs_data
>   else
>     mtd erase rootfs_data
Your custom sysupgrade commands are buggy. With a dynamic
rootfs/rootfs_data split, you can never rely on the rootfs_data offset
to remain constant across upgrades.
For this to work, the rootfs needs to be padded using the pad-rootfs
build template (thus containing jffs2 end-of-filesystem markers).
You also need to append the config data while flashing the rootfs image
(using -j "$CONF_TAR").

In general, using block2mtd for rootfs/overlay split is deprecated, you
should switch to squashfs + f2fs/ext4 instead, like on x86, mvebu and
others.

- Felix