Now it makes sense, just wondering why the first method did end up in a endless loop sad.
One reason could be the different stock layout?
From the partition layout you posted, "OS1" on stock firmware has the length of 0xc80000 or 13107200, while on PandoraBox it's:
% fgrep firmware < /proc/mtd
mtd4: 00f80000 00010000 "firmware"
Or 16252928, so there is some discrepancy. However OS1 is still larger than the firmware image file, so there issue is not here really.
But one hypothesis come to my mind, you do (at a specific time) erase the script that is running at start up, right? What if it's not possible to erase it? It will do the changes again and again and again.
I think you're onto something here. The /etc/rc.local script removes itself after it's done and before rebooting the system. But since it's in the ROM partition, it cannot really be deleted, so what happens is that a symbolic link is created on the /overlay partition with the target (overlay-whiteout) to mark it as deleted.
So if the /overlay partition were not mounted when it was trying to delete itself, it would just get an error saying something like rm: Read-only filesystem and then it would still be present upon the next boot.
One reason this could happen is if the JFFS2 (writeable) filesystem failed to be initialized because it didn't find its marker (0xDEADC0DE).
The JFFS2 initialization problem will usually appear when going from larger to smaller firmware and there is some leftover garbage in the partition that interferes with the supposedly empty space that is assigned to JFFS2. I think that's what likely happened here, especially as, if I recall correctly, Xiaomi stock images are in the neighborhood of 12MB. So I'd venture a guess that reflashing from stock would have probably worked if you first did an mtd erase OS1.
The firmware image includes the part called a padding to remedy that but I set the build script not to exceed 8MB in size when creating the padding, as I got the impression that it would break the flashing compatibility in some situations. Since the kernel and filesystem are already nearly 8MB by themselves that means the full padding is not appended. Perhaps the limit can be lifted so that the Optimal image includes the whole padding (about 150 kB). Then erasing the partition beforehand would not be necessary in such a scenario.
Still, no matter what it shouldn't end up with a boot loop. It's funny that when I wrote the script it didn't appear to me such a thing could happen (and in fact it just did). Now it seems obvious that, at the very least, the first line of /etc/rc.local should be something like:
fgrep -qs /overlay < /proc/mounts || exit 1
Thanks for bringing this interesting scenario to my attention.
Yeah, it worked great for me the couple of times I got to use it. Just be careful flashing it. There's no USB mode but instead you just plug in the Ethernet cable, get a DHCP lease automatically, point your browser to http://192.168.1.1, and flash whatever you want (even another bootloader). You can also run a program instead of pressing the Reset button on the router. Caveat: it's in Chinese only.