LittleFS partition wiped on OTA update

[mano1979]

In my code i use LittleFS for the wifimanager. And all is working well. The update is downloaded and installed.

However after a reboot, i get into a bootloop and the files that were on the littleFS filesystem are gone.

Is there a way to tell the OTA-Pull to start writing at a certain memory location? No idea if it works like that...

This is the output if i upload the sketch over usb:
`Sketch uses 1138140 bytes (86%) of program storage space. Maximum is 1310720 bytes.
Global variables use 36236 bytes (11%) of dynamic memory, leaving 291444 bytes for local variables. Maximum is 327680 bytes.
esptool.py v4.6
Serial port COM3
Connecting...
Chip is ESP32-C3 (revision v0.4)
Features: WiFi, BLE
Crystal is 40MHz
MAC: 9c:9e:6e:c3:73:f4
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Configuring flash size...
Flash will be erased from 0x00000000 to 0x00004fff...
Flash will be erased from 0x00008000 to 0x00008fff...
Flash will be erased from 0x0000e000 to 0x0000ffff...
Flash will be erased from 0x00010000 to 0x00130fff...
Compressed 18688 bytes to 12099...
Writing at 0x00000000... (100 %)
Wrote 18688 bytes (12099 compressed) at 0x00000000 in 0.2 seconds (effective 609.6 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 146...
Writing at 0x00008000... (100 %)
Wrote 3072 bytes (146 compressed) at 0x00008000 in 0.0 seconds (effective 656.4 kbit/s)...
Hash of data verified.
Compressed 8192 bytes to 47...
Writing at 0x0000e000... (100 %)
Wrote 8192 bytes (47 compressed) at 0x0000e000 in 0.1 seconds (effective 872.1 kbit/s)...
Hash of data verified.
Compressed 1180208 bytes to 727892...
Writing at 0x00010000... (2 %)
Writing at 0x0001acb9... (4 %)
Writing at 0x00026d60... (6 %)
Writing at 0x0002c0f9... (8 %)
Writing at 0x000330c5... (11 %)
Writing at 0x0003d130... (13 %)
Writing at 0x00047aa5... (15 %)
Writing at 0x0004daee... (17 %)
Writing at 0x00053bce... (20 %)
Writing at 0x00059979... (22 %)
Writing at 0x0005fd02... (24 %)
Writing at 0x00066746... (26 %)
Writing at 0x0006d806... (28 %)
Writing at 0x000738ed... (31 %)
Writing at 0x00079ba2... (33 %)
Writing at 0x0007f7f9... (35 %)
Writing at 0x00085b83... (37 %)
Writing at 0x0008ba52... (40 %)
Writing at 0x0009185a... (42 %)
Writing at 0x00097890... (44 %)
Writing at 0x0009d25a... (46 %)
Writing at 0x000a2b68... (48 %)
Writing at 0x000a85bd... (51 %)
Writing at 0x000ae28d... (53 %)
Writing at 0x000b46e8... (55 %)
Writing at 0x000ba6a2... (57 %)
Writing at 0x000bfc30... (60 %)
Writing at 0x000c54fd... (62 %)
Writing at 0x000cb0dd... (64 %)
Writing at 0x000d1961... (66 %)
Writing at 0x000d7371... (68 %)
Writing at 0x000dcee9... (71 %)
Writing at 0x000e3247... (73 %)
Writing at 0x000e8e02... (75 %)
Writing at 0x000eeef6... (77 %)
Writing at 0x000f5023... (80 %)
Writing at 0x000fb44b... (82 %)
Writing at 0x001016bc... (84 %)
Writing at 0x0010799b... (86 %)
Writing at 0x0010d82b... (88 %)
Writing at 0x001137f2... (91 %)
Writing at 0x0011aa94... (93 %)
Writing at 0x00121025... (95 %)
Writing at 0x00127264... (97 %)
Writing at 0x0012d443... (100 %)
Wrote 1180208 bytes (727892 compressed) at 0x00010000 in 8.3 seconds (effective 1133.0 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...
`

[MattPellegrini]

Please use arduino stack exchange, or some other stack exchange or appropriate forum to ask these questions. This is not the right place for such questions and you'll likely get better engagement and answers there anyway.

When you post there, please include:

• A link to your code (ideally, or at least all relevant code properly formatted in code blocks)
• Your partition table
• Details of how you're developing (pio + vscode or arduino IDE)

Link the post here and I'll take a look.

[mrcodetastic]

@mano1979 - Are you saying that when you use OTA-pull to write new firmware after having anyway wrote the original firmware + LittleFS partition with an IDE... That the LittleFS partition then becomes unreadable?

Are you sure your new version of the software (firmware component) has the same partition configuration?

@MattPellegrini - Not sure what stack exchange has to do with it. Pretty critical issue with the library if it makes existing FS partitions unreadable. Will test this in my fork of the library.

I've asked the maintainer of this library to give me contributor access, but have got no response. I hope they're are ok IRL.

[MattPellegrini]

I suggested generic forums to get better assistance. I believe (perhaps incorrectly, but based on previous posts) that the issue author is not experienced in Esp32 programming. I suspect this is not a library issue but a generic one. Specifically that the partition table doesn't match or is misconfigured. Asking in generic forums will get many more eyes on the problem and better help for the author. If a concrete and reproducible issue is found with the library - then is the right time to post here with the steps to reproduce the issue.

Yes the library author is unresponsive, which is a shame, but this library amounts to a few hundred lines of code (and one file) - I just made a local copy to support https as per my previous issue.

I'm not sure why the maintainer doesn't respond, but if I were the maintainer, you'd have better luck with your pull request if you broke it up to make reviewing easier. One functional change at a time, not made noisy with formatting changes (keep those to a separate commit and pull request, including the linter config used so others can reproduce). But I wouldn't bother with that work until your hear back from the maintainer, since as you state, they are unresponsive.

They seem fine IRL based on other GitHub activity, this may just not be a focus for them right now :)