[Galaxy Ace S5830i Q&A, Help & Troubleshooting] Jarmezrocks:
Why? I was not actually asking for support as such, just sharing what I learnt/noticed.

Yes I am aware of that. I actually did attempt to flash the CM9 developer package several times all without result.

I tried many methods, firstly the conventional method and then several other unconventional methods. I first flashed CWM recovery 6.0.0.x (something around there) and that was ok but it could not detect the partitions....naturally I was on the standard firmware!

So I then flashed Thunder kernel which allowed recovery to see and mount all the partitions as well as prepare for a CM firmware flash. As I knew that CM required EXT4 I was prepared and flashed Rio's Ext4-RFS conversion script via Aroma in recovery. This worked very well. Only issue was that in doing so it corrupts the system partition and then I am unable to mount it anymore to flash CM.

Returning to stock or even attempting a nandroid restore from this point forward was fruitless as you can imagine. I tried several other combinations before retiring the idea. These included full system wipe after flashing CWM recovery (I figured maybe having data on the partitions its self could be interferring with the EXT conversion scripts? Everything seemed fine and ran correctly as expected only no system mounting.

I tried another method of flashing a ROM that included a kernel with it based on CM7 in the hopes that migrating to CM9 would be easier; this was not the case.

I picked a CM7 ROM that had a conversion script built in for BML to MTD. After returning to stock base via Odin I proceeded to flash recovery 6.0.0.x again, then I immediately flashed CM7 in the hope that I would kill two birds with 1 stone and have CM do its conversion on the fly as well as install (alleviating the need for mounting system after migrating to Ext4). This ROM installed without fault. All was well until I rebooted expecting to boot into CM7....this wasn't the case, I received bootloops like crazy. Naturally I booted into recovery (the ROM had downgraded me to version 5.x CWM recovery - that is fine anyway); I proceeded by clearing the caches and performing a factory reset (note This usually a good thing to do anyway regardless if you came from a clean reset factory firmware or not).

After doing this and rebooting the device reboots continuously as it did prior. I again decided to re-install the same zip as I am aware with changing to CM on many other devices it can sometimes require flashing 2-3 (and sometimes even 4) times for a firmware update to stick. Again still no response and forever bootloops. I decided at this point that if I was to waste the time and effort in Odin'ing back to stock AND THEN flashing my standard firmware that I should try another CM ROM.

I had CM9 available and even though half hour prior I was unable to mount the the system partition, I thought maybe that CM7 had been flashed first so if CM9 can see and mount partitions (like it should have originally) then I could flash CM9 in a hope that it might wipe out what ever was causing all the issues with bootloops.

CM9 installed correctly, however again I could not boot the device at all! I had read a post from a forum member's guide saying that if I got some of these issues that I should flash back to base and try it again. I did this another 3-4,5 times at least, various combinations of wiping base firmware, not wiping base firmware, wiping CM7; not wiping CM7......Always the end result = bootloops.

As you can imagine it was rather annoying if I was returning to base firmware (if I wanted to be stock carrier branded again I needed to flash twice, once to return to stock and again to flash Optus firmware.

Overall I was unable to get any firmware booting besides that which was provided as an Odin package AKA stock firmware. If I flashed a custom recovery over stock firmware I was unable to boot again. Oddly enough I found a standalone version of CWM recovery version 5 that was not CM specific and I performed a backup as it was able to see the stock partitions without throwing errors.

I then opted to do a conversion to EXT4 again and hoped that I could just restore my nandroid backup of the stock partitions like recommended in may of the guides for Galaxy Ace.

Unfortunately again I was unable to boot and the partitions become unmountable leading to yet again flashing back to base unbranded, then flashing stock carrier branded firmware (this has the correct modem for the carrier and region).

At this point I retired the idea of custom firmware. I will later root the device and just leave it on 2.3.7 and do internal/external SDcard swap and flash a theme and maybe a few compatible APKs from newer stock firmwares (at least ICS) to achieve the functionality I was hoping to have by flashing and using ICS. I found the best and most simplest way of achieving this was through Moto-Chopper Root method and adb, most of the documented ways of achieving root on the Ace don't work for the S5830V for some reason. So I will stick with what works.

Thanks for the tip. :good: I have downloaded this ready now, so I will investigate how this goes? It looks very similar to a application I already use TAR.MD5_PACKAGER however I see it has an option for extracting from .tar.md5 files that have malformed header information. So that sounds like it should do the trick!:fingers-crossed: Do you think that this is maybe intensional as a means of stopping people like us from building custom firmware packages?

I mean the .tar.md5 package flashes perfectly as it should do which is very surprising seeming .md5 signature is very easily broken when you rename the file and you have not even opened it. That was what lead me to flashing it in the first place, I mean I figured that if the .tar.md5 was so corrupt as I believed it was, then the worst that can happen will be Odin will spit an error message and not proceed i.e. it won't even attempt to flash the said firmware!

Myself if I download any firmware that doesn't flash and fails due to md5 error, I immediately open it up and inspect it and unless it was extremely difficult to obtain (I have waited close to 30 hours once for an old firmware package to download from the only source I could find - but regardless if it was damaged or not I only wanted the old bootloader so I could integrate it into a new firmware package so the passing md5 was relatively unimportant), I would just re-download it again.

The fact that ALL of these packages for S5830I are like this (regardless of what browser or means I downloaded the package) and the fact that they DO in fact flash like normal packages, and the phone returns to 100% factory condition; tells me that this does look like a means of discouraging custom firmware developers? hmmm :confused:

The device is actually a S5830V...the V devices are relatively undocumented, but they are essentially just the same as the more common i/M variants. I did my homework first with this, and I can most certainly attest that it is NOT the S5830. I wouldn't attempt flashing S5830 firmware, also S5830i firmware boots and functions as normal and has signal albeit not so strong when the modem is not for our carrier and/or region, but function none the less.

Well give the fact that I had performed so many download of firmware that I initially believed to be corrupt I was unable to extract the PIT (or in the case of the generic Ace OPS file) from the firmwares.

Being the fact that there was little known about the S5830V I was unsure if to proceed of not? There are few reports on the device and most of them were of owners bricking their device, only 1 report I know of where a V owner claimed he flashed S5830i firmware without a hitch, again he was not from Australia where I am from, so I was flying blind and scared I was going to brick the device.

At the very least if I had a PIT file I could analyse it and could manually make image backup of the EFS/IMEI partition straight after rooting the phone. I have looked already at scripts that scan the whole emmc and I hit a snag when the kernel I am using is not insecure i.e. adb cannot run as root. I have root and confirmed with root checker app but terminal emulator and/or command line are unable to obtain root :(

Anyway to shed some light for you EFS Pro is a means of doing this that works on most Samsung devices....just not the Ace as far as I can tell.

Yes I am already aware that there is Galaxy Toolbox and I had actually gone ahead and done all that already,but an incident more recently where I had a device I was repairing with a wiped IMEI and it actually refused to boot. This becomes a hassle when restoring the IMEI cause in order to have Galaxy Toolbox you need to be booted and rooted. I wasted a whole day repairing the IMEI. So pretty much the message here is what good is Galaxy Toolbox to me restoring the IMEI if it can't boot? NONE!

I contacted the developer weeks ago and explained my situation and he is still yet to respond. I explained that I had a V variant of the Ace and wanted to ensure I had all bases covered. I requested information on how I could open the IMEI manually outside of the Galaxy Toolbox in the case that it would not boot (as this was how I restored the other device last week and it worked), unfortunately I am still yet to hear a response form him? Slack.

When I obtain this information I will share it here on XDA in the hopes that people in Australia with this variant will search and find some info on it. This is also why I am making this post here so detailed for folks like me who have been searching fruitlessly for answers.

My thoughts are that maybe there is something still not 100% the same between the i and the V because all custom firmwares I tried made for the S5830i never worked?

There is maybe an issue with how they are scripting their installs that is causing issues, but it is worrying enough that flashing so far has lead to partitions becoming corrupted very easily. I have had this before with my own phone more recently because a dev made a simple mistake in an updater script that called an explicit partition by mounting point ID and not by a more generic mounting point like "/system", "system" which lead to lost IMEI and bricked phone.

I am not blaming the dev though because it is easy to assume that a even though the mounting was non-specific for my device and the partition being called was not actually the EFS, it should not have corrupted my EFS....but that is not true, so a discovery was made and a lesson learned from all this. I managed to revive my device and it lived to fight another day, but simple mistakes made in ignorance or lack of information can still be costly mistakes. Need I say more.

I will report back when I have got a proper partition map for the S5830V and all will be happy days :)