You haven’t heard a lot from me for a long time now, but now I’m coming back with some bad news for some of you: I will migrate my server in mid July and therenfore stop all services I am offering around the FP2 (at fp2.retsifp.de):
I unfortunately cannot continue to support those, because of several reasons:
I don’t own a FP2 anymore (for some years now, it died very dishonourable due to a hardware defect… ), so I cannot test anything of this anymore.
(root) The building of the root-images needs a java virtual machine running on the server, which lead to several quirks I had to work around with some scripting… Sometimes the build didn’t succeed because of low RAM… And it’s also a security issue, because all this java stuff needs a lot of packages I don’t want to run on my server.
(signed recovery) I don’t know anymore how to sign the images This is why I didn’t upload the latest TWRP-Version. I know that I forget things and created a post here in the forum, but it’s not accessible anymore (that is, IMHO, a very bad habit to make old stuff inaccessible in a forum. Why would one do that, I really don’t get it? )
I still see downloads for the images (~2-3 per day, which is way more than I ever expected). This is why I’m informing you, maybe someone from the community wants to take over the hosting.
If you are willing to try to take that over, please contact me. I can provide my scripts and you can try to set that up on your machine.
And maybe someone from the @moderators could look into the dead link I mentioned above, then I could sign the latest TWRP-Version. I could then continue to provide signed TWRP-Images, and update them on request.
Seems archived. I’m no moderator, but content is as follows …
Well, the boot.img-files are simply not signed. That’s everything.
Sign them and they will boot just well, I already did this for testing my new autobuild-service for rooted boot.imgs (You can just boot one of the images from there if you want).
I don’t think it’s worth the effort for FP to sign their images, since they always get flashed during an update. It’s only for testing.
Here is how super-bootimg signs the images. You’ll have to generate the keystore before, use the script from AOSP for this (Here is how to use the script).
Edit: I just realized, that @anon36364121posted the part of the sourcecode from the bootloader, which generates this message. The image will never be checked, the line is commented out (and I think device.is_unlocked is TRUE). I don’t get instantly, why it fails with a non-signed boot.img, still looking into it…
But I double ckecked this now, and it works as I thought before:
First, I tried the original boot-image from the latest 1.8.1-BETA:
fastboot boot orig-boot.img
OKAY [ 0.431s]
FAILED (remote: bootimage: incomplete or not signed)
finished. total time: 0.432s
That’s a pity but I fully understand your reasons and I’m very grateful that you’ve still provided your system for so long (and I can say that I also used your files often in former times)!
I think that was not intentinally made inaccessible but some older topics unfortunately remained archived during a past reorganization of the forum.
I can move it back now if it still helps (although @AnotherElk has already copied the relevant content here).
If someone is found, then even better. But if no one is found, then it might even be helpful to still have the last files (as static content) there, because ultimately there was not a lot of change/update regarding OS version. This would make hosting probably much easier than using the scripts to dynamically update the content…