Being a Kickstarter backer, I was just lurking here, until now. I first saw this thread months ago, hoping it would change. Disappointed that it hasn't.
+1 to easy recovery.
This is the essence of an "open" system.
+1 to that … I posted to this thread back in June
last year and still check it occasionally. I'm disappointed each time to see no progress ...
Looks like the system image has been build with wrong parameters. Try using an older version.
Yeah, it's a huge drag for the OUYA lacking a proper system image recovery mechanism. :-( Although this key-combo workaround works it is nothing more than just a dirty hack. What if the kernel panics before getting to keyboard or USB initialization? This is definitely not the way to do it. I wish OUYA would finally address this problem and provide developers with a documented and proper system image recovery mechanism.
I can only speculate here. Judging by the property's name its value seems to denote the system image's build date. So, the current image's build date may be checked against the one to be installed, and only images of later date are allowed.
Since you have nothing to loose anyway but only to gain a working OUYA console again, you could try modifying the ro.build.date.utc property's value in the build.prop file to a date before or after the assert. I do not know if the build.prop is read at boot time, so I am just speculating here that this might help. But, then the system image may not pass the integrity check after it has been modified. So, this is just some awkward attempt to get past the assert test.
Perhaps resetting the OUYA console's internal real time clock would help. Apparently, the board does not have a battery to power the real time clock when it's off grid power. Again, I am just assuming here; it probably has some sort of capacitor for this job. How long does it last when it's offline? I don't know. Can you discharge this capacitor somehow? Probably, but I don't know for sure. I am not a hardware tinkerer.
Please beware that these are just suggestion, not hints or advice how to repair your OUYA console. Anyway, good luck! :-)
Tried removing the first line in the script as suggested elsewhere on the web, so that it simple doesn't perform the check. It still fails with the above display only without the assert failed: line.
@spinal_cord, I am aware that this thread is old and you may have resolved the issue by now, but the solution to the error you were getting "assert failed" is to use a newer update of the firmware. The sideloading process checks to see if the version you are flashing is the same or newer than the one currently on the device, effectively preventing a flash of an old firmware.
I am mainly replying to this as it just did not have a good answer to @spinal_cord's issue.
Comments
+1 to that … I posted to this thread back in June last year and still check it occasionally. I'm disappointed each time to see no progress ...
Looks like the system image has been build with wrong parameters. Try using an older version.
Yeah, it's a huge drag for the OUYA lacking a proper system image recovery mechanism. :-( Although this key-combo workaround works it is nothing more than just a dirty hack. What if the kernel panics before getting to keyboard or USB initialization? This is definitely not the way to do it. I wish OUYA would finally address this problem and provide developers with a documented and proper system image recovery mechanism.
I can only speculate here. Judging by the property's name its value seems to denote the system image's build date. So, the current image's build date may be checked against the one to be installed, and only images of later date are allowed.
Since you have nothing to loose anyway but only to gain a working OUYA console again, you could try modifying the ro.build.date.utc property's value in the build.prop file to a date before or after the assert. I do not know if the build.prop is read at boot time, so I am just speculating here that this might help. But, then the system image may not pass the integrity check after it has been modified. So, this is just some awkward attempt to get past the assert test.
Perhaps resetting the OUYA console's internal real time clock would help. Apparently, the board does not have a battery to power the real time clock when it's off grid power. Again, I am just assuming here; it probably has some sort of capacitor for this job. How long does it last when it's offline? I don't know. Can you discharge this capacitor somehow? Probably, but I don't know for sure. I am not a hardware tinkerer.
Please beware that these are just suggestion, not hints or advice how to repair your OUYA console. Anyway, good luck! :-)
OUYA Inc | Android Developer
Skype: tgraupmann_prey
http://github.com/ouya/docs
http://github.com/ouya/ouya-sdk-examples
Check out the latest docs for your game engine: [setup] [adobe air] [android] [clickteam fusion] [construct 2] [corona] [libGDX] [game maker] [html5] [marmalade] [monogame] [unity] [unreal]
Use caution when setting [persistent wireless mode].