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).

[Q] Flashing stock via fastboot error message

Hi, I want to (re-)flash the stock 4.1.2 rom on my Photon Q, because I recently run into some problems of the phone sending messages to the number 8737 even after I had removed the stock sms app.
This should be the right rsd file:
Code:
asanti_c_sprint-user-4.1.2-9.8.2Q-122_XT897_FFW-5-6-release-keys-cid9.xml.zip (MD5: 88f43a03d313bbcc262db78f15ac957c)
I'm on linux and I don't have any Windows system I could install and run RSDLite on. So I decided to take the fastboot way: I unzipped the above file and tried flashing the rom manually. But I always run in to the following error output:
Code:
# fastboot flash cdrom cdrom
(bootloader) Variable not supported!
target reported max download size of 31457280 bytes
Invalid sparse file format at header magi
error: write_sparse_skip_chunk: don't care size 22923264 is not a multiple of the block size 4096
fastboot: ../libsparse/sparse.c:143: write_all_blocks: Assertion `pad >= 0' failed.
Note that "fastboot devices" lists the Photon Q as "T069503UAP fastboot". The same or a similar error messages applies to "fastboot flash system system.img" etc. I use fastboot from the Fedora 20 "android-tools" package (version 20130123git98d0789-2).
Any ideas what's the problem here? Solution?
Thanks in advance!

It's dangerous to try and fastboot the items yourself. Would be better to borrow a Windows PC or something to use RSD (virtual machines are also NOT recommended for this).
But perhaps you should just try to fastboot the other partitions. Not sure 'cdrom' is needed. Either way, I strongly, STRONGLY advise against doing what you are doing.

Okay, thanks for your advice!
The same or similar error messages appear when flashing the other partitions (as already mentioned in the first post). Unfortunately, it's really hard to find somebody with a Windows system, at the moment. I thought RSDLite uses fastboot internally anyway.

I'm not sure if the FXZ images can be flashed as they are, via fastboot.
I believe they should be converted to the standard ext4 format via the simg2img.py pytoon script, before being usable.
I repeat I'm not sure, but I believe that hardly motorola's own format is handled correctly by the fastboot command.
Whatever, for your convenience, I attach the mentioned converter script.
Aside fastboot, can be used for a variety of other purposes, the ext4 images can be mounted straight in Linux via loopback device or extracted in windows with a bunch of tools, personally I use Ftk Imager.

Thanks, that tool is great! After conversion, I was indeed able to mount the system partition as follows:
Code:
# mount -o ro,loop system_converted.img /some/mnt/path
But it doesn't help with the other files (cdrom, boot.img, recovery.img), because they seem to have a different format. However, the system partition was all I wanted. Now, instead of reflashing, I'm going to compare the system partition's files (especially in the "app" folder) and see what might have caused my problem.

tuxor1337 said:
But it doesn't help with the other files (cdrom, boot.img, recovery.img),
Click to expand...
Click to collapse
The boot, recovery and similar partitions aren't written on top of a filesystem like /system or /data.
they are written as they are on top of the physical media.
you can safely flash them in any way: fastboot, restore by recovery and so on.
unlike the filesystem based partitions, they are always in the same format.
If you need to edit the boot or recovery content you need a special script to unpack and repack them, many android kitchens have it

I was just wondering whether flashing on Linux will work when using "moto fastboot" like this one: http://forum.xda-developers.com/showthread.php?t=1138092
I don't really need this functionality anymore. But out of curiosity: What do you think?

My photon has a broken USB connector, so I can't test it in first person.
Btw, I believe that testing is the only way to understand what is flashable and what not, obviously taking handy a good full nandroid backup.

[Q] New info (in OP bold txt), can you answer? - Power on/Reboot goes into APX mode

Sorry, other post is a bit hard to read, was trying to see if upgrading my TF300t (unlocked, rooted, nvflash run) to v9.4.3.30 would fix it - which unfortunately didn't.
I'm having issues resolving powering up and reboots automatically going into APX mode. Plus lost my icons (fastboot, wipe, ? ) when powering up w/vol down
button. Only have choice of Recovery or let it cold-boot into ICS. The original help post for added details is at:
Original post with more details
I'm thinking the AndroidRoot booloader I've been running from when I originally created my nvflash backups got corrupted. The update (via Install Zip in TWRP) does
not seem to have updated the bootloader. In reading even more posts, another user shows:
The Device is UnLocked
Android cardhu-user bootloader <2.10 e> released by "US_epad-9.4.3.30-20120604" A03
Checking for android ota recovery
I see the exact same except my version is "WW_epad-9.4.3.30-20120604", which makes me think the bootloader isn't getting updated correctly & is still the original AndroidRoot
version which became corrupted? I also double checked the new EBT blob I'm flashing via a hex editor and it shows it has a US SKU! So does that mean nvflash isn't truly
flashing it? If not, how can I get it to take either with nvflash, ADB, or TWRP?
Also can see (lack of) progress below *sigh*

wha2do said:
Sorry, other post is a bit hard to read, was trying to see if upgrading to v9.4.3.30 would fix it - which unfortunately it didn't.
I'm having issues resolving powering up and reboots automatically going into APX mode. Plus lost my icons (fastboot, wipe, ? ) when powering up w/vol down
button. Only have choice of Recovery or let it cold-boot into ICS. The original help post is at:
Original post with more details
See (lack of) progress below.
Click to expand...
Click to collapse
Well, still need some suggestions/help. I've run:
nvflash -r --download 4 blob.EBT
nvflash -r --download 10 blob.APP
nvflash -r --download 6 blob.LNX
nvflash -r --download 5 twrp2.5.0.0.img
Didn't do anything to fix the APX issue nor get my fastboot icon back. I'm wondering if I should try using
the bricksafe.img file I'd created before - not sure what exactly it contains and if it would be any different.
At this point I'm days away from seeing if I can return the tablet (under a 2 year warranty plan - thought it
was said if they can't fix, get my money back rather than a replacement) and look at something else.
I've read and read and not found anything useful yet and not much on the nvflash backup file use for restoring...
Help!

You could try erasing the misc partition.
I think this this is the right command, but you might have to check the exact command syntax (don't have nvflash handy right now):
nvflash -r --format_partition 3
Sent from my TF300T using Tapatalk

f69m said:
You could try erasing the misc partition.
I think this this is the right command, but you might have to check the exact command syntax (don't have nvflash handy right now):
nvflash -r --format_partition 3
Sent from my TF300T using Tapatalk
Click to expand...
Click to collapse
Thx & that's the correct syntax, but what is nvflash's partition 3 (misc)? And is this nvflash PartitionId 3 or adb's mount point /dev/block/mmcblk0p3? In
nvflash's partition table list, MSC (assuming this is the same "misc" partition) is listed as PartitionId 12...
When I do a list of partition tables from nvflash, it shows this as type Partition_table and named PT. I did install the Partition Table app
and see where 3 may be coming from, as in the mount point /mmcblk0p3, labelled as MSC?
Looking at other known nvflash/Partition table comparisons, one nvflashes blob.APP (system) to partition 10 yet the Partition Table app
shows /system, labelled as APP mounted on /mmcblk0p1. And with blob.SOS, nvflash sends it to 5 yet the adb command uses /mmcblk0p4...
I maybe interpreting these all wrong and it's ok - just being very cautious about formatting a partition and what effect it will have... Thanks in advance for clarification!

wha2do said:
Thx & that's the correct syntax, but what is nvflash's partition 3 (misc)? And is this nvflash partition 3 or adb's mount point /dev/block/mmcblk0p3?
When I do a list of partition tables from nvflash, it shows this as type Partition_table and named PT. I did install the Partition Table app
and see where 3 may be coming from, as in the mount point /mmcblk0p3, labelled as MSC?
Looking at other known nvflash/Partition table comparisons, one nvflashes blob.APP (system) to partition 10 yet the Partition Table app
shows /system, labelled as APP mounted on /mmcblk0p1. And with blob.SOS, nvflash sends it to 5 yet the adb command uses /mmcblk0p4...
I maybe interpreting these all wrong and it's ok - just being very cautious about formatting a partition and what effect it will have... Thanks in advance for clarification!
Click to expand...
Click to collapse
Sorry, my bad, haven't really used nvflash much. Just assumed it would be the same numbers. :/
Yes, I mean the MSC or misc partition /dev/block/mmcblk0p3.
It holds commands for the bootloader, for eaxample "recovery", etc. Cleaning it might make your bootloader behave. Might.
Sent from my TF300T using Tapatalk

f69m said:
Sorry, my bad, haven't really used nvflash much. Just assumed it would be the same numbers. :/
Yes, I mean the MSC or misc partition /dev/block/mmcblk0p3.
It holds commands for the bootloader, for eaxample "recovery", etc. Cleaning it might make your bootloader behave. Might.
Sent from my TF300T using Tapatalk
Click to expand...
Click to collapse
No problem at all, I appreciate the help and I just always try to be cautious! Just to be doubly sure, here's the excerpt from
getting the partition table info from nvflash earlier today:
PartitionId=12
Name=MSC
DeviceId=18
StartSector=317568
NumSectors=512
BytesPerSector=4096
So doing the nvflash -r --format_partition 12 command should be safe. Wondering, does it make sense to do this first:
nvflash --resume --rawdeviceread 317568 512 msc.img
Should back up what's there if need it afterwards...again being safe, lol!

wha2do said:
No problem at all, I appreciate the help and I just always try to be cautious! Just to be doubly sure, here's the excerpt from
getting the partition table info from nvflash earlier today:
PartitionId=12
Name=MSC
DeviceId=18
StartSector=317568
NumSectors=512
BytesPerSector=4096
So doing the nvflash -r --format_partition 12 command should be safe. Wondering, does it make sense to do this first:
nvflash --resume --rawdeviceread 317568 512 msc.img
Should back up what's there if need it afterwards...again being safe, lol!
Click to expand...
Click to collapse
Yes, this looks like the right one. Unfortunately /proc/partitions does not give a start sector, but the name MSC matches. /proc/partitions gives the size at 2048, but that should be 1K blocks, so maching the 512 4K-blocks shown by nvflash.
Yeah, should be save to erase, but being careful and having a backup never hurts. Might even be interesting to have a glance at the contents.
Sent from my TF300T using Tapatalk

Well, I think if indeed the bootloader is corrupted I've found my flashes of a new one aren't taking. I tried nvflashing blob.EBT, blob.SOS, blob.LNX, and then blob.APP from the stock v9.4.3.30
update (all in same nvflash session) and all listed as successful. The rest did take...but wasn't sure about blob.EBT. I expected to see the US_epad version (and I've checked the blobs
with a hex editor and they indeed have the US SKU).
I ended up sideloading v9.4.3.17 in TWRP and saw the bootloader version stayed the same (WW_epad-v9.4.3.30). With a stock recovery back in place, I tried to see if I could take an OTA
back to v9.4.3.30, but said no updates were available. Ended up sideloading v9.4.3.30 and am back to where I was...
I also let the tablet battery run down completely, charged fully over night hoping something might "reset", but no go...
Last thing I'll be trying later is a factory reset via TWRP (read try doing it three times to be sure) and reload v9.4.3.30. If not, looks like I have two options: 1) try the reformat of the MSC partition
and/or do an nvflash rawdevicewrite of the bricksafe.img file. Just worried with both that it'll create more issues (being very careful since at least I can still get into APX, ADB, and ultimately boot up).
Any recommendations/suggestions on how to get blob.EBT to flash successfully or which step to try next? Please, please, please...lol!

I tried doing a factory reset. Probably overkill, but also wiped cache, Dalvik, and data while in TWRP. Then booted up, skipped set up, and did this two more times. Didn't have any effect,
so I tried sideloading v9.4.3.30 and same old story...
I finally quit and restored my nandroid made prior to the factory resets and now have to decide:
Try the format of the MSC partition or nvflash bricksafe.img. Again just being very cautious since while tedious, I can still use my tablet by restarting via nvflash.
Wish I could get advice from one of the AndroidRoot members!!
Any ideas/recommendations at this point?

bootloader

Hey guys i have an n8010. When samsung released the leak fw for the 8000 I installed it. It worked pretty well. A few months ago an official update came for the 8010 but im using the 8000 bootloader i cannot install it Is that any solution for recovering the old bootloader? I've tried a lot of thing to solve it but none of them was successful. I've tried this method: http://forum.xda-developers.com/galaxy-note-10-1/help/recovering-n8010-leaked-locked-n8000-t2802516 and a lot of custom roms but i always have a same crash after using it for about 2 days. It says System UIDs Inconsistent, UIDs on the system are inconsistent you need to wipe your data partition or your device will be unstable. And if i press "I'm felling lucky" every app crashes touchwiz ,android everything.
Please help me to solve my problem

kataik95 said:
Hey guys i have an n8010. When samsung released the leak fw for the 8000 I installed it. It worked pretty well. A few months ago an official update came for the 8010 but im using the 8000 bootloader i cannot install it Is that any solution for recovering the old bootloader? I've tried a lot of thing to solve it but none of them was successful. I've tried this method: http://forum.xda-developers.com/galaxy-note-10-1/help/recovering-n8010-leaked-locked-n8000-t2802516 and a lot of custom roms but i always have a same crash after using it for about 2 days. It says System UIDs Inconsistent, UIDs on the system are inconsistent you need to wipe your data partition or your device will be unstable. And if i press "I'm felling lucky" every app crashes touchwiz ,android everything.
Please help me to solve my problem
Click to expand...
Click to collapse
I think your Stuck with the bootloader..
The issue about im feeling lucky thing... I think you have malware on your device... Never heard of or seen nothing like that

hi,
this is my backup of the jb bootloader for the n8013 [n801x]
http://d-h.st/users/moonbutt74/?fld_id=39849#files
cwm flashable
m

moonbutt74 said:
hi,
this is my backup of the jb bootloader for the n8013 [n801x]
http://d-h.st/users/moonbutt74/?fld_id=39849#files
cwm flashable
m
Click to expand...
Click to collapse
Thanks man i havent tried it yet but i hope it will help
Sent from my SM-G900F using XDA Free mobile app

Hi, well I have the n8010 model.
and while you install the version of n8000 leak.
so my bootloader remained in n8000.
and then, after much, I put the rom gnabo v6.
and a few days ago, my note I do not step beyond the samsung logo, stayed stagnant.
try putting on the rom again, but not carrying anything.
I made full format from the recovery of the internal sdcard.
did wipes and try to flash the rom, but not!
I went back to install the 4.4 leak of n8000, but nothing.
and I get the error: failed mount / efs (invalid argument)
that I can do? please help.
sorry for my English, I'm from mexico

FGM 11 said:
Hi, well I have the n8010 model.
and while you install the version of n8000 leak.
so my bootloader remained in n8000.
and then, after much, I put the rom gnabo v6.
and a few days ago, my note I do not step beyond the samsung logo, stayed stagnant.
try putting on the rom again, but not carrying anything.
I made full format from the recovery of the internal sdcard.
did wipes and try to flash the rom, but not!
I went back to install the 4.4 leak of n8000, but nothing.
and I get the error: failed mount / efs (invalid argument)
that I can do? please help.
sorry for my English, I'm from mexico
Click to expand...
Click to collapse
I tried everything but nothing helped. And now i have the same efs problem like you. I hope that somebody can help us

This worked for the galaxy tab 3 10.1
okay,
a while back i helped a user with a similar problem. this was my approach HOWEVER, the following conditions
must be met first.
1 you are able to boot into recovery and maintain normal operation including adb root shell access
2 you are able to charge your tab from a powered off state, mostly to see if you charging animation shows.
that means your kernel is intact-ish
3 you can boot into odin mode.
assuming the partion layouts for your respective devices match the red highlighted sections of this output from parted.
Code:
[email protected]:/ # parted /dev/block/mmcblk0
GNU Parted 1.8.8.1.179-aef3
Using /dev/block/mmcblk0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print all
print all
Model: MMC MAG2GA (sd/mmc)
Disk /dev/block/mmcblk0: 15.8GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
[COLOR="Red"] 1 4194kB 8389kB 4194kB BOTA0
2 8389kB 12.6MB 4194kB BOTA1
3 12.6MB 33.6MB 21.0MB ext4 EFS
4 33.6MB 41.9MB 8389kB PARAM[/COLOR]
5 41.9MB 50.3MB 8389kB BOOT
6 50.3MB 58.7MB 8389kB RECOVERY
7 58.7MB 92.3MB 33.6MB RADIO
8 92.3MB 931MB 839MB ext4 CACHE
9 931MB 2399MB 1468MB ext4 SYSTEM
10 2399MB 2923MB 524MB ext4 HIDDEN
11 2923MB 2932MB 8389kB OTA
12 2932MB 15.8GB 12.8GB ext4 USERDATA
(parted)
AND provided you can get someone competent with access to the respective models to open a root shell
on device or through adb and run the following command,
Code:
[COLOR="Red"]dd if=/dev/block/mmcblk0 of=/sdcard/fix.img bs=1 count=35221668[/COLOR]
AND zip the output fix.img and post it, again for the respective devices.
THEN you can through adb,
adb push fix.img /sdcard/
or
adb push fix.img /sdcard
or
adb push fix.img /data/media/0/
or
adb push fix.img /data/media/0
you can then navigate TO the directory you pushed the image to and execute the following
dd if=fix.img of=/dev/block/mmcblk0
the above approach worked for me in helping another user with a like device.
you assume the same risk you took previously to achieve the state your device is in now.
NOTE- count=35221668 is a hair under the actual end of /efs . you may need to adjust through param and into boot maybe
half way , but then you can just reflash kernel or then do a proper odin flash of stock. the fix.img will NOT be odin flashable.
m

partitions
moonbutt74 said:
okay,
a while back i helped a user with a similar problem. this was my approach HOWEVER, the following conditions
must be met first.
1 you are able to boot into recovery and maintain normal operation including adb root shell access
2 you are able to charge your tab from a powered off state, mostly to see if you charging animation shows.
that means your kernel is intact-ish
3 you can boot into odin mode.
assuming the partion layouts for your respective devices match the red highlighted sections of this output from parted.
Code:
[email protected]:/ # parted /dev/block/mmcblk0
GNU Parted 1.8.8.1.179-aef3
Using /dev/block/mmcblk0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print all
print all
Model: MMC MAG2GA (sd/mmc)
Disk /dev/block/mmcblk0: 15.8GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
[COLOR="Red"] 1 4194kB 8389kB 4194kB BOTA0
2 8389kB 12.6MB 4194kB BOTA1
3 12.6MB 33.6MB 21.0MB ext4 EFS
4 33.6MB 41.9MB 8389kB PARAM[/COLOR]
5 41.9MB 50.3MB 8389kB BOOT
6 50.3MB 58.7MB 8389kB RECOVERY
7 58.7MB 92.3MB 33.6MB RADIO
8 92.3MB 931MB 839MB ext4 CACHE
9 931MB 2399MB 1468MB ext4 SYSTEM
10 2399MB 2923MB 524MB ext4 HIDDEN
11 2923MB 2932MB 8389kB OTA
12 2932MB 15.8GB 12.8GB ext4 USERDATA
(parted)
AND provided you can get someone competent with access to the respective models to open a root shell
on device or through adb and run the following command,
Code:
[COLOR="Red"]dd if=/dev/block/mmcblk0 of=/sdcard/fix.img bs=1 count=35221668[/COLOR]
AND zip the output fix.img and post it, again for the respective devices.
THEN you can through adb,
adb push fix.img /sdcard/
or
adb push fix.img /sdcard
or
adb push fix.img /data/media/0/
or
adb push fix.img /data/media/0
you can then navigate TO the directory you pushed the image to and execute the following
dd if=fix.img of=/dev/block/mmcblk0
the above approach worked for me in helping another user with a like device.
you assume the same risk you took previously to achieve the state your device is in now.
NOTE- count=35221668 is a hair under the actual end of /efs . you may need to adjust through param and into boot maybe
half way , but then you can just reflash kernel or then do a proper odin flash of stock. the fix.img will NOT be odin flashable.
m
Click to expand...
Click to collapse
Well this is how my partitions look like: http://kepfeltoltes.hu/view/140928/partitions2_www.kepfeltoltes.hu_.png

Instructions Matter
kataik95 said:
Well this is how my partitions look like: http://kepfeltoltes.hu/view/140928/partitions2_www.kepfeltoltes.hu_.png
Click to expand...
Click to collapse
K,
i must stress the need for you to follow instructions, hear me out, I am operating on the assumption that you are
an experienced android user.
1 the archive with the bootloader data i provided was a cwm flashable zip file. to attempt a flashing of that file itself
or the img files contained within in any other fashion has likely made your problem worse. i also stated as per the
name of the file that it is for the n8013. it is good to hear that you have made some progress however instructions
are important because,
2 though you have succeeded in using parted through adb you have provided the wrong information.
instead of
parted /dev/block/mmcblk0p8
please run
parted /dev/block/mmcblk0
then at the (parted) prompt running print all wil return the correct information.
I mean the above in the best way, as well to stress the importance of doing these things correctly
to avoid a true hard-bricking of your device. You will need to go hat in hand and request an experienced/competent
user/developer pull the needed data from their device as stated in my previous post.
it is likely that the data pulled from my device may work, but that your device afterwards will register as an n8013.
please re-execute parted through adb as instructed for the needed information and we can move foward from there.
m

moonbutt74 said:
K,
i must stress the need for you to follow instructions, hear me out, I am operating on the assumption that you are
an experienced android user.
1 the archive with the bootloader data i provided was a cwm flashable zip file. to attempt a flashing of that file itself
or the img files contained within in any other fashion has likely made your problem worse. i also stated as per the
name of the file that it is for the n8013. it is good to hear that you have made some progress however instructions
are important because,
2 though you have succeeded in using parted through adb you have provided the wrong information.
instead of
parted /dev/block/mmcblk0p8
please run
parted /dev/block/mmcblk0
then at the (parted) prompt running print all wil return the correct information.
I mean the above in the best way, as well to stress the importance of doing these things correctly
to avoid a true hard-bricking of your device. You will need to go hat in hand and request an experienced/competent
user/developer pull the needed data from their device as stated in my previous post.
it is likely that the data pulled from my device may work, but that your device afterwards will register as an n8013.
please re-execute parted through adb as instructed for the needed information and we can move foward from there.
m
Click to expand...
Click to collapse
Thanks for all the help you gave me but I decided to take my tab to a service, they probably make it work

kataik95 said:
Thanks for all the help you gave me but I decided to take my tab to a service, they probably make it work
Click to expand...
Click to collapse
Sure, no problem. Hope everything works out. :good:
m

moonbutt74 said:
Sure, no problem. Hope everything works out. :good:
m
Click to expand...
Click to collapse
Imagine after 2 services where the could't fix I took to a 3rd. They could fix it so it works its on 4.0.4 in some kind of factory mode (strange). I can not quit from this mode and odin not works as well. In the recovery it says efs is invaild. What is that fw?

[WIKO][WAX]recovery partition problem

Hi everybody,
Well, I'm in trouble ...
I find myself unable to flasher the recovery, it would be a worry of partition.
Indeed the command
Code:
nvflash -r --download 15 recovery.img
runs smoothly but the phone does not boot in normal mode or in recovery mode (blocked on" booting recovery mode" probably due to tight previous try).
After browsing the web, I conclude that I must stay on partition 16 and not 15 (it is already tests on the 16 with obviously not adapted recovery that caused the boot error).
But with the command
Code:
nvflash -r --download 16 recovery.img
I have the result:
Code:
Nvflash 4.10.1800 started
[resume mode]
recovery.img is too large for partition
command failure / warning: partition download failed
And then I'm stuck ...
So I really need your help, please ...

Hello,
Failing to be able to install custom recovery/ROM, at least I succeed getting it back to factory reset, thanks to a link provided by wiko support (big thanks to them) : http://support-fr.wikomobile.com/update-0-mise-a-jour
It work now like a charm, as new.

Can you copy for me file in data/rfs/data/modem
I am lost my baseband

Hello,
Sorrry, I can't help : I've sold this ugly phone and so I haven't it anymore.