Database Info

How to flash the G1

WARNING: Following these instructions may brick your phone, void your warranty and kill your dog. You don't want your dog to die do you?
Once I got root access on my G1, I've been messing around with trying to build reflash the recovery partition. That project is still in progress, but I have learned a bit about how to flash the various partitions on the G1.
First things first, you have to have root access. See this thread.
There are 6 mtd devices or partitions on the G1, mtd0-mtd5. They are located at /dev/mtd. You can use the /system/bin/flash_image tool to flash an image to any of these.
The syntax for the flash_image tool is:
Code:
# flash_image
usage: flash_image partition file.img
#
You can see a list of partition names and which device they are associated with by doing a "cat /proc/mtd".
Code:
#cat /proc/mtd
dev: size erasesize name
mtd0: 00040000 00020000 "misc"
mtd1: 00500000 00020000 "recovery"
mtd2: 00280000 00020000 "boot"
mtd3: 04380000 00020000 "system"
mtd4: 04380000 00020000 "cache"
mtd5: 04ac0000 00020000 "userdata"
#
These should all be self explanatory, except maybe "misc", which just appears to have a few string values.. Not really sure what it's used for..
Before you do any erasing or writing, it's a "really good idea" (tm) to make backups of each of these. Even if you don't plan on writing to them. I had accidentally erased the bootloader partition (typed mtd0 instead of mtd1), which I'm fairly sure would have bricked my phone if I had tried to reboot it. Ugh! Luckily, I had created a backup earlier, so I was able to restore it. (And then was nervous as heck when I tried to reboot it... "Please boot up! Please boot up!")
To create the backups:
Code:
# cat /dev/mtd/mtd0 > /sdcard/mtd0.img
# cat /dev/mtd/mtd1 > /sdcard/mtd1.img
# cat /dev/mtd/mtd2 > /sdcard/mtd2.img
# cat /dev/mtd/mtd3 > /sdcard/mtd3.img
# cat /dev/mtd/mtd4 > /sdcard/mtd4.img
# cat /dev/mtd/mtd5 > /sdcard/mtd4.img
#
Now you can use flash_image to write the new image.
Code:
#flash_image recovery /system/recovery.img
#
And that's how it's done.
Update: You normally don't need to erase the flash before you write, as long as you don't corrupt the flash first, by trying to "cat" an image directly to the mtd device, like I did . If you get a lot of ECC errors when you use flash_image then you need to erase it
Code:
# cat /dev/zero > /dev/mtd/mtd1
write: No space left on device
#
On a related note, Based on my experience so far, the recovery partition is not critical to booting the G1. When I first tried this, I used flash_image to write a new image without erasing the partition first, and it corrupted it pretty good. When I tried to boot the G1 into recovery mode (power+home), it would go to the bootloader screen instead. But it would boot into normal mode just fine.
Additionally, I've verified that the device will boot into recovery mode if you screw up the boot partition (mtd2). So as long as you at least have a good recovery image *or* a good boot image, you should be able to get back in business. Just don't try to update both at the same time.
Even so.. be careful, and don't come crying to me when you brick your phone. Or if your dog dies. You don't want your dog to die do you?

Excellent work!
So if misc is the boot loader, it looks like it is roughly 266k. If you can dump it, have you tried to "open" the image and see if you can see files?
Now you have given me more ideas

readonly sdcard?
When I run: cat /dev/mtd/mtd1 > /sdcard/mtd1.img
I got this:
cannot create /sdcard/mtd1.img: read-only file system
I know I am root...

staulkor said:
So if misc is the boot loader, it looks like it is roughly 266k. If you can dump it, have you tried to "open" the image and see if you can see files?
Click to expand...
Click to collapse
Actually, now that I look at it.. I'm not positive that mtd0 is the bootloader. There's not much data there at all. Just a few strings in the beginning, then lots of nothing. Mostly all FFs, with a few blocks of 00s thrown in. It doesn't look like there's any code at all, so it can't be the bootloader.

Nice work. How about the signing? Does the image you flash have to be correctly signed this way?

