I'm using Buildimage and also images from the trunk repository.
Both gives me the same bug, flash is not written and reinitialized after each reboot. The flash is detected is 32MB but physically there is only 8MB available.
Does someone already report the problem and is it already under investigation ? I didn't found any reference about this proble on the forum and on the bug tracker so I opend one FS#3597.
Sorry for my late answer I was quite busy this Week-End.
It's stange, if I'm not wrong the partition table looks good
Sun Dec 6 08:18:15 2020 kern.notice kernel: [ 0.396535] 6 fixed-partitions partitions found on MTD device spi0.0
Sun Dec 6 08:18:15 2020 kern.notice kernel: [ 0.403004] Creating 6 MTD partitions on "spi0.0":
Sun Dec 6 08:18:15 2020 kern.notice kernel: [ 0.407912] 0x000000000000-0x000000020000 : "u-boot"
Sun Dec 6 08:18:15 2020 kern.notice kernel: [ 0.414284] 0x000000020000-0x000000030000 : "partition-table"
Sun Dec 6 08:18:15 2020 kern.notice kernel: [ 0.421310] 0x000000030000-0x000000040000 : "info"
Sun Dec 6 08:18:15 2020 kern.notice kernel: [ 0.427391] 0x000000040000-0x0000007c0000 : "firmware"
Sun Dec 6 08:18:15 2020 kern.notice kernel: [ 0.433919] 2 fixed-partitions partitions found on MTD device firmware
Sun Dec 6 08:18:15 2020 kern.notice kernel: [ 0.440574] Creating 2 MTD partitions on "firmware":
Sun Dec 6 08:18:15 2020 kern.notice kernel: [ 0.445637] 0x000000000000-0x000000300000 : "kernel"
Sun Dec 6 08:18:15 2020 kern.notice kernel: [ 0.451841] 0x000000300000-0x000000780000 : "rootfs"
Sun Dec 6 08:18:15 2020 kern.notice kernel: [ 0.458156] mtd: device 5 (rootfs) set to be root filesystem
Sun Dec 6 08:18:15 2020 kern.notice kernel: [ 0.471377] 1 squashfs-split partitions found on MTD device rootfs
Sun Dec 6 08:18:15 2020 kern.notice kernel: [ 0.477745] 0x000000740000-0x000000780000 : "rootfs_data"
Sun Dec 6 08:18:15 2020 kern.notice kernel: [ 0.484417] 0x0000007c0000-0x0000007f0000 : "config"
Sun Dec 6 08:18:15 2020 kern.notice kernel: [ 0.490751] 0x0000007f0000-0x000000800000 : "art"
After investigating a bit the "dmesg" I found this line indicating a problem to mount the root fils system and keep the tmpfs as root filesystem.
Sun Dec 6 08:18:15 2020 user.notice kernel: [ 10.060196] mount_root: jffs2 not ready yet, using temporary tmpfs overlay
Sun Dec 6 08:19:11 2020 daemon.err mount_root: failed - mount -t jffs2 /dev/mtdblock6 /rom/overlay: Not a tty
The last partition (art) terminates at 0x800000 (which is hexadecimal for 8388608, ie 8 MiB). So that looks OK. Can you share the output of df -h? Sounds like your overlay is not working.
Yeah, what you see is your overlayfs is put in RAM. There is no JFFS2 partition at all. If you grep your logs you'll see a message about not enough blocks being left.
It looks like you crammed too much into your image and there's not enough space on the flash left for your overlay. You'll need to strip some stuff.
ok stange, I also tried some images built by community and had the same issue.
Will try to free-up some stuff on my own build and see if I can manage to make it work.
You're welcome. Do double check and close your bug report if it's a lack of free blocks issue, since that's not an actual bug, just the result of your image being too big after adding extra stuff.
I confirm that system work after freeing space on the image and reflashing with -factory image instead of sysupgrade. I close the bug and sorry for the joke I will pay attention to the amount of flash available on device before generating a snapshot image. Just the OpenWisP agent doesn't fit on top ot the regular packages of the device.