CC upgrade to LEDE Configuration files lost

zimiao815 · March 19, 2019, 3:38am

hi
board info : zbt-we826. soc 7620a.
before upgrade is CC15.05 firmware, /sbin/sysupgrade upgrade to LEDE17.01.5 (version r3919-38e704be71) with save config.but The configuration is lost after the device starts normally. the device config info is LEDE Factory settings。

&spi0 {
        status = "okay";

        en25q128@0 {
                #address-cells = <1>;
                #size-cells = <1>;
                compatible = "jedec,spi-nor";
                reg = <0>;
                spi-max-frequency = <10000000>;

                partition@0 {
                        label = "u-boot";
                        reg = <0x0 0x30000>;
                        read-only;
                };

                partition@30000 {
                        label = "u-boot-env";
                        reg = <0x30000 0x10000>;
                        read-only;
                };

                factory: partition@40000 {
                        label = "factory";
                        reg = <0x40000 0x10000>;
                        read-only;
                };

                partition@50000 {
                        label = "firmware";
                        reg = <0x50000 0xfb0000>;
                };
        };
};

what should I do ？ next
Thank you very much for your help.！！！！

jeff · March 19, 2019, 3:49am

I'm not sure why you're showing DTS.

The config from Chaos Calmer isn't compatible with that of current OpenWrt releases. One needs to re-configure when moving to a modern OpenWrt release.

zimiao815 · March 19, 2019, 8:55am

jeff：Thank you very much for your reply
My previous device（7620A） was using Chaos Calmer, and now I want to be unified with other devices（QCA9531，X86），Need to save the configuration upgrade remotely，
So I have to solve this problem。
Remote upgrade of QCA9531 series equipment is no problem。（cc to lede is ok）
But 7620A series has this problem
What is the essential cause of this problem, can't it be solved?

trendy · March 19, 2019, 10:02am

Take a backup from the device before the upgrade, then upgrade without preserving the configuration. After the device is up with the new version of the OS manually restore the configuration, paying attention to deprecated or changed options.
As Jeff mentioned earlier the versions you are upgrading from and to are not compatible.

zimiao815 · March 19, 2019, 10:34am

trendy Thank you very much for your reply
I need to solve it, achieve compatibility, tens of thousands of devices certainly can't do this；

Do you want to express that this thing is not compatible, is it?

trendy · March 19, 2019, 11:38am

It might work, but no one can guarantee that there will be no problems whatsoever.

mk24 · March 19, 2019, 1:02pm

The WE-826 should have 16/128 memory, which is adequate flash and RAM to run the latest versions such as 18.06.

If you need to configure thousands of identical devices identically I suggest using Image Builder to create a custom image with all of the necessary packages and pre-configured config files packed in. After testing it thoroughly in the lab it would be safe to deploy remotely.

zimiao815 · March 20, 2019, 1:36am

trendy Thank you very much for your reply;

I guess it is caused by the difference in the default kernel size of the 7620A in CC and LEDE compilation environments.Do you know the default kernel size of both?

zimiao815 · March 20, 2019, 1:37am

mk24 Thank you very much for your reply;

I guess it is caused by the difference in the default kernel size of the 7620A in CC and LEDE compilation environments.Do you know the default kernel size of both?

jeff · March 20, 2019, 1:53am