blues said:
When I run: cat /dev/mtd/mtd1 > /sdcard/mtd1.img
I got this:
cannot create /sdcard/mtd1.img: read-only file system
I know I am root...
Click to expand...
Click to collapse
Do you have the sdcard mounted for USB access? If so, just unplug the usb cable and plug it back in. (don't select "mount" in the usb notification thingy that pops up)

Chainfire said:
Nice work. How about the signing? Does the image you flash have to be correctly signed this way?
Click to expand...
Click to collapse
Nope. This is a raw write directly to the flash device. The whole signing thing is only applicable to the OTA updates (or Update.zip style update).
But the other project I'm working on is to rebuild the recovery mode and disable the signature check for OTA/update.zip updates.

If you check out the SDK and build the open-source version for the phone, it builds a custom recovery-image that accepts only things signed with the testkeys - which is cool. Since the test keys are in the directory, you can easily resign the images yourself.
I know a guy who has done this now. I'll do it when I get a chance.
There are two proprietary files that you have to suck off the device in addition to the ones that the "extract_files" script in the android build pulls off - I sent in a patch to fix this but who knows if they'll apply it or not (I thnk they think that the crap in the msm7k dir will do something)
What I'm wondering is if we can write an update mode that will backup the contents of the /cache and /data to the SDCard - then erase the three partitions - then recreate /data as a huge partition and leave only 10 or 15 megs for /cache - because... well.. /cache is worthless since OTA updates aren't gonna happen to our phones anymore anyway. It would be nice to get an extra 40 megs for app storage.

JesusFreke said:
Actually, now that I look at it.. I'm not positive that mtd0 is the bootloader. There's not much data there at all. Just a few strings in the beginning, then lots of nothing. Mostly all FFs, with a few blocks of 00s thrown in. It doesn't look like there's any code at all, so it can't be the bootloader.
Click to expand...
Click to collapse
I just looked at my dumped mtd0.img and I see a few interesting strings:
T-MOB010
DeviceWarmBoot
CE Serial InUse
Debug Cable Ena
CE USB InUse
ClearAutoImage
And then a mountain of FFs, lol

You are right. I am on XP machine. So I disabled the usb storage, and it works fine
JesusFreke said:
Nope. This is a raw write directly to the flash device. The whole signing thing is only applicable to the OTA updates (or Update.zip style update).
But the other project I'm working on is to rebuild the recovery mode and disable the signature check for OTA/update.zip updates.
Click to expand...
Click to collapse
It works for me now.

RyeBrye said:
If you check out the SDK and build the open-source version for the phone, it builds a custom recovery-image that accepts only things signed with the testkeys - which is cool. Since the test keys are in the directory, you can easily resign the images yourself.
Click to expand...
Click to collapse
Yep, that's exactly what I'm doing. I'm planning on posting a recovery.img for others to use, since trying to build the thing from scratch is a pain, and takes forever.
RyeBrye said:
There are two proprietary files that you have to suck off the device in addition to the ones that the "extract_files" script in the android build pulls off - I sent in a patch to fix this but who knows if they'll apply it or not (I thnk they think that the crap in the msm7k dir will do something)
Click to expand...
Click to collapse
I assume you're talking about libaudio.so and librpc.so?
RyeBrye said:
What I'm wondering is if we can write an update mode that will backup the contents of the /cache and /data to the SDCard - then erase the three partitions - then recreate /data as a huge partition and leave only 10 or 15 megs for /cache - because... well.. /cache is worthless since OTA updates aren't gonna happen to our phones anymore anyway. It would be nice to get an extra 40 megs for app storage.
Click to expand...
Click to collapse
Good idea. Even better would be if we could put the installed apps and all data on the sdcard.. But that would probably be a harder modification than just resizing the partitions.

staulkor said:
I just looked at my dumped mtd0.img and I see a few interesting strings:
T-MOB010
DeviceWarmBoot
CE Serial InUse
Debug Cable Ena
CE USB InUse
ClearAutoImage
And then a mountain of FFs, lol
Click to expand...
Click to collapse
that partition is the config partition, standard HTC stuff.
T-MOB010 is your CID (carrier ID, spl checks this when flashing NBH), but it is only a backup copy of it, the real CID is in radio part of nand (protected!).
and the rest is just config stuff for SPL and radio. (yes HTC uses strings to set these configs - SPL reads the strings from specific nand addresses and decides what to do)

JesusFreke said:
On a related note, Based on my experience so far, the recovery partition is not critical to booting the G1. When I first tried this, I used flash_image to write a new image without erasing the partition first, and it corrupted it pretty good. When I tried to boot the G1 into recovery mode (power+home), it would go to the bootloader screen instead. But it would boot into normal mode just fine.
Click to expand...
Click to collapse
very nice stuff! have you been able to reflash a recovery.img then to fix the corruption?
and you are right about the boot order... it's : radio bootloader -> SPL (that tricolour screen is SPL mode) -> boot.img or recovery.img.
(if boot.img then the OS loads)

cmonex said:
very nice stuff! have you been able to reflash a recovery.img then to fix the corruption?
Click to expand...
Click to collapse
Yep. I screwed up the recovery partition and rebooted, and wasn't able to boot into recovery mode. It just went into SPL mode when I tried. Then I normal booted and re-flashed with the original recovery.img and rebooted, and was able to boot into recovery mode.
Thanks for the info on the boot order. I didn't realize the radio image was used for booting, I figured it was just firmware for the 3G chip or something.
I'm getting close to being able to apply my own update.zip style update. I've been able to reflash the recovery partition with a custom built recovery image that skips the signature verification. I'm having a touch of trouble getting it to actually install an update.zip though. It keeps saying "update script not found", even though there is a "META-INF/com/google/android/update-script" file in the zip. Arg! Anyways.. I'm in the process of tracking the issue down. More to come!

cmonex said:
that partition is the config partition, standard HTC stuff.
T-MOB010 is your CID (carrier ID, spl checks this when flashing NBH), but it is only a backup copy of it, the real CID is in radio part of nand (protected!).
and the rest is just config stuff for SPL and radio. (yes HTC uses strings to set these configs - SPL reads the strings from specific nand addresses and decides what to do)
Click to expand...
Click to collapse
Ah! Excellent info.

I was finally able to get the rebuilt recovery tool to work. The problem with the update.zip was due to the fact that the zip was built in windows, so it had the wrong path separators. It was looking for META-INF/com/google/android/update-script, but the zip file contained META-INF\com\google\android\update-script
After switching the slashes around in a hex editor, it installed the update no problem.
Next, I was tempted to try to flash the boot partition. I was somewhat sure that I would be able to recover from a bad boot flash, with my nifty new recovery tool. But after reading about the guy that bricked his phone (over in the root thread), I was a bit scared.
But I finally went ahead and decided to give it a try. You only live once, right?
So I opened up a root console, and just wiped the boot partition clean. "cat /dev/zero > /dev/mtd/mtd2" and rebooted. Palms sweaty.. breathing hard.. shaking.. Powered the phone on (without holding down home), and it comes up to the recovery tool. So far so good. Then I ran the update on the sdcard - it was a smallish update I had created before hand that just flashed the original boot image back to mtd2. Update runs fine.. phone reboots....
And it boots up normally.
yes!
*takes a big sigh of relief*
So now I can mess around with the boot partition, and know that I have that recovery tool safety net.
And now. It's time to sleep. *head hits the keyboard*

very cinematic good job mate!

Very nice work

Congrats on the successful flash!

strings in mda1.img include:
Code:
ANDROID!
no_console_suspend=1
-- System halted
ran out of input data
Malloc error
Memory error
Out of memory
incomplete literal tree
incomplete distance tree
bad gzip magic numbers
internal error, invalid method
Input is encrypted
Multi part input
Input has invalid flags
invalid compressed format (err=1)
invalid compressed format (err=2)
out of memory
invalid compressed format (other)
crc error
length error
Uncompressing Linux...
done, booting the kernel.
What are these images? Are they filesystem images that you could theoretically mount? If so, what filesystem (I haven't gotten anything to work).

Modded recovery and boot images

Here is a zip file containing a modified recovery and boot image, as well as a few other things:
http://rapidshare.com/files/166164961/AndroidMod.zip
http://jf.nyquil.org/AndroidMod.zip
http://android-dls.com/forum/index.php?f=24&t=191&rb_v=viewtopic (see post for actual link to file)
NOTE: if you need a complete RC30 to v1.3 guide, see this page.
The recovery image (recovery_testkeys.img) uses the test keys that are distributed with the android platform source. This means that an OTA update or an update.zip update must be signed with the test key in order for it to install. In other words, it will no longer install OTA updates from t-mobile. You don't want them stealing back root access from you now do you? .
I've also included the test keys and the SignApk.jar tool, so you can sign your own update scripts (for use only with the modified recovery image). You can resign any image, even if it has been signed before. So for example, if you needed to install an "official" t-mobile update, you must re-sign it with the test keys first.
Another bonus in this recovery image is that ADB is enabled while in recovery mode. You can't adb into a shell (no sh binary), but you can at least use it to push and pull files from the device. For example, you could push an update.zip file to the sdcard.
The boot image (boot_nosecure.img) has been modified so that adb has root access by default. So when you do an adb shell, you automatically get a root shell. You can remount the system image using adb, and then push files directly to the system partition.
Finally, the "update - Restore Original RC29 Boot Image.zip" file is an update.zip file signed with the test keys, which will restore your boot partition back to the stock RC29 image. Useful if you accidentally hose your boot partition..
To install the recovery image onto your phone:
Code:
D:\Android\AndroidMod>adb push recovery_testkeys.img /data/local/recovery.img
912 KB/s (0 bytes in 1767424.001s)
D:\Android\AndroidMod>adb shell
$ su
su
# mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system
mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system
# cd /system
cd /system
# cat /data/local/recovery.img > recovery.img
cat /data/local/recovery.img > recovery.img
# flash_image recovery recovery.img
flash_image recovery recovery.img
#
Note: You must place the recovery image at /system/recovery.img. the init.rc boot script automatically flashes the recovery partition with that file every time you boot up the phone.
At this point, it's probably a good idea to reboot the phone into recovery mode, and make sure it loads OK. If the recovery image is corrupt somehow, it will throw you back into SPL mode (the multi-color bootloader screen). If that happens, just boot the phone normally, and reflash recovery image.
Once it boots into recovery mode, press alt+L, and the next to top line of text should say something like "using test keys.". If it doesn't, then you're still using the original recovery image.
Note: If you are planning on installing the modified RC30 update, you can ignore the following - there is no need to install the boot image. The update already has a newer, modified boot image.
Now that you know you have the modified recovery image loaded, you can install the boot image:
Code:
D:\Android\AndroidMod>adb push boot_nosecure.img /data/local/boot.img
939 KB/s (0 bytes in 1533952.001s)
D:\Android\AndroidMod>adb shell
$ su
su
# flash_image boot /data/local/boot.img
flash_image boot /data/local/boot.img
# rm /data/local/boot.img
rm /data/local/boot.img
#
Now reboot the phone and let it boot normally. If the boot image was corrupted, it will boot into recovery mode instead. You can use the included update zip file to reload the original RC29 boot image.
Otherwise, if it boots up normally, open a command prompt however you like (telnet, adb, terminal emulator app, etc.) and type "getprop ro.secure". If it says 0, then you're running the modified boot image. Otherwise, if it says 1, you're still running the original boot image.

Attachement..
Hmm. It doesn't look like the attachment made it.. Does anyone have some space I could throw the file up at? It's around 5mb.

JesusFreke said:
Hmm. It doesn't look like the attachment made it.. Does anyone have some space I could throw the file up at? It's around 5mb.
Click to expand...
Click to collapse
I should have some space let me know

JesusFreke said:
Hmm. It doesn't look like the attachment made it.. Does anyone have some space I could throw the file up at? It's around 5mb.
Click to expand...
Click to collapse
Sent you an email with u/p if you need space.

test
anyway to test and make sure i did this correctly.. other than my phone booted and is not a paperweight

jriley60 said:
anyway to test and make sure i did this correctly.. other than my phone booted and is not a paperweight
Click to expand...
Click to collapse
To check the boot image, boot the phone normally, and then get a shell with adb. Type "id", and see if you are root
To check the recovery image, boot up the phone into recovery mode. Once you're in recovery mode, Press alt-l to show the text. The next to top line should say something like "using test keys"

JesusFreke said:
To check the boot image, boot the phone normally, and then get a shell with adb. Type "id", and see if you are root
To check the recovery image, boot up the phone into recovery mode. Once you're in recovery mode, Press alt-l to show the text. The next to top line should say something like "using test keys"
Click to expand...
Click to collapse
When will we see the files? Can you just upload to RS and we will mirror?

neoobs said:
When will we see the files? Can you just upload to RS and we will mirror?
Click to expand...
Click to collapse
Look at the original post. I added a link for the zip file..

boot.img is in correct. assuming typing id in telnet returning uid=0(root) gid=0(root) means i'm root then i'm good, thank you so much. looks like i really should install the emulator it might make things a little easier

JesusFreke said:
Look at the original post. I added a link for the zip file..
Click to expand...
Click to collapse
thank you. Sorry

jriley60 said:
boot.img is in correct. assuming typing id in telnet returning uid=0(root) gid=0(root) means i'm root then i'm good, thank you so much. looks like i really should install the emulator it might make things a little easier
Click to expand...
Click to collapse
Well, that does mean you have root, but that doesn't say anything about whether the boot.img was installed correctly. If you're telneting in, then you would have root access regardless of whether you are running a stock boot image or my modified one.
My boot image allows adb to connect to the phone as root. If you don't use adb, there's no reason to install my modified boot image.
Actually, there's an easier way to tell if you're running my boot image. Get to a command prompt (telnet, adb, terminal emulator app, whatever), and type
getprop ro.secure
If it says 0, then you correctly installed my boot image. Otherwise, if it says 1, you're still running the stock image.

Thanks! Was waiting for this.
Now to screw with my phone like crazy

Not that I don't trust you... but...
Ok... I don't trust you implicitly enough to reflash my phone with your stuff
Any chance you can post diffs against the android source tree so I can apply your changes and build it myself?
No offense - I just like to know what's going on...

RyeBrye said:
Ok... I don't trust you implicitly enough to reflash my phone with your stuff
Any chance you can post diffs against the android source tree so I can apply your changes and build it myself?
No offense - I just like to know what's going on...
Click to expand...
Click to collapse
Not at all
The recovery tool is just a stock build (almost) from the android source, using the test keys, which is the default if you don't specify keys of your own. The only change I made was to make it print out "using test keys" when it runs, just to make it easy to tell if it's running. I can give you a diff if you really want.. but it's a simple change though, and doesn't affect the actual functionality.
For the boot image, I replaced the initramfs image in the boot.img included in the official RC29 update, with the initramfs image from a default build of the android source, which has the ro.secure property set to 0.
I first tried the boot.img that was generated by the default android build, but I had issues with getting wifi to work, so I tried merging the initramfs image with the RC29 boot.img, and it seems to work fine.
I suspect you could accomplish the same thing by extracting the initramfs image from the RC29 boot.img, un-gzipping and un-cpioing it, and then modifying the default.prop file to set ro.secure to 0. Then you would have to package it back up and stick it back into the RC29 boot.img.
ro.secure is the property that the adb service looks at to determine if it should use root user, or drop to the shell user. When ro.secure is 0, adb will run as root.
It can be a bit of a pain to get the android source to build though. Make sure you get the dream specific product files (they aren't downloaded by default when you do a "repo sync"). You'll also encounter issues where it can't find libaudio.so or librpc.so. You'll have to copy these from the phone to a couple of output folders in order for the build to proceed.
If you get stuck, feel free to give me a holler and I'll try and help out.
Be warned.. the build takes quite a while.. on the order of an hour or two at least. But then again, I was doing it in a VM.. it may be faster if you do it on a native linux box.

i cant get it to work i know I'm doing something wrong can you(everyone)help me out(i have Vista 64) i get this error
this i what i type​# C:\Android\AndroidMod>adb push recovery_testkeys.img /data/local/recovery.img​
this is the error​C:AndroidAndroidMod: not found​
please and thank you
EDIT: could we do it off the sdcard?
EDIT2: i think i found my own mistake this cant be done in Windows i need to have shell with adb meaning time to whip out VM

JesusFreke said:
For the boot image, I replaced the initramfs image in the boot.img included in the official RC29 update, with the initramfs image from a default build of the android source, which has the ro.secure property set to 0.
I first tried the boot.img that was generated by the default android build, but I had issues with getting wifi to work, so I tried merging the initramfs image with the RC29 boot.img, and it seems to work fine.
Click to expand...
Click to collapse
Can you talk more about this step of the process? How did you do this "merging"? Did you use mkbootimg?
JesusFreke said:
I suspect you could accomplish the same thing by extracting the initramfs image from the RC29 boot.img, un-gzipping and un-cpioing it, and then modifying the default.prop file to set ro.secure to 0. Then you would have to package it back up and stick it back into the RC29 boot.img.
Click to expand...
Click to collapse
And this could be done without going through the whole process of doing an Android build, right? I'm just thinking about how one might build a simple utility to allow editing of the ramdisk.

alansj said:
Can you talk more about this step of the process? How did you do this "merging"? Did you use mkbootimg?
Click to expand...
Click to collapse
I just used the good ol hex-editor. The gzip file starts with a few specific bytes (don't remember them offhand..), so you can search through the image. There are 2 gzip files, the initramfs is the last one. In mine, it starts at offset 0x00154000.
Once you find it, just cut it out and dump the new one in (there is some 00 padding after the gzip file ends.. not sure if you need to keep the padding or not). You also have to update the size of the initramfs, which is at offset 0x00000010.
alansj said:
And this could be done without going through the whole process of doing an Android build, right? I'm just thinking about how one might build a simple utility to allow editing of the ramdisk.
Click to expand...
Click to collapse
Yes.

Anyway to make this using the update.zip sd card method?

JesusFreke, per some requests in #android on freenode I have setup a wiki (not a device wiki like xda's but more like an "information about android/g1 and how to tweak it" wiki) and would like to put this on there. Let me know if you care (unless you would like to add it in your own words), the wiki is http://android-dls.com/wiki and its still very new, but im trying to to get it built up (RyeBrye is doing most of the work).

humble said:
i cant get it to work i know I'm doing something wrong can you(everyone)help me out(i have Vista 64) i get this error
this i what i type​# C:\Android\AndroidMod>adb push recovery_testkeys.img /data/local/recovery.img​
this is the error​C:AndroidAndroidMod: not found​
please and thank you
EDIT: could we do it off the sdcard?
Click to expand...
Click to collapse
First of, you do know that when we refer to "C:\..." we refer to windows via a command prompt (or "cmd") and when you see "# ..." we refer to a shell connection to the Android phone.
Second, you do have the Android SDK right? If not download it HERE. Now extract that to a folder, preferably close to the C: root. (ex. C:\AndroidSDK)
1)Either extract/copy the files from the "AndroidMod.zip" to the Android Tools folder from the SDK (ex. C:\AndroidSDK\Tools) OR copy "adb.exe" and "AdbWinApi.dll" from the Android Tools folder from the SDK (ex. C:\AndroidSDK\Tools)to the folder where you have extracted the "AndroidMod.zip" to.
2)Open up a command prompt. Start -> Run (or Windows key + R) and type "cmd"
3)CD to the directory where the files are.
EXAMPLE:
C:\Users\[your_user_name_here]> cd \
C:> cd androidsdk\tools
C:\AndroidSDK\Tools>
4) Now follow the Instructions.

