My goal is to recover/update the 2nd fs partition (I name it “chi”) when fw update via curl or OTA.update.
With the knownledge on creating the 2nd fs partition and embed into fw.zip, I was hoping that the 2nd fs partition get updated or recover during curl or OTA.update.
using $ mos --port ws://ip/rpc ls -l chi
android-icon-192x192.png 12785
apple-icon-180x180.png 12038
chi_smart_114x114.png 8289
favicon.ico 2238
index.html 33536
First I delete “index.html” from chi folder, then I do a esp update via curl
$ curl -i -v -F filedata=@./build/fw.zip http://$ip/update
mgos_http_server.c:176 0x3fff2b0c HTTP connection from 192.168.0.77:52037
mgos_ota_core.c:253 Starting, timeout 600, commit timeout 0, mem 35960
mgos_ota_core.c:489 FW: chi_smart esp8266 3.39 20191210-143605/3.30-95-g3ab5083-master-dirty
esp_ota_backend.c:152 Slot 1, FW: chi_smart.bin -> 0x200000, FS fs.bin -> 0x48000
mgos_ota_core.c:506 0.13% total, chi.bin 512 of 524288
mgos_ota_core.c:506 16.88% total, chi.bin 262656 of 524288
esp_ota_backend.c:245 Start writing chi_smart.bin (773072) @ 0x200000
mgos_ota_core.c:506 33.64% total, chi_smart.bin 512 of 773072
mgos_ota_core.c:506 50.40% total, chi_smart.bin 262656 of 773072
mgos_ota_core.c:506 67.16% total, chi_smart.bin 524800 of 773072
esp_ota_backend.c:282 Write finished, checksum ok
mgos_ota_core.c:506 83.04% total, esp_init_data_default_v08.bin 128 of 128
esp_ota_backend.c:245 Start writing fs.bin (262144) @ 0x48000
mgos_ota_core.c:506 83.08% total, fs.bin 512 of 262144
esp_ota_backend.c:282 Write finished, checksum ok
mgos_ota_core.c:506 99.84% total, rboot.bin 512 of 2320
mgos_ota_core.c:629 Reached the end of archive
esp_ota_backend.c:330 New rboot config: prev_rom: 0, current_rom: 1 current_rom addr: 0x200000, current_rom size: 773072, current_fs addr: 0x48000, current_fs size: 262144
mgos_ota_core.c:811 Update finished, result 1 (Update applied, rebooting)
mgos_ota_core.c:852 Update requires reboot
mgos_utils.c:38 Rebooting in 500 ms
mgos_vfs.c:990 Unmounting filesystems
state: 5 -> 0 (0)
rm 0
bcn 0
del if1
del if0
usl
mode : null
mgos_system.c:42 Restarting
I see “chi.bin” in the log above. If the update is via uart, the “chi” folder will get written correctly, but with curl, the “chi” folder remain intact. Is there any flag to tell the fw update to update the content in “chi” folder?