[Ovmsdev] Config store mount failure / reformatting

[Michael Balzer]

OK, our esp-idf repository is now rolled back to the previous commit.

After pulling you may need to explicitly "git checkout master" -- verify you're on commit 812f959cec635cb7a849085bcc46711bd57ff0c9.

You also will need to do a "git submodule update" afterwards.

I've checked the esp-idf issues for a vfs_fat corruption thread, it seems we're first. As it's not clear how to reproduce the bug (and is it possibly our
fault?), I hesitate opening an issue without further details. I only have the mount failure code 13.

The problem has now been reported by more users in the german forum, but also without detail. One user booted into the old 3.1.009 main release but also had the
configuration erased on that boot, so it seems the corruption happens already before reboot.

Regards,
Michael


Am 22.08.2018 um 09:21 schrieb Michael Balzer:
> I just wanted to report the same, except on my unit it hasn't happened during flashing but on (I assume) a reboot after a crash somewhere yesterday evening.
>
> I'll do the rollback on our esp-idf repository this evening.
>
>
> Am 22.08.2018 um 05:06 schrieb Mark Webb-Johnson:
>> I just updated my test box, and the same thing happened. It had been rock-solid for months.
>>
>>     I (562) ovms_main: Mounting CONFIG...
>>     Initialising OVMS CONFIG within STORE
>>     E (822) config: Error: Cannot open config store directory
>>
>>
>> Downgraded to 3.1.009, but still can’t mount store.
>>
>> I’m pretty sure there is something in the new IDF that is corrupting FAT filesystems on flash.
>>
>> We need to roll-back. I’ve disabled nightly builds until we can resolve this.
>>
>>> I wonder if there could be a better strategy than immediately formatting the config filesystem on a mount error. Is there any chance the mount fails due to
>>> some race condition, i.e. would it make sense to first retry mounting after a short delay?
>>
>> I’m not seeing a reformat of the flash, just a failure to mount. The reformat option is part of the fat mount option. We can certainly turn it off, or
>> delay/retry it, but it is required for initial boot of a new device.
>
>> Regards, Mark.
>>
>>> On 19 Aug 2018, at 7:23 PM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>>>
>>> I've pulled the latest esp-idf updates, merges, builds and runs without issues. Btw, the idf now includes a CAN driver, may be worth a look.
>>>
>>> On the second app-flashing, this happened:
>>>
>>>     …
>>>     Wrote 2399584 bytes (1382879 compressed) at 0x00010000 in 26.1 seconds (effective 736.0 kbit/s)...
>>>     Hash of data verified.
>>>
>>>     Leaving...
>>>     Hard resetting via RTS pin...
>>>     …
>>>     I (452) ovms_main: Mounting CONFIG...
>>>     W (722) vfs_fat_spiflash: f_mount failed (13)
>>>     I (722) vfs_fat_spiflash: Formatting FATFS partition, allocation unit size=4096
>>>     I (1152) vfs_fat_spiflash: Mounting again
>>>     Initialising OVMS CONFIG within STORE
>>>
>>> :-(
>>>
>>> The first flash was perfectly OK and I haven't been able to reproduce this afterwards.
>>>
>>> I don't think this is related to idf changes, as we had some reports on lost configs before. Issue #145 also seems to be solved by the new idf, I had no
>>> more crashes during reboots.
>>>
>>> I wonder if there could be a better strategy than immediately formatting the config filesystem on a mount error. Is there any chance the mount fails due to
>>> some race condition, i.e. would it make sense to first retry mounting after a short delay?
>>>
>>> Regards,
>>> Michael
>>>
>>> -- 
>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>>
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> -- 
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180822/f9977f71/attachment.htm>