android's init / working with .img files

hey everyone, this all started when i began to try and get my sd partitioned for apps. i have the stock rogers fw with haykuro's root based off cyangens recovery? anyway, i got the partition to work and all and even copied files over. my only problem is that the ext2 does not mount unless i do it manually from the terminal on device. i have come up with an init.rc file that i believe should work. currently it is in /etc
Code:
on boot
export PATH /data/busybox
mount -rw -t ext2 /dev/block/mntblk0p2 /system/sd
on device-added-/dev/block/mntblk0p2
mount -rw -t ext2 /dev/block/mntblk0p2 /system/sd
any ideas?

Tried lucids script to do everything?
http://forum.xda-developers.com/showthread.php?t=480582 I mean I know that rom you have has a adds2sd thing in it, but I can only speak with what I use and know. =)

i'll check it out, but my rom is stock. there is no apps2sd in it. i just partitioned and was going to set up some links when i realized the partition wasn't mounting on it's own. thanks for the link though

The init.rc isn't a shell script, and doesn't run normal commands - its built-in mount command has a different syntax from normal mount. Check out the source or other init.rc files for the syntax.

gwydionwaters said:
i'll check it out, but my rom is stock. there is no apps2sd in it. i just partitioned and was going to set up some links when i realized the partition wasn't mounting on it's own. thanks for the link though
Click to expand...
Click to collapse
Check your PM

