OK, will force sysupgrade - and failsafe. Not quite sure what to look for yet ... 
. Will poke around though!
Hmmm ... in failsafe, did mount_root, but got,
mount_root: no usable overlay filesystem found, using tmpfs overlay
Thinking this may be part of the issue? Nothing in /overlay, which is where I assume the config should be stored?
OK, not so sure now this is specific to this device / load. I see on the restore (from file), in the serial log,
[ 7.335532] jffs2: notice: (456) jffs2_build_xattr_subsystem: complete building xattr subsystem, 3 of xdatum (2 unchecked, 1 orphan) and 6 of xref (1 dead, 0 orphan) found.
[ 7.368041] mount_root: switching to jffs2 overlay
[ 7.409920] overlayfs: upper fs does not support tmpfile.
And checking, files are there (in /overlay/upper). But, on sysupgrade (and I have noticed this before),
[ 82.932356] jffs2_scan_eraseblock(): End of filesystem marker found at 0x7000
[ 82.963302] jffs2_build_filesystem(): unlocking the mtd device...
[ 82.963396] done.
[ 82.979592] jffs2_build_filesystem(): erasing all blocks after the end marker...
[ 121.966001] done.
[ 121.984820] jffs2: notice: (1599) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found.
[ 122.253091] overlayfs: upper fs does not support tmpfile.
This is roughly 2 minutes in! But, way back at 7 seconds again,
[ 7.157593] mount_root: no usable overlay filesystem found, using tmpfs overlay
So when mount_root runs, jffs2 isn't there yet.
Thoughts?
AFAIK this is normal behavior for a firstboot. preinit cycle attempts to mount jffs2, does not find it. That is what triggers the rest...jffs2_scan_eraseblock() and jffs2_build_filesystem()
I'm more interested in the integrity of sysupgrade.tgz before jffs2 is made
Before you do this, get rid of the append-metadata from tftp install first i guess...
Okay so looking at what you said...looks like this is more complicated than I thought...
Lets do a hacky thing instead...
The file that triggers config restore is
package/base-files/files/lib/preinit/80_mount_root
it does so with the lines
tar xzf /sysupgrade.tgz
sync
So do a make clean, build an image after removing those lines (and you can edit the echo if you want). Then after firstboot the file will still be there in root after jffs2 is built. You can check it's integrity with binwalk or whatever and unpackage it yourself with the same command.
An alternative hack...stop the automatic reboot after upgrade
in this file remove the last section, everything after v "Rebooting system..."
package/base-files/files/lib/upgrade/do_stage2
Does this error affects HT-TM05 too? Or just RP-WD03? 
What's your device recipe?
I'm unsure if it's caused by mtd-concat, because if it affects then ENS202EXT would be affected too.
@mpratt14, append-metadata shouldn't do anything bad here, as the current RP-WD03 recipe uses sysupgrade.bin for the initial OpenWrt flashing over OEM firmware since the beginning.
About the sysupgrade problem, ... I don't have anything in mind whats happening here. 
Will do this, but thinking it's a side issue - take care of it (a bit later)? And does it mean we're back to two different rootfs images?
Will do this, no image needed that way 
OK, need to dig a bit more here ... modifying it on the router itself, and I see (but haven't found yet, platform_copy_config). => Hmmm ... finding it in the source, but not sure the mt7620 is pulling this in?!?!
Well THAT didn't work 
. Disabled those lines, still rebooted. Let me dig some more this evening.
Thanks!
It's the opposite...
raw source code doesn't exist on the router, this has to be done before building
This is part of the "base-files" package that you see in OPKG
Edit: I see that it's a shell...but the other scripts might be calling it from /rom
editing the preinit might work better
package/base-files/files/lib/preinit/80_mount_root
Edit 2: remember unmounting /overlay is one of the first steps in upgrade...so changed files don't exist anymore
yes....I guess, unless you want to combine them into one factory.bin with padding
You can do both of these things for your next image 
OK, trying to understand, sorry. I do see script files on the router ... editing those (to disable reboot) won't work? Thanks!
Agreed! Will tuck it away for now, fix the sysupgrade first.
What is odd ... archive (restore) works fine. I would have thought they are similar mechanisms - no?
@arrmo, do you have the OKLI sysupgrade and factory files from the time when the there was only one firmware partition?
Or should I do it for you?
It seems that JFFS2 partition (/overlay) gets unmounted before that script is ran, so that is making it use the "original" from squashfs when it was built
I could try stock v19.07 ... thoughts?
OK, dumb question ... where the heck is that? LOL. It just seems that for some reason sysupgrade doesn't write the info out, but restore does? Still trying to wrap my head around that
Oh, and BTW ... sysupgrade -T /tmp/openwrt-ramips-mt7620-ravpower_wd03-squashfs-sysupgrade.bin is just fine. Issue was a copy timeout on my side. One less issue to worry about ... LOL!
I'm building one for you. I was lazy so just dropped the kernel flashspace from firmware.
I'd like to check if it's mtd-concat or not.
Here is the diff:
diff --git a/target/linux/ramips/dts/mt7620n_ravpower_wd03.dts b/target/linux/ramips/dts/mt7620n_ravpower_wd03.dts
index 2a3dca79c8..5bd2ee1708 100644
--- a/target/linux/ramips/dts/mt7620n_ravpower_wd03.dts
+++ b/target/linux/ramips/dts/mt7620n_ravpower_wd03.dts
@@ -40,7 +40,7 @@
virtual_flash {
compatible = "mtd-concat";
- devices = <&firmware1 &firmware2 &firmware3>;
+ devices = <&firmware2 &firmware3>;
partitions {
compatible = "fixed-partitions";
@@ -49,7 +49,7 @@
partition@0 {
compatible = "openwrt,okli";
- label = "firmware";
+ label = "firmware-mtd-concat";
reg = <0x0 0x0>;
};
};
@@ -121,7 +121,8 @@
};
firmware1: partition@200000 {
- label = "firmware1";
+ compatible = "openwrt,okli";
+ label = "firmware";
reg = <0x200000 0x600000>;
};
};
diff --git a/target/linux/ramips/mt7620/config-4.14 b/target/linux/ramips/mt7620/config-4.14
index c4bf303b08..635b3c67f8 100644
--- a/target/linux/ramips/mt7620/config-4.14
+++ b/target/linux/ramips/mt7620/config-4.14
@@ -162,7 +162,6 @@ CONFIG_MTD_SPLIT_JIMAGE_FW=y
CONFIG_MTD_SPLIT_SEAMA_FW=y
CONFIG_MTD_SPLIT_TPLINK_FW=y
CONFIG_MTD_SPLIT_UIMAGE_FW=y
-CONFIG_MTD_VIRT_CONCAT=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_PER_CPU_KM=y
CONFIG_NET_RALINK_GSW_MT7620=y
diff --git a/target/linux/ramips/mt7620/config-5.4 b/target/linux/ramips/mt7620/config-5.4
index fcbd7e8a32..edeff27472 100644
--- a/target/linux/ramips/mt7620/config-5.4
+++ b/target/linux/ramips/mt7620/config-5.4
@@ -174,7 +174,6 @@ CONFIG_MTD_SPLIT_JIMAGE_FW=y
CONFIG_MTD_SPLIT_SEAMA_FW=y
CONFIG_MTD_SPLIT_TPLINK_FW=y
CONFIG_MTD_SPLIT_UIMAGE_FW=y
-CONFIG_MTD_VIRT_CONCAT=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_PER_CPU_KM=y
CONFIG_NET_RALINK_GSW_MT7620=y
Btw, yes, it would be nice if 19.07 would have this bug too! 
Please try it!
Will do! Realized I need to TFTP that, not sysupgrade => need to replace loader also.
And here are the files: ravpower-wd03-lzma-loader-03.tar.gz
Thanks! Sadly, I see the flash trash happened again, this time with the RAVPower. Arrgh! Here is the serial log, I can see now why it happened, but seems like a bug to me 
Input kernel filename:kernel
netboot_common, argc= 3
NetTxPacket = 0x81FE3F00
KSEG1ADDR(NetTxPacket) = 0xA1FE3F00
NetLoop,call eth_halt !
NetLoop,call eth_init !
Trying Eth0 (10/100-M)
Waitting for RX_DMA_BUSY status Start... done
ETH_STATE_ACTIVE!!
*** ERROR: `serverip' not set
Erase(0x50000, 2013200140)
raspi_erase: offs:50000 len:77feff0c
................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
I had turned away for a minute, too late after. OK, back to the HooToo for now, no ability to re-flash the RAVPower
Your file OK for the HooToo also?
Sorry...
squashfs is the read-only file system of rootfs
rootfs = squashfs + jffs2
the squashfs gets mounted as /rom
the jffs2 gets mounted as /overlay
you edited a file that also exists in /rom
when /overlay gets unmounted, your changes don't exist anymore
Yeah that looks like a huge bug....
Just checking, the size of the image you tried to flash is normal right? less than 8 MB?
1 Like