Hi! Any idea how to remove these files? "OVMS# vfs ls /store/usr 64 12-Sep-1965 06:34 ????????.??? 64 12-Sep-1965 06:34 ????????.??? 64 12-Sep-1965 06:34 ????????.??? 64 12-Sep-1965 06:34 ????????.??? 64 12-Sep-1965 06:34 ????????.??? 64 12-Sep-1965 06:34 ????????.??? 64 12-Sep-1965 06:34 ????????.??? 64 12-Sep-1965 06:34 ????????.??? 64 12-Sep-1965 06:34 ????????.??? 64 12-Sep-1965 06:34 ????????.??? 64 12-Sep-1965 06:34 ????????.??? 64 12-Sep-1965 06:34 ????????.??? 64 12-Sep-1965 06:34 ????????.??? 64 12-Sep-1965 06:34 ????????.??? 64 12-Sep-1965 06:34 ????????.??? 64 12-Sep-1965 06:34 ????????.??? 64 12-Sep-1965 06:34 ????????.??? 64 12-Sep-1965 06:34 ????????.??? 64 12-Sep-1965 06:34 ????????.??? ..." [image: Screenshot 2020-12-06 at 16.07.57.png]
On Sun, 6 Dec 2020, Tamás Kovács wrote:
Any idea how to remove these files? "OVMS# vfs ls /store/usr
64 12-Sep-1965 06:34 ????????.??? 64 12-Sep-1965 06:34 ????????.??? 64 12-Sep-1965 06:34 ????????.???
The filesystem is corrupted. This happened to me in 2018. Below is an edited thread of messages about this from ovmsdev list. -- Steve From: Stephen Casner <casner@acm.org> I know that I can use "config backup" to back up the config to SD. Does the re-format step mean "module factory reset"? -- Steve From: Michael Balzer <dexter@expeedo.de> Yes. You might consider saving the flash partition for further bug analysis before erasing it: https://docs.google.com/document/d/1q5M9Lb5jzQhJzPMnkMKwy4Es5YK12ACQejX_NWEi... Regards, Michael From: Stephen Casner <casner@acm.org> I will save the flash partition as you suggest. Also, in your message telling about the addition of the config backup/restore function you said the backup covers the directories "ovms_config" and "events" from "/store". I note that /store also contains a .htpasswd file. Should that also be included, or is it already? -- Steve From: Michael Balzer <dexter@expeedo.de> The .htpasswd file is generated automatically by the webserver from the password config. Regards, Michael From: Stephen Casner <casner@acm.org> What kind of <path> is expected in "config backup <path>"? I tried "/sd/config-20181221.zip" and "config-20181221.zip" but both resulted in "Error: zip failed: No such file or directory". Manually creating the empty file "/sd/config-20181221.zip" first did not help. -- Steve From: Michael Balzer <dexter@expeedo.de> I missed the case of a non-existent "/store/events" directory. I'll fix that now, to backup without updating, do "vfs mkdir /store/events". Regards, Michael From: Stephen Casner <casner@acm.org> Michael, Glad you figured that out. I had looked at the code to see if that gave me any hints as to what kind of <path> argument was required, but I could not tell from the code where the error was occurring. I notice that some other commands use <vfspath> for the help string to be more specific. Would that be a good idea for config backup? -- Steve From: Stephen Casner <casner@acm.org> On Fri, 21 Dec 2018, Michael Balzer wrote:
You might consider saving the flash partition for further bug analysis before erasing it https://docs.google.com/document/d/1q5M9Lb5jzQhJzPMnkMKwy4Es5YK12ACQejX_NWEi...
I finally got around to fixing the corrupted /store filesystem on my OVMS v3.0 module. I did save the partition first, as directed by the section of the OVMS v3 Developer Guide to which the reference above points. I also updated the instructions there to add an example of how to mount the saved filesystem on macOS rather than Linux. Looking at the whole filesystem as a raw binary file, I see that the sector at 0x00002000 is all 0xFFs. I don't know if that is what caused the "vfs ls /store" command to show 128 invalid directory entries, but after erasing the flash and rebuilding the /store filesystem and then saving the flash partition to another file on my Mac, there is not a sector of 0xFF like that. Running fsck_msdos on the broken filesystem (as attached on macOS) only shows orphaned clusters, not any invalid directory entries: auge16> fsck_msdos /dev/disk11 ** /dev/rdisk11 ** Phase 1 - Preparing FAT ** Phase 2 - Checking Directories ** Phase 3 - Checking for Orphan Clusters Found orphan cluster(s) Fix? [yn] n Found 25 orphaned clusters 19 files, 800 KiB free (200 clusters) ** Phase 1 - Preparing FAT ** Phase 2 - Checking Directories ** Phase 3 - Checking for Orphan Clusters Found orphan cluster(s) Fix? [yn] n Found 25 orphaned clusters 19 files, 1600 KiB free (400 clusters) ** Phase 1 - Preparing FAT ** Phase 2 - Checking Directories ** Phase 3 - Checking for Orphan Clusters Found orphan cluster(s) Fix? [yn] n Found 25 orphaned clusters 19 files, 2400 KiB free (600 clusters) auge17> -- Steve
Dear all, I would like to suggest a new metric for the distance and days until the next maintenance is due. This would be one more step for the VW e-UP/Mii/Citigo module to convince users to switch from the original VW cloud service (which has this feature). Attached is a suggestion how the metric could be displayed in the Android app (at the very top in front of the car). Any comments are most welcome; I would also need some guidance in how to implement the metric so it is transmitted correctly (if it is approved). Best wishes, sharkcow
I would suggest two different metrics. One for distance, one for days. Perhaps v.service.days and v.service.range? Or v.e.service.days and v.e.service.range? N.B. Tesla Roadster also has this (although we haven’t decoded the CAN bus message for it) Regards, Mark. P.S. I am not sure if it needs to be so prominent in the App? It doesn’t seem that important.
On 7 Dec 2020, at 10:17 PM, sharkcow <sharkcow@gmx.de> wrote:
Dear all,
I would like to suggest a new metric for the distance and days until the next maintenance is due. This would be one more step for the VW e-UP/Mii/Citigo module to convince users to switch from the original VW cloud service (which has this feature).
Attached is a suggestion how the metric could be displayed in the Android app (at the very top in front of the car).
Any comments are most welcome; I would also need some guidance in how to implement the metric so it is transmitted correctly (if it is approved).
Best wishes,
sharkcow
<maintenance.png>_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
I get your point. How about showing it under the energy counters as attached? If no one objects, I would submit a pull request for the app and ovms with the two new standard metrics. sharkcow Am 08.12.20 um 07:20 schrieb Mark Webb-Johnson:
I would suggest two different metrics. One for distance, one for days.
Perhaps v.service.days and v.service.range? Or v.e.service.days and v.e.service.range?
N.B. Tesla Roadster also has this (although we haven’t decoded the CAN bus message for it)
Regards, Mark.
P.S. I am not sure if it needs to be so prominent in the App? It doesn’t seem that important.
On 7 Dec 2020, at 10:17 PM, sharkcow <sharkcow@gmx.de> wrote:
Dear all,
I would like to suggest a new metric for the distance and days until the next maintenance is due. This would be one more step for the VW e-UP/Mii/Citigo module to convince users to switch from the original VW cloud service (which has this feature).
Attached is a suggestion how the metric could be displayed in the Android app (at the very top in front of the car).
Any comments are most welcome; I would also need some guidance in how to implement the metric so it is transmitted correctly (if it is approved).
Best wishes,
sharkcow
<maintenance.png>_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Hey Sharkcow Where can I take a look at the code? I didn't find new code in your repository. Greetinx Chris Am Donnerstag, den 10.12.2020, 21:16 +0100 schrieb sharkcow:
I get your point. How about showing it under the energy counters as attached?
If no one objects, I would submit a pull request for the app and ovms with the two new standard metrics.
sharkcow
Am 08.12.20 um 07:20 schrieb Mark Webb-Johnson:
I would suggest two different metrics. One for distance, one for days.
Perhaps v.service.days and v.service.range? Or v.e.service.days and v.e.service.range?
N.B. Tesla Roadster also has this (although we haven’t decoded the CAN bus message for it)
Regards, Mark.
P.S. I am not sure if it needs to be so prominent in the App? It doesn’t seem that important.
On 7 Dec 2020, at 10:17 PM, sharkcow <sharkcow@gmx.de> wrote:
Dear all,
I would like to suggest a new metric for the distance and days until the next maintenance is due. This would be one more step for the VW e-UP/Mii/Citigo module to convince users to switch from the original VW cloud service (which has this feature).
Attached is a suggestion how the metric could be displayed in the Android app (at the very top in front of the car).
Any comments are most welcome; I would also need some guidance in how to implement the metric so it is transmitted correctly (if it is approved).
Best wishes,
sharkcow
<maintenance.png>_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Sharkcow, the point is, this isn't something that needs to be present continuously. Live displays should display important momentary status data, not long term background info. It's totally sufficient to add this to the vehicle info menu. Regards, Michael Am 10.12.20 um 21:16 schrieb sharkcow:
I get your point. How about showing it under the energy counters as attached?
If no one objects, I would submit a pull request for the app and ovms with the two new standard metrics.
sharkcow
Am 08.12.20 um 07:20 schrieb Mark Webb-Johnson:
I would suggest two different metrics. One for distance, one for days.
Perhaps v.service.days and v.service.range? Or v.e.service.days and v.e.service.range?
N.B. Tesla Roadster also has this (although we haven’t decoded the CAN bus message for it)
Regards, Mark.
P.S. I am not sure if it needs to be so prominent in the App? It doesn’t seem that important.
On 7 Dec 2020, at 10:17 PM, sharkcow <sharkcow@gmx.de> wrote:
Dear all,
I would like to suggest a new metric for the distance and days until the next maintenance is due. This would be one more step for the VW e-UP/Mii/Citigo module to convince users to switch from the original VW cloud service (which has this feature).
Attached is a suggestion how the metric could be displayed in the Android app (at the very top in front of the car).
Any comments are most welcome; I would also need some guidance in how to implement the metric so it is transmitted correctly (if it is approved).
Best wishes,
sharkcow
<maintenance.png>_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@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
Thanks for the clarification Michael! I'm still on the (for me pretty steep:) learning curve... I'll move it to the vehicle info. sharkcow Am 11.12.20 um 09:09 schrieb Michael Balzer:
Sharkcow,
the point is, this isn't something that needs to be present continuously. Live displays should display important momentary status data, not long term background info.
It's totally sufficient to add this to the vehicle info menu.
Regards, Michael
Am 10.12.20 um 21:16 schrieb sharkcow:
I get your point. How about showing it under the energy counters as attached?
If no one objects, I would submit a pull request for the app and ovms with the two new standard metrics.
sharkcow
Am 08.12.20 um 07:20 schrieb Mark Webb-Johnson:
I would suggest two different metrics. One for distance, one for days.
Perhaps v.service.days and v.service.range? Or v.e.service.days and v.e.service.range?
N.B. Tesla Roadster also has this (although we haven’t decoded the CAN bus message for it)
Regards, Mark.
P.S. I am not sure if it needs to be so prominent in the App? It doesn’t seem that important.
On 7 Dec 2020, at 10:17 PM, sharkcow <sharkcow@gmx.de> wrote:
Dear all,
I would like to suggest a new metric for the distance and days until the next maintenance is due. This would be one more step for the VW e-UP/Mii/Citigo module to convince users to switch from the original VW cloud service (which has this feature).
Attached is a suggestion how the metric could be displayed in the Android app (at the very top in front of the car).
Any comments are most welcome; I would also need some guidance in how to implement the metric so it is transmitted correctly (if it is approved).
Best wishes,
sharkcow
<maintenance.png>_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
participants (6)
-
Chris van der Meijden -
Mark Webb-Johnson -
Michael Balzer -
sharkcow -
Stephen Casner -
Tamás Kovács