i figured it out a little, i have noticed that the init i create is being overwritten when i reboot. i would assume perhaps i need to add the modified file into the system.img and then flash that version on? does that sound right to anyone?

The init is flashed during boot. Its in the boot.img. you can check the stickys to see how to crack one open and put it back together. Ill fix it for you this weekend as promised. Ill even show you what I did but I gotta get time at my computer. Patience my internet friend, patience.
Edit
Also check the "all you need to know" post by haykuro. Its the most recent thread started by him in this forum I believe

If you are using a stock rom did you get the modified mount.conf that supports partition mounts?

lol no i didn't know there was one. i did modify my mount.conf on my own and added the entry for the ext.
i'm having some serious trouble unpacking my boot image, and yes i have read all there is to read and then some. i originally tried unyaffs on the image i got from my nandroid back up i made before root, but it was claiming a broken image. so i made a current back up and tried that boot, the same problem. i figured maybe the nandroid backup utility was creating bad images so i went another route. i started on device and created an image of my boot mount
Code:
cat /dev/mtd/mtd2 > /sdcard/boot.img
i stripped off the header and kernel, saved the remainder as a raw file. then
Code:
gunzip -c boot | cpio -i
and it sort of works, maybe with errors and then asks for the name of archive 2 ..
cpio: Cannot identify format. Searching...
cpio: Cpio file name length 46200 is out of range
cpio: Invalid header, starting valid header search.
cpio: Cpio file name length 6960 is out of range
cpio: Cpio file name length 40367 is out of range
cpio: Cpio file name length 21330 is out of range
gunzip: /device/here/boot: decompression OK, trailing garbage ignored
cpio: End of archive volume 1 reached
ATTENTION! cpio archive volume change required.
Ready for archive volume: 2
Input archive name or "." to quit cpio.
Archive name >
Click to expand...
Click to collapse
and if i enter anything it can't find/read the file (the one i named of course) and if i quit there is nothing gained, no files or anything

