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 _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