"Comparing apples and apples" (as I don't see the ZBT-WE826 in the archives)

jeff@deb-devel:~/_tmp$ binwalk openwrt-15.05.1-ramips-mt7620-mt7620a-squashfs-sysupgrade.bin 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             uImage header, header size: 64 bytes, header CRC: 0x2FED2F03, created: 2016-02-02 12:53:41, image size: 1179580 bytes, Data Address: 0x80000000, Entry Point: 0x80000000, data CRC: 0xF0770871, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "MIPS OpenWrt Linux-3.18.23"
64            0x40            LZMA compressed data, properties: 0x6D, dictionary size: 8388608 bytes, uncompressed size: 3506340 bytes
1179644       0x11FFFC        Squashfs filesystem, little endian, version 4.0, compression:xz, size: 2248862 bytes, 1160 inodes, blocksize: 262144 bytes, created: 2016-02-02 12:53:40

jeff@deb-devel:~/_tmp$ binwalk openwrt-18.06.2-ramips-mt7620-mt7620a-squashfs-sysupgrade.bin 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             uImage header, header size: 64 bytes, header CRC: 0x87FEED7B, created: 2019-01-30 12:21:02, image size: 1437435 bytes, Data Address: 0x80000000, Entry Point: 0x80000000, data CRC: 0x3C76FA1A, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "MIPS OpenWrt Linux-4.14.95"
64            0x40            LZMA compressed data, properties: 0x6D, dictionary size: 8388608 bytes, uncompressed size: 4497604 bytes
1437499       0x15EF3B        Squashfs filesystem, little endian, version 4.0, compression:xz, size: 2374080 bytes, 1202 inodes, blocksize: 262144 bytes, created: 2019-01-30 12:21:02

So the kernel looks to be roughly 250 kB larger.

As I understand the build process, the same kernel is used for all devices on the same target.

zimiao815 · March 20, 2019, 2:33am

trendy Thank you very much for your reply;

Ok, let me debug it.

:~/test$ binwalk 201808021830-openwrt-ramips-mt7620-zbt-wa05-16m-squashfs-sysupgrade.bin

DECIMAL         HEX             DESCRIPTION
-------------------------------------------------------------------------------------------------------
0               0x0             uImage header, header size: 64 bytes, header CRC: 0x6480F845, created: Thu Aug  2 18:28:05 2018, image size: 1148649 bytes, Data Address: 0x80000000, Entry Point: 0x80000000, data CRC: 0x9F456D13, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "MIPS OpenWrt Linux-3.18.29"
64              0x40            LZMA compressed data, properties: 0x6D, dictionary size: 8388608 bytes, uncompressed size: 3409884 bytes
1148713         0x118729        Squashfs filesystem, little endian, version 4.0, compression:  size: 8967650 bytes,  2391 inodes, blocksize: 262144 bytes, created: Thu Aug  2 18:27:22 2018 

~/test$ binwalk lede-ramips-mt7620-zbt-wa05-16m-squashfs-sysupgrade.bin 

DECIMAL         HEX             DESCRIPTION
-------------------------------------------------------------------------------------------------------
0               0x0             uImage header, header size: 64 bytes, header CRC: 0x1F68DA82, created: Sat Jul 14 03:25:14 2018, image size: 1277072 bytes, Data Address: 0x80000000, Entry Point: 0x80000000, data CRC: 0x1898F15A, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "MIPS LEDE Linux-4.4.140"
64              0x40            LZMA compressed data, properties: 0x6D, dictionary size: 8388608 bytes, uncompressed size: 4030948 bytes
1277136         0x137CD0        Squashfs filesystem, little endian, version 4.0, compression:  size: 7225026 bytes,  2678 inodes, blocksize: 262144 bytes, created: Sat Jul 14 03:25:14 2018

The kernel size is the same, it should be another problem, this is really a troublesome problem！！！

mk24 · March 20, 2019, 1:10pm

I'm not sure what the question is now. Kernel size might be an issue if it doesn't boot at all. I think you said you can install and boot a new version, but not use the "save settings" option to import the settings you were running on the old version.

As others said, that is likely normal since major versions are not intended to be absolutely compatible in this regard.

For most purposes, you should be using the 18.06.2 release build. Images that don't have a release number in the file name are snapshot builds, and sometimes those are broken.

The OpenWrt image in flash actually consists of three parts, which are stored next to each other.

Kernel. Only the bootloader uses this. During bootup, the bootloader extracts the LZMA compressed kernel image into RAM and launches it. The kernel must be stored in flash where the bootloader expects to find it. A few bootloaders have a limit on kernel size. This model is likely not one of those.
Rootfs. The rootfs is the standard directory tree of all the files that exist when the install is booted the first time. Because it is a highly compressed "squashfs" it is not practical to modify it at runtime.
roofts-data, aka jffs or overlayfs. This is another filesystem in a format that can be changed at runtime. It contains files that were added or changed from what was squashed up during the image build. These files "overlay" the rootfs. If the same file exists in both, the newer one in jffs will be used.

On a clean new install, an empty jffs is created the first time OpenWrt boots. Then several scripts run to detect hardware (especially wireless) and create skeleton config files appropriate for that particular hardware. This process can take 3 to 5 minutes on a large NOR flash. Do not cut the power, try to log into the router or save any settings until the jffs is ready to use and mounted.

For a "keep settings" install, the sysupgrade process of the old version creates a tar of certain files that are marked to be kept, especially /etc/config/*. Sysupgrade then creates a partial jffs that includes these files. Finally the kernel, rootfs, and jffs are flashed and the router rebooted. The "firstboot" of the new version knows not to format over this jffs.

You can see that "keep settings" requires a lot of cooperation between the old OpenWrt and the new OpenWrt, thus it is recommended only for changing to a new release in the same series.

zimiao815 · March 21, 2019, 2:46am

mk24;Thank you for your reply suggestion！

      I continue to work hard to solve this problem and share it with everyone.

zimiao815 · March 27, 2019, 3:29am

hello everyone：
I solved this problem！ the mtd erasesize is different
CC erasesize defaults is 0x10000 LEDE is 0x1000.
LEDE change into 0x10000

root@DEV:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00030000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
mtd2: 00010000 00010000 "factory"
mtd3: 00fb0000 00010000 "firmware"
mtd4: 00137a88 00010000 "kernel"
mtd5: 00e78578 00010000 "rootfs"
mtd6: 00780000 00010000 "rootfs_data"

--- target.orig/linux/ramips/mt7620/config-4.4
+++ target/linux/ramips/mt7620/config-4.4
@@ -138,7 +138,7 @@ CONFIG_MTD_M25P80=y
 CONFIG_MTD_NAND_MT7620=y
 CONFIG_MTD_PHYSMAP=y
 CONFIG_MTD_SPI_NOR=y
-CONFIG_MTD_SPI_NOR_USE_4K_SECTORS=y
+#CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not set
 CONFIG_MTD_SPLIT_FIRMWARE=y
 CONFIG_MTD_SPLIT_SEAMA_FW=y
 CONFIG_MTD_SPLIT_TPLINK_FW=y

system · April 6, 2019, 3:34am

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.