[HOW-TO]Create Custom ODIN Images for Backup/Restore

I'm sure several people will be wanting this information, so I figured I would post it here for everyone. This will allow you to backup your system and create custom Odin images for restore purposes. For anyone unfamiliar with the Samsung system, they use Odin to flash things to the device, much like HTC has RUU and Moto has SBF. Odin files are either .tar files, or .tar.md5 files.
The .tar.md5 files are .tar files with the md5 checksum added to the end of the file. If you attempt to flash a .tar.md5 file, Odin will automatically check that the contents are what they should be before flashing and proceed with the flash if the md5 is valid, otherwise it will stop.
In Odin, you should use the PDA button for all flashing. The PIT button may be used as well, if we can get a valid .pit file for the device, but for now, PIT won't be used either. Other than PDA, Start/Reset are the only other buttons you need to worry about.
Now, on to creating the backup files. First, you will need your device to be rooted (perm or temp root will work), and you also need to have access to terminal on the phone, either via an emulator or adb shell access. To create the backup files, you won't need a Linux/UNIX system, but you will if you want to create a flashable Odin package. The following will output the files on the root of the SDCard, adjust the "of=" path if you want them somewhere else. It will also create the files for the proper filename for Odin as well. So to create the files, here are the commands you will use from root shell (#):
System:
Code:
dd if=/dev/block/stl10 of=/sdcard/factoryfs.rfs bs=4096
Kernel:
Code:
dd if=/dev/block/bml8 of=/sdcard/zImage bs=4096
Recovery:
Code:
dd if=/dev/block/bml9 of=/sdcard/recovery.bin bs=4096
DO NOT INCLUDE THE FOLLOWING IN ANYTHING BUT A PERSONAL BACKUP
Cache:
Code:
dd if=/dev/block/mmcblk0p3 of=/sdcard/cache.rfs bs=4096
DBData:
Code:
dd if=/dev/block/stl11 of=/sdcard/dbdata.rfs bs=4096
Data:
Code:
dd if=/dev/block/mmcblk0p1 of=/sdcard/movinand.bin bs=4096
The last three files (cache, dbdata, data) may contain personal information, so do not include these 3 files in anything but a personal backup/recovery package.
To create a flashable Odin package, you need to pull all of the files off of the phone/sdcard and onto your computer. From there, you use the following to create the package:
Code:
tar -H ustar -c factoryfs.rfs recovery.bin zImage > package_name.tar
md5sum -t package_name.tar >> package_name.tar
mv package_name.tar package_name.tar.md5
If you want to include cache/dbdata/data in the above for personal use, just add them after the "-c" and before the ">".
There are other files that may be in Odin packages, but they are protected by Samsung and cannot be dumped properly. The files are the bootloader, secondary bootloader, modems, and .lfs partitions. The files would be boot.bin, Sbl.bin, modem.bin (not sure what it would be for the CDMA/LTE dual modem here), and param.lfs. It however isn't that big of an issue that these can't be dumped as the can't really be altered by normal flashing of the device, and are usually only altered via OTA updates.

