I have a ramips mt7620a -based device that is losing it's sysupgrade.tgz config when upgraded from LEDE 17.01 series to 18.06.1. There seems to be some incompatibility when doing the 'zcat sysupgrade.bin | mtd write -j /tmp/sysupgrade.tgz - firmware', where it integrates the sysupgrade.tgz into the jffs2 filesystem.
There is plenty of free flash space (writing to a 24MB partition, ~10MB free.) This target is using a single 24MB firmware partition, having a uImage header with a kernel + rootfs, and the root filesystem is split squashfs + jffs2.
I've tried using the new mtd binary to write the image (from the old kernel/firmware), but that had no effect. I've looked at the diffs between mtd, mount_root, and kernel jffs2, but I don't see significant changes there.
Some other data points: same codebase for x86_64 and mvebu targets with ext4 upgrades/downgrades OK (they stash sysupgrade.tgz using a different mechanism). Also this ramips jffs2 downgrade from 18.06 loses its config.
Any tips on where I should be looking -- for what has changed between versions?
Yes, I was using /sbin/sysupgrade <sysupgrade_image> directly, which was in turn invoking default_do_upgrade() from /lib/upgrade/common.sh (so my comment about mtd write -j was just illustrative.)
It does log that it has written the image successfully, then successfully appended the sysupgrade.tgz file.
But when we reboot and appear on the other side, the /lib/preinit/80_mount_root isn't hitting the "- config restore -" block, as the /sysupgrade.tgz file seems to be missing.
OK upon further inspection the old and new kernels reported different erasesizes in /proc/mtd. So there was a change to the Linux kernel file drivers/mtd/spi-nor/spi-nor.c for the flash chip w25q256.
The flags went from this: SECT_4K | SPI_NOR_4B_READ_OP
to this: SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_READ_OP
So removing the new flags for this board maintains the same flash layout and erasesize, and then sysupgrade works as expected.