Thread: Possible new downgrade method
View Single Post
Old 05-13-2022, 09:50 PM   #15
j.p.s
Grand Sorcerer
j.p.s ought to be getting tired of karma fortunes by now.j.p.s ought to be getting tired of karma fortunes by now.j.p.s ought to be getting tired of karma fortunes by now.j.p.s ought to be getting tired of karma fortunes by now.j.p.s ought to be getting tired of karma fortunes by now.j.p.s ought to be getting tired of karma fortunes by now.j.p.s ought to be getting tired of karma fortunes by now.j.p.s ought to be getting tired of karma fortunes by now.j.p.s ought to be getting tired of karma fortunes by now.j.p.s ought to be getting tired of karma fortunes by now.j.p.s ought to be getting tired of karma fortunes by now.
 
Posts: 5,738
Karma: 103020299
Join Date: Apr 2011
Device: pb360
Quote:
Originally Posted by fonix232 View Post
Okay, I'm excited about this, but for a completely different reason...

I believe by modifying the build values here, one could essentially block firmware updates completely (at least until Amazon catches up with the version number supplied), essentially making sure that your jailbreak doesn't get wiped out because Amazon forced an update even though you turned off auto updates.
Good idea. I hope someone looks into this. It might be a bit more complicated than just putting in a large number.

Quote:
Originally Posted by NiLuJe View Post
Wiping (at least) some of the more database-y stuff from /var/local might be a good idea before attempting a significant (or maybe even a not so significant one) downgrade, because nothing in the process is intended to support database downgrades .

IIRC, back in the olden days, at worst it just broke stuff at runtime, but there is a non-zero chance it could break the boot, which would be bad .
Good point. It would be good to know which dbs can be simply deleted
j.p.s is offline   Reply With Quote