Thanks for this info imnuts! I unfortunately updated to the new update and would like to go back to rooted but cant until I downgrade.

Thanks!
Thanks for posting this. I'm going to attempt to make a personal backup and then I can factory reset the phone and make a stock version for people to use. I'm haven't installed the update yet either, so I'm hoping this will let people get back to ED1. I've also been playing around with theming using the fascinate community rom theme and ninjamorph to swap files. It'll take a while, but it's currently the only way I feel safe messing with framework-res.

wynalazca said:
Thanks for posting this. I'm going to attempt to make a personal backup and then I can factory reset the phone and make a stock version for people to use. I'm haven't installed the update yet either, so I'm hoping this will let people get back to ED1. I've also been playing around with theming using the fascinate community rom theme and ninjamorph to swap files. It'll take a while, but it's currently the only way I feel safe messing with framework-res.
Click to expand...
Click to collapse
I'm definitely looking forward to having a downgrade ROM image to get back to ED1!

So how do you add the last personal 3 i just got the droid charge and i am not very familiar with samsung files i had a droid x and a thunderbolt very shortly and am familiar with ruu and sbf but how do you add cache dbdata and the other one. I meab like the actual command not the instruction to put it after c

rami98 said:
So how do you add the last personal 3 i just got the droid charge and i am not very familiar with samsung files i had a droid x and a thunderbolt very shortly and am familiar with ruu and sbf but how do you add cache dbdata and the other one. I meab like the actual command not the instruction to put it after c
Click to expand...
Click to collapse
The only thing that would change would be the tar command. If you want to include the other files, it would be:
Code:
tar -H ustar -c cache.rfs dbdata.rfs factoryfs.rfs movinand.bin recovery.bin zImage > package_name.tar
md5sum -t package_name.tar >> package_name.tar
mv package_name.tar package_name.tar.md5
You just need to pull the files from your phone and have them in the same directory that you're in in terminal, and have them named appropriately. It also doesn't matter what order they are in (that I know of), I just have them in alphabetical order for ease of reading.

So im going to try and do the voodoo lagfix for the first time ever but I wanted to make a backup. Im on ED2 and NOT rooted so how would I go about making these backups?

