On 4/18/26 07:14, Michael Balzer via OvmsDev wrote:
On a second thought, maybe it's better to just guide the user, but keep all steps and their log output visible for the user in the web UI. Making the steps explicit user actions keeps the user in control (as far as possible here).
We can also ask the user to copy each step's log output, so in case something goes wrong we can get that info.
If something goes totally wrong in an automated process, the module may no longer boot. All diagnostic info would be lost in that case, as the user can then only reinstall the system via USB.
I have some ideas.
Does "ota flash" detect when the incoming image is too large to fit in the designated partition? (I'm guessing yes.)
I think a one-step process is fine. If it was done via the web gui it could use a <progress> bar with a "continue" button after each step. And when the user clicks on the button that would trigger a download of a file (config or partial log).
I would insert this to the start of the upgrade process:
continue: download backupOn 4/17/26 01:27, Mark Webb-Johnson wrote:
ota partitions store upgrade
continue: download log1> # module reset (aka ‘reboot’)
sd unmount
ota partitions store migrate
continue: download log2> # ota partitions upgrade factory
continue: download log3> # module reset (aka ‘reboot’)
I believe currently a sd card is required to create a backup. How hard would it be to add a "download backup" button that didn't require a sd card? (But I guess the follow-on problem is how to restore a config without a sd card... So maybe just warn the user to create a backup on sd in case they run into trouble.)
I figured I would want to reset my dev module back to the 3 partition setup (for future testing) so I wrote an installation script that will also be useful for recovering from a failed upgrade. I didn't see an obvious place for it in the Open-Vehicle-Monitoring-System-3 tree so I'm attaching a copy instead of a PR. Right now it only knows how to install the old 3 partition layout. I'm guessing it could go straight to the 2 partition layout with the correct partitions.bin? And /store is auto-magically populated when the code detects it has been zero'ed?
My script has a flag to erase the flash which I tested; I had assumed I clobbered the module pw but it appears to still be there. Is there somewhere aside from flash where it lives? (Just curious)
Appended is the log from when I converted my dev module back to the 3 partition layout.
Craigice 1898 % ovmsinstall.sh -v /dev/tty.SLAB_USBtoUART
- wget -q --show-progress --progress=bar:force:noscroll -O /tmp/ovmsinstall.sh.bootloader.PAQhaV https://ovms.dexters-web.de/firmware/ota/v3.3/edge/bootloader.bin /tmp/ovmsinstall.sh 100%[===================>] 22.42K 141KB/s in 0.2s
- wget -q --show-progress --progress=bar:force:noscroll -O /tmp/ovmsinstall.sh.firmware.VXmLEG https://ovms.dexters-web.de/firmware/ota/v3.3/edge/ovms3.bin /tmp/ovmsinstall.sh 100%[===================>] 3.95M 410KB/s in 10s
- wget -q --show-progress --progress=bar:force:noscroll -O /tmp/ovmsinstall.sh.partitions.haefnt https://ovms.dexters-web.de/firmware/ota/v3.3/edge/partitions.bin /tmp/ovmsinstall.sh 100%[===================>] 3.00K --.-KB/s in 0s Warning: Are you sure you want to reinstall the module? y Please enter yes or no Warning: Are you sure you want to reinstall the module? yes
- esptool.py --chip esp32 --port /dev/tty.SLAB_USBtoUART --baud 921600 --before default_reset --after hard_reset write_flash --compress --flash_mode dio --flash_freq 40m --flash_size detect 0x1000 /tmp/ovmsinstall.sh.bootloader.PAQhaV 0x10000 /tmp/ovmsinstall.sh.firmware.VXmLEG 0x8000 /tmp/ovmsinstall.sh.partitions.haefnt esptool.py v4.10.0 Serial port /dev/tty.SLAB_USBtoUART Connecting..... Chip is ESP32-D0WD-V3 (revision v3.0) Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None Crystal is 40MHz MAC: 94:b9:7e:41:88:00 Uploading stub... Running stub... Stub running... Changing baud rate to 921600 Changed. Configuring flash size... Auto-detected Flash size: 16MB Flash will be erased from 0x00001000 to 0x00006fff... Flash will be erased from 0x00010000 to 0x00402fff... Flash will be erased from 0x00008000 to 0x00008fff... SHA digest in image updated Compressed 22960 bytes to 14682... Wrote 22960 bytes (14682 compressed) at 0x00001000 in 0.5 seconds (effective 367.4 kbit/s)... Hash of data verified. Compressed 4138432 bytes to 2411643... Wrote 4138432 bytes (2411643 compressed) at 0x00010000 in 43.4 seconds (effective 763.7 kbit/s)... Hash of data verified. Compressed 3072 bytes to 152... Wrote 3072 bytes (152 compressed) at 0x00008000 in 0.0 seconds (effective 575.5 kbit/s)... Hash of data verified.
Leaving... Hard resetting via RTS pin...
Success!