robot resets itself

[josch]

Hi, I followed the instructions to patch firmware v11_001792 and install valetudo and dummycloud on the device. But just today, only about 1 or 2 minutes after 3:00 in the morning, the vacuum proclaimed "restart the initial version please be patient" and now seems to be reset. I didn't do anything to it (in fact I was sleeping at the time) and now my robot is reset. Did anybody else experience this effect already?

[dugite-code]

See: https://github.com/Hypfer/Valetudo/issues/80

You vacuum will always restart around 3 or 4 am, that is normal. It's still not clear as to why sometimes it becomes un-provisioned. Valetudo should still be present on the vacuum though. I have had some slight success reducing the issue by changing the upstart config: https://github.com/Hypfer/Valetudo/issues/80#issuecomment-477834787 However I still had one drop recently, but I think that was an issue with my wifi.

The latest release of Valetudo has dummycloud built in so that's one less item to consider

[josch]

It did not just become unprovisioned. It said "restart the initial version please be patient" and this seems to indicate that it performed a factory reset? I didn't touch the robot yet to investigate the problem but restarting it via the power button doesn't help. I just see its wifi network and can query it with mirobo but I no longer can access it via ssh for example.

[dugite-code]

@josch looks like Hypfer https://github.com/Hypfer/Valetudo/issues/80#issuecomment-484414033 had a similar issue recently. You may want to head over there

[josch]

Yes, and here somebody else experienced it: https://www.roboter-forum.com/index.php?thread/33043-mein-roborock-s50-hat-sich-gestern-selbst-zur%C3%BCckgeflasht/

[jlo88]

I also had this last night, it suddenly started speaking Chinese again! Last time it happened this was on the 21st of March. So about 6 weeks ago. When this happens I also have to go through the flashing process again.

[josch]

Another possible duplicate: Hypfer/Valetudo/issues/206

[dugite-code]

@josch in the roboter-forumthe link you posted they claim that the settings in /mnt/default/roborock.conf were wrong. Have you given that a try?

As Hypfer mentioned it looks like there is an error counter somewhere that triggers a re-flash if too many errors are logger (somewhere), you could also try disabling logging maybe it'll stop the issue? disable_logging.sh

GEN1: step-by-step-conversion-from-ccc-to-ce

[dugite-code]

Further updates: https://github.com/Hypfer/Valetudo/issues/206#issuecomment-498132355 Looks like you can modify the crash counter.

Would be better to identify the issue and fix it but there is a work around

[josch]

@dugite-code I posted the contents of my roborock.conf here: https://github.com/Hypfer/Valetudo/issues/206#issuecomment-493832448

[florian-asche]

Syslog from during the restore to the old firmware: https://pastebin.com/raw/FLcvbnQ6 Version 1810.

[froodproton]

Same over here, this morning, the Robo was not available on the assigned IP and it was speaking English, although German was installed before. My problem is: Where is the original firmware coming from? Is it stored in a partition somewhere on the Robocalls although we flash it with the alternative firmware which gets copied to system_a and system_b? Or does the robo need an Internet connection to Xiaomi to download the vendors firmware? In the latter case I would be worried since I would be missing some dns "redirects" in my (router) config. It would mean that the robocalls can still connect to Xiaomi!!

[dugite-code]

It keeps a copy of the factory firmware, no downloads occur for the reset.

There still has been little progress in solving the issue for the v2. changing the dnsmasq settings fixed the v1 for me. see the previously linked Valetudo for further detaila

On November 19, 2019 9:28:08 AM UTC, froodproton notifications@github.com wrote:

Same over here, this morning, the Robo was not available on the assigned IP and it was speaking English, although German was installed before. My problem is: Where is the original firmware coming from? Is it stored in a partition somewhere on the Robocalls although we flash it with the alternative firmware which gets copied to system_a and system_b? Or does the robo need an Internet connection to Xiaomi to download the vendors firmware? In the latter case I would be worried since I would be missing some dns "redirects" in my (router) config. It would mean that the robocalls can still connect to Xiaomi!!

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/dgiese/dustcloud/issues/206#issuecomment-555413179

[prinz3nroll3]

hi, after 3 weeks firmware reset. i dont want to install few weeks the firmware.

is there some solution, no or? what about fsck every day, how can i add this?

[Xento]

Did you use the available fixes? I flashed mine with valetudo 0.4 and installed valetudo re 0.8.1 over it with a deb package. Today it seems that the robot flashed it self with the flashed valetudo 0.4 again. Settings are persisted but I was on valetudo 0.4 again instead of valetudo re 0.8.1. I Applied both fixed manually now.

[dugite-code]

Unfortunately even after all this time the cause is really still unknown. Possibly because the robot will re-flash for a multitude of errors. I myself found after this modification an increasing the crash counter I no longer encountered re-sets, however other research might point to simple file-system issues.

As mentioned in the linked comment you may want to do a fstrim as well. It could be an issue of running out of disk space.

[Xento]

I added the dnsmasq change, too now. I changed CRASH_IGNORE_MIN to 60 instead of 600. I checked /dev/mmcblk0p8 but it was clean.

I'm new to this, but does the firmware switch from mmcblk0p8 to mmcblk0p9 and than when an third issue was found switchs to the mmcblk0p7 (recovery). Maybe it would be possible to switch back to mmcblk0p8 and avoid an complete recovery.

[dugite-code]

I believe it should only have two system partitions 'A' and 'B' with one of the partitions being the boot partition. That said I've never manipulated them directly as it's a bit dangerous as you can effectively brick both partitions.

If memory serves me the recovery partition never changes and is used only to over-write the active partition if an error occurs.

I noticed this comment https://github.com/Hypfer/Valetudo/issues/206#issuecomment-570213340

@hkemal Excellent observations, thanks! Mine has only resetted once and only with logging enabled. It did a full vacuum run the day before the reset.

I just realized I actually did disable logging myself when last building my Valetudo firmware. So it's possible the fstrim really isn't being performed.

[Xento]

I think my device resettet the first time and switched from A to B. Maybe the next time it would switch from B to recovery and than it would be an full reset. So, when you know how to modify the cmdline for uBoot to use partition A again, maybe you could avoid a full reset. My device is now on /dev/mmcblk0p9 (B)

cat /proc/cmdline rootwait boot_fs=b console=ttyS0,115200 root=/dev/mmcblk0p9 rootfstype=ext4 loglevel=7 partitions=boot-res@mmcblk0p2:env@mmcblk0p5:app@mmcblk0p6:recovery@mmcblk0p7:system_a@mmcblk0p8:system_b@mmcblk0p9:Download@mmcblk0p10:reserve@mmcblk0p11:UDISK@mmcblk0p1 boot_reason=0x69617070 location=en boot_ver=2011.09-rc1-dirty