imnuts said:
The only thing that would change would be the tar command. If you want to include the other files, it would be:
Code:
tar -H ustar -c cache.rfs dbdata.rfs factoryfs.rfs movinand.bin recovery.bin zImage > package_name.tar
md5sum -t package_name.tar >> package_name.tar
mv package_name.tar package_name.tar.md5
You just need to pull the files from your phone and have them in the same directory that you're in in terminal, and have them named appropriately. It also doesn't matter what order they are in (that I know of), I just have them in alphabetical order for ease of reading.
Click to expand...
Click to collapse
I tried the above and I keep getting this error message in the command prompt:
'tar' is not recognized as an internal or external command, operable program or batch file.
(I'm trying this on windows 7 professional)
Any help would be appreciated, thanks!

mypantsaretorn said:
I tried the above and I keep getting this error message in the command prompt:
'tar' is not recognized as an internal or external command, operable program or batch file.
(I'm trying this on windows 7 professional)
Any help would be appreciated, thanks!
Click to expand...
Click to collapse
You wouldn't by any chance be trying the "tar" command at a windows command prompt, would you?
imnuts said:
To create the backup files, you won't need a Linux/UNIX system, but you will if you want to create a flashable Odin package.
To create a flashable Odin package, you need to pull all of the files off of the phone/sdcard and onto your computer. From there, you use the following to create the package:
Code:
tar -H ustar -c factoryfs.rfs recovery.bin zImage > package_name.tar
md5sum -t package_name.tar >> package_name.tar
mv package_name.tar package_name.tar.md5
If you want to include cache/dbdata/data in the above for personal use, just add them after the "-c" and before the ">".
Click to expand...
Click to collapse
Course you might be running Linux in a vmware or Hyper-V environment....hint?
HTH

Damn! I didn't pay attention to the second part of that sentence! Lol
Thanks for the "hint"..
Sent from my SCH-I510 using XDA App

The other option would be using Cygwin, but I've never tried it, so it may or may not work.

imnuts said:
The other option would be using Cygwin, but I've never tried it, so it may or may not work.
Click to expand...
Click to collapse
cygwin works!
Edit: Here is how:
1. Search google for cygwin - download
2. Run - you will be prompted to get packages - I assumed "archive" was a good place to start - not sure if you need this or not...
3. When complete you will see a new icon on your desktop - double-click
4. Be patient as it loads
5. Copy the files output'ed from first post to same folder on PC
6. Back in cygwin:
a. cd x: (where x: is the drive letter of the drive that has the folder with the files)
b. tar -H ustar -c cache.rfs dbdata.rfs movinand.bin factoryfs.rfs recovery.bin zImage > package_name.tar
c: md5sum -t package_name.tar >> package_name.tar
d: mv package_name.tar package_name.tar.md5
Complete output of commands:
These files are for the users to personalise their cygwin experience.
They will never be overwritten nor automatically updated.
`./.bashrc' -> `/home/UWINKET//.bashrc'
`./.bash_profile' -> `/home/UWINKET//.bash_profile'
`./.inputrc' -> `/home/UWINKET//.inputrc'
`./.profile' -> `/home/UWINKET//.profile'
Your group is currently "mkgroup". This indicates that neither
your gid nor your pgsid (primary group associated with your SID)
is in /etc/group.
The /etc/group (and possibly /etc/passwd) files should be rebuilt.
See the man pages for mkpasswd and mkgroup then, for example, run
mkpasswd -l [-d] > /etc/passwd
mkgroup -l [-d] > /etc/group
Note that the -d switch is necessary for domain users.
[email protected] ~
$ cd h:
System Volume Information
[email protected] /cygdrive/h
$ cd downloads
[email protected] /cygdrive/h/downloads
$ cd charge
[email protected] /cygdrive/h/downloads/charge
$ cd tarbackup/
[email protected] /cygdrive/h/downloads/charge/tarbackup
$ tar -H ustar -c cache.rfs dbdata.rfs movinand.bin factoryfs.rfs recovery.bin
zImage > package_name.tar
[email protected] /cygdrive/h/downloads/charge/tarbackup
$ md5sum -t package_name.tar >> package_name.tar
[email protected] /cygdrive/h/downloads/charge/tarbackup
$ mv package_name.tar package_name.tar.md5
[email protected] /cygdrive/h/downloads/charge/tarbackup
$

Hmm flash did not work with my personal data in it - got an error. Created a new .tar file with just factoryfs.rfs recovery.bin and zImage and was able to flash that. TG for TiBu!

jism31 said:
Thanks for this info imnuts! I unfortunately updated to the new update and would like to go back to rooted but cant until I downgrade.
Click to expand...
Click to collapse
How do you start doing this. How do I get to root shell (#)... Thanks
AD

I plan to get rooted on ED1 so I can get a stock image backed up, and have a clean base to work from. Still getting my head around the odin stuff first.

RaptorMD said:
I plan to get rooted on ED1 so I can get a stock image backed up, and have a clean base to work from. Still getting my head around the odin stuff first.
Click to expand...
Click to collapse
you dont have to do that its already done
http://forum.xda-developers.com/showthread.php?t=1085190

Well, I successfully followed all the instructions and have created my first ODIN flashable file, I have not tried to flash it yet. I'm just curious, I pull all the different .rfs, .bin, and zImage on this file and noticed it's about 1.8gb file. Is this normal?
Also, before I try to flash this. Should I have dissable voodoo lagfix and converted back to rfs before I dumped the files?
Thanks for all the help!

JKChad said:
Well, I successfully followed all the instructions and have created my first ODIN flashable file, I have not tried to flash it yet. I'm just curious, I pull all the different .rfs, .bin, and zImage on this file and noticed it's about 1.8gb file. Is this normal?
Also, before I try to flash this. Should I have dissable voodoo lagfix and converted back to rfs before I dumped the files?
Thanks for all the help!
Click to expand...
Click to collapse
Yes, that's normal for it to be so large as dd will dump the partition, including empty space. If you were to compress it with zip or lzma, it'd drop down considerably.
Not sure about the voodoo part as I've never dumped files from an ext4 partition. I don't see any reason why it wouldn't work, but I'd flash with caution and have another working image ready just in case.

imnuts said:
Not sure about the voodoo part as I've never dumped files from an ext4 partition. I don't see any reason why it wouldn't work, but I'd flash with caution and have another working image ready just in case.
Click to expand...
Click to collapse
Shouldn't be an issue as long as he keeps the voodoo kernel.
Sent from my SCH-I510 using Tapatalk

Anybody try this with voodoo yet ?

Extract files from stock firmware images

Hi,
when I still hadn't the device, I wanted to know exactly what's included in stock ROMs to have a better idea of what to expect. I hence downloaded a stock firmare and the stock system.img (see below for the steps).
Ok, so what? Well, when KK was released I decided to do the same (I was still waiting for the device), but I couldn't. Unlike before, I didn't find a single system.img, but multiple files (3 to be exact, maybe it's too big to be flashed at once with fastboot, I don't know, I'm new to this) and couldn't understand how the original image was splitted to generate those files.
Did anyone see something similar already and sucesfully merged splitted filesystems?
I know I could simply ask for a system dump (or wait for KK), but now I'm curious to know on how to do this. I tried few things but I couldn't find any way to do it. Maybe I could see how fastboot treat these files, but I wonder if anyone already knows the answer.
Anyway, here the steps to mount the system.img of our stock JB firmwares. Maybe there's an easier way, I honestly don't know. As far as I know, converting the sparge image should be enough, but I had to do more:
Code:
#Convert sparse image with simg2img
simg2img system.img system.img.raw.tmp
#UTF8 may slow down grep, switch to C
export LANG=C
#Look for the ext4 magic and calculate its position
magic=`grep -aobP -m1 '\x53\xEF' system.img.raw.tmp | head -1 | cut -d":" -f1`
offset=$(($magic-1080))
#Remove extra header with dd
dd if=system.img.raw.tmp of=system.img.raw ibs=$offset skip=1
#Remove temp file
rm system.img.raw.tmp
Now you can mount system.img.raw as a normal ext4 filesystem.

Just concatenate the three chunks together like so:
Code:
cat system.img_sparsechunk1 system.img_sparsechunk2 system.img_sparsechunk3 > system.img
Then apply the steps from the OP and voilà!
Edit: Scratch that: the image is accessible, some files are visible but others are missing. To be continued...

Darkshado said:
Just concatenate the three chunks together like so:
Code:
cat system.img_sparsechunk1 system.img_sparsechunk2 system.img_sparsechunk3 > system.img
Then apply the steps from the OP and voilà!
Edit: Scratch that: the image is accessible, some files are visible but others are missing. To be continued...
Click to expand...
Click to collapse
As you have found that doesn't work, remember that each file will have metadata headers so that may be one reason you can't just cat them together.
To OP - can't you just mount each img as a filesystem and copy all the files from each mounted filesystem to another entirely separate directory. At least that way you have all the files in one place, eg copy
/sparsechunk1/system/file1 to /newdir/system/file1
And so on.

scott_doyland said:
As you have found that doesn't work, remember that each file will have metadata headers so that may be one reason you can't just cat them together.
To OP - can't you just mount each img as a filesystem and copy all the files from each mounted filesystem to another entirely separate directory. At least that way you have all the files in one place, eg copy
/sparsechunk1/system/file1 to /newdir/system/file1
And so on.
Click to expand...
Click to collapse
Only the first chunk can be mounted, the other two are not recognized as filesystem and there's no way to mount them.
It's not as if /system was divided in three parts and then an image for each one was created, so that you can treat them as separate files (what you said would work in this case).
One image is created and then it's splitted in three in some unknown way. The first image is the one that holds the informations to access the files, the other two just pieces of files that can't be accessed without the informations in the first chunk.
mfastboot knows how to correctly copy the data from the separate images with the right offsets inside the phone so that in the end all the files can be accessed. Concatenating the files using dd using the correct offsets could maybe work, but after a few attempts I gave up.

There is method to extract files under Windows

Al936 said:
There is method to extract files under Windows
Click to expand...
Click to collapse
Any change you happen to be willing to share the contents of or principles behind `sparse2img.exe`?

HolySid said:
Any change you happen to be willing to share the contents of or principles behind `sparse2img.exe`?
Click to expand...
Click to collapse
What kind of principles you expect from me? I just posted the link to one of the method to extract all files and folders from stock firmware's system partition. The tools were not developed by me - I just informed XDA community about it. As you can see from the tread several persons already confirmed that it works.

Al936 said:
What kind of principles you expect from me? I just posted the link to one of the method to extract all files and folders from stock firmware's system partition. The tools were not developed by me - I just informed XDA community about it. As you can see from the tread several persons already confirmed that it works.
Click to expand...
Click to collapse
Oh, I'm sorry, I thought it was your work. I just want to know how to merge the system files. I know the exe is working, but I'm running Linux, so my question it is both out of curiosity and simply because I cannot run the code.

Try running it with wine or in virtual machine.
sent via tapatalk

Thanks, I managed it by using another laptop. But still, I'd rather know what happened
Sent from my XT1032 using xda app-developers app

Darkshado said:
Just concatenate the three chunks together like so:
Code:
cat system.img_sparsechunk1 system.img_sparsechunk2 system.img_sparsechunk3 > system.img
Then apply the steps from the OP and voilà!
Edit: Scratch that: the image is accessible, some files are visible but others are missing. To be continued...
Click to expand...
Click to collapse
I just replaced the first line in the OP's instructions with this to join the system.img_sparsechunk files:
Code:
simg2img system.img_sparsechunk.* system.img.raw.tmp
And then the rest worked fine. Here were the exact steps I took (I shortened it a tiny bit, but it's the same concept):
Code:
simg2img system.img_sparsechunk.* system.img.raw.tmp
offset=`LANG=C grep -aobP -m1 '\x53\xEF' system.img.raw.tmp | head -1 | awk '{print $1 - 1080}'`
dd if=system.img.raw.tmp of=system.img.raw ibs=$offset skip=1
sudo mkdir /mnt/system
sudo mount system.img.raw /mnt/system

SenorChang said:
I just replaced the first line in the OP's instructions with this to join the system.img_sparsechunk files:
Code:
simg2img system.img_sparsechunk.* system.img.raw.tmp
And then the rest worked fine. Here were the exact steps I took (I shortened it a tiny bit, but it's the same concept):
Code:
simg2img system.img_sparsechunk.* system.img.raw.tmp
offset=`LANG=C grep -aobP -m1 '\x53\xEF' system.img.raw.tmp | head -1 | awk '{print $1 - 1080}'`
dd if=system.img.raw.tmp of=system.img.raw ibs=$offset skip=1
sudo mkdir /mnt/system
sudo mount system.img.raw /mnt/system
Click to expand...
Click to collapse
It worked. Thank you!