yashsingh1/xdaforums huggingface dataset:
[Verizon Droid Charge] TrypWyr:
trparky,

I did as you directed. In fact, it's the same thingI did last night, same result. On step 19 and on, if you mean go into the stock recovery and do a factory reset, that's been done many times. As usual, it will not clear the CACHE partition, it gets "Invalid argument". I'm going on the assumption that this is due to the partition still being EXT4 and not RFS.

rj57,

I think that is the next step: I need a MBR file from someone with stock, unrooted EE4. I also had multiple nandroid backups from previous ROMs, including stock. None of them helped, I kept getting the same force closes on everything.

At this point, I am holding off taking the phone to Verizon. I really don't want to deceive them and get a new phone for something that should be fixable. The tech in me really wants to resolve this, not only for my own peace of mind, but for the many people seeing the same issue. Taking a device back to Verizon will only make rooters look bad, assuming they even figure out that was the cause.

BTW, I've run both Odin and PST on multiple PCs, all 64-bit Win7. My next thought is to just try it on a 32-bit WinXP, just for kicks. I will let you know on that one.

What would really assist me is a nice person who is willing to generate that MBR file for me! I would love to test that out... :D
[Verizon Droid Charge] trparky:
I have to wonder if the issue you're having is being caused by a hardware problem, as in somewhere in your phone the flash memory went bad. It's entirely possible.

I've seen posts about people having force closes on third-party ROMs as well as stock ROM (like yourself). I don't want to jinx myself but I have two Droid Charges (mine and my brother's) and both of them show no issues whatsoever on the third-party ROMs. On the stock ROM you shouldn't even be having those issues since you don't even have root to be messing with things that could cause that kind of stuff to happen.

There have been reports from people who have never even rooted or ROMed their phone having issues with the Factory Reset not working and even having the stock ROM going into a boot-loop. So I have to wonder if those people who are having those issues may have a phone with bad flash memory in it.
[Verizon Droid Charge] rj57:
Ok, I took a quick trip to stock EE4 + PIT and pulled this partition table from my phone right after I flashed CWM.

BTW, it is identical to the partition table from when I am on voodoo.

FOR ANYONE READING THIS. DO NOT TRY TO FLASH THIS WITH CWM OR TRY TO USE IT AS A PIT FILE IN ODIN. IT WOULD LIKELY DO NOTHING, BUT IF IT DID, IT PROBABLY WOULD NOT BE GOOD.:eek:
[Verizon Droid Charge] TrypWyr:
Sigh. Yeah, I used the dd command to output my mbr and it's identical to yours.

Well, I'm out of ideas...

Okay, one last try at PIT+EE4. Here is the Odin status window:

<ID:0/006> Added!!
<ID:0/006> Odin v.3 engine (ID:6)..
<ID:0/006> File analysis..
<ID:0/006> Enter CS for MD5..
<ID:0/006> Check MD5.. Do not unplug the cable..
<ID:0/006> Please wait..
<ID:0/006> Checking MD5 finished Sucessfully..
<ID:0/006> Leave CS..
<ID:0/006> SetupConnection..
<ID:0/006> Initialzation..
<ID:0/006> Set PIT file..
<ID:0/006> DO NOT TURN OFF TARGET!!
<ID:0/006> Get PIT for mapping..
<ID:0/006> Firmware update start..
<ID:0/006> boot.bin
<ID:0/006> Sbl.bin
<ID:0/006> param.lfs
<ID:0/006> factoryfs.rfs
<ID:0/006> dbdata.rfs
<ID:0/006> zImage
<ID:0/006> recovery.bin
<ID:0/006> movinand.bin
<ID:0/006> lte_modem.bin
<ID:0/006> cp_modem.bin
<ID:0/006> Completed..
<OSM> All threads completed. (succeed 1 / failed 0)

This is with Odin 1.3, with PIT, and with EE4 stock rom. This is what I get on first boot:

-- bootmode=7 from cmdline
E:Can't mount /dev/block/mmcblk0p1
(Invalid argument)

-- Movi_check Start..!!
checksum confirmation need_checksum[0]
Not need checksum confirmation

-- Movi_check already executed!!...

-- movi_checking done!..
E:Can't mount /dev/block/mmcblk0p3
(Invalid argument)
E:Can't mount CACHE:recovery/command
# MANUAL MODE #
E:Can't mount /dev/block/mmcblk0p3
(Invalid argument)
E:Can't mount CACHE:log/recovery.log
E:Can't open CACHE:log/recovery.log
E:Can't mount /dev/block/mmcblk0p3
(Invalid argument)

This is what I see in adb, using the mount command:

mount
rootfs on / type rootfs (rw)
tmpfs on /dev type tmpfs (rw,relatime,mode=755)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
none on /acct type cgroup (rw,relatime,cpuacct)
nodev on /tmp type tmpfs (rw,relatime)
/dev/block/stl7 on /mnt/.lfs type j4fs (rw,relatime)
tmpfs on /mnt/asec type tmpfs (rw,relatime,mode=755,gid=1000)
none on /dev/cpuctl type cgroup (rw,relatime,cpu)
/dev/block/stl10 on /system type rfs (rw,relatime,vfat,llw,check=no,gid/uid/rwx,
iocharset=utf8)
/dev/block/mmcblk1p1 on /sdcard type vfat (rw,nosuid,nodev,noexec,relatime,uid=1
000,gid=1015,fmask=0002,dmask=0002,allow_utime=0020,codepage=cp437,iocharset=iso
8859-1,shortname=mixed,utf8,errors=remount-ro)
/dev/block/mmcblk0p3 on /cache type ext4 (rw,noatime,barrier=0,data=writeback)
/dev/block/mmcblk0p1 on /data type ext4 (rw,noatime,barrier=0,data=writeback)

Then I get continual reboots on the animation screen with no sound.

If I install other ROMs, such as GummyCharged 2.0, I can get in to the ROM but I get FCs on everything until it finally reboots.

If I install a voodoo kernel, it appears to convert the filesystems. I then put the disable_lagfix file in the voodoo folder and it tries to convert back to RFS, but it still shows CACHE and DATA still as ext4.
[Verizon Droid Charge] rj57:
You could still try it. I looked at the procedure and it should basically do the same as you would do if you were to run parted on the MMC storage. You end up with fresh unformatted partitions. Everything that was on any of the cache, preinstall, and data partitions is more or less nuked. It's similar to running FDISK on older Windows and MSDOS disks. The first boot into stock, should then format the partitions to RFS.

Edit:

If that does not work, then we may be able to fix the partitions using parted and manually format the partitions to RFS. The parted program is not part of the CWM/Voodoo distribution, but I did find it from this link :http://www.droidforums.net/forum/htc-droid-eris/78650-internal-storage-partitions-screwed-up.html

Its kind of a pain getting the programs where you can use them in CWM, but parted appears to work at least good enough to print partition tables.:)

Looking back at everything, it looks like you found this procedure last week.
[Verizon Droid Charge] trparky:
Have you tried a newer version of Odin? 1.3 is pretty old. Also, are you sure you're checking the repartition checkbox in Odin?
[Verizon Droid Charge] rj57:
It looks like an issue may be that one of the voodoo kernels out there may have a bug on the lagfix conversion for the data partition. I did a partition list with parted on /dev/mmcblk0 and found something very interesting. It appears that the /data partition is being created with an ext2 filesystem. That seems a bit risky:

This is a parted dump that I got from my phone after it went from EE4+PIT->CWM->GC FE 2.0.

Model: MMC SEM02G (sd/mmc)

Disk /dev/block/mmcblk0: 1959MB

Sector size (logical/physical): 512B/512B

Partition Table: msdos

Number Start End Size Type File system Flags

1 32.8kB 1256MB 1256MB primary ext2

2 1256MB 1686MB 430MB primary fat16

3 1686MB 1959MB 273MB primary ext4

Edit: It looks like the ext2 thing may not be an issue as the partition is being mounted as ext4. All of the voodoo kernels for charge appear to be doing this.
[Verizon Droid Charge] TrypWyr:
LOL, oh yeah.

I've been testing with both 1.3 and 1.85. With 1.3 you have to manually check the repartition box even after you select the PIT file. With 1.85 once you choose a PIT file, the repartition box gets checked automatically.

In other words, yeah, I'm definitely checking the box and using a newer version. ;)
[Verizon Droid Charge] trparky:
I wonder why that is. I'd think that they would want to use EXT4.
[Verizon Droid Charge] rj57:
Actually, the ext2 is fine as it is being mounted as ext4. The ext4 cache though has my interest as imnuts' kernels do both cache and data as ext2. I had to do EE4+ PIT again couple of times last night after my phone had a complete hissy fit after disabling lagfix.

It booted once and then bootlooped after I tried to boot to recovery.

_____________________________

Bloat frozen EE4 with Poop n Pumpkin. theme

PBJT Voodoo 0730

V6 SuperCharger

Loopy Smoothness Tweak
[Verizon Droid Charge] trparky:
So what does that mean for the rest of us? Are we talking about a kernel bug here?

Any reason why you think you had to do multiple restores?
[Verizon Droid Charge] rj57:
In my case, it doesn't seem to be a kernel bug. My issue appears to have been related to the conversion back to RFS when lagfix is disabled. Looks like /dev/block/mmcblk0 got a bit messed up and wouldn't format properly.

I have been going through the Voodoo logs trying to get to the bottom of this. It looks like the conversion of the cache partition to RFS blew up when the rfs_formatter tried to format it back to FAT16 .

As for the multiple restores, I may have mucked things up by trying to do too much at once. I did basically this sequence:

[1]Flashed EE4+PIT using Odin - went perfect

[2]Rebooted - looped once, had the movinand error that TrypWyr, zagoric, ercDROID, and others got.

[3]Was getting ready to pull the battery, but it proceded to format all of the partitions on its own and finished booting.

[4]Did the basic setup using my secondary gmail account - no issues.

[5]Rebooted it once - no issues

[6]Powered down

[7]Flashed CWM

[8]Installed PBJT 0730 voodoo kernel

[9]Rebooted without converting - ok, forgot to remove disable-lagfix file

[10]Installed free version of Voodoo Control - Market would not let me use my primary account

[11]Enabled Lagfix

[12]Set to Factory Defaults so that I could set up on primary gmail account after boot

[13]Phone bootlooped for 15 minutes - borked at this point

After that, I did the PIT+EE4 again and went to my current configuration which was very stable for the almost 3 months that I ran it.
[Verizon Droid Charge] trparky:
So let me get this straight, those of us who have opted to use a third-party ROM may have issues going back to the stock ROM?

Or have you been able to go back to stock successfully? Then load a third-party ROM after that and have it load successfully?

Sorry to be a pest but I'm just trying to find out what is going on.

That sounds like a kernel bug to me. As in somewhere in the voodoo conversion process something is broken.
[Verizon Droid Charge] TrypWyr:
Seems to sum up part of the issue...

The big part for me tho (and others) is that the PIT file is supposed to (in my limited understanding) wipe out and recreate the partitions, but it's not doing the job.
[Verizon Droid Charge] trparky:
You know... try this. It may be a long shot at best so it may not even work.

The EE4 download that I found on the Internet doesn't seem (at least to me) a complete ROM file. When I look at the TAR file in question (I made a copy of the tar.md5 file and renamed it to just .tar) in an archive utility it seems like it's missing files. Don't know if that's supposed to be that way.

http://www.toms-world.org/android/CI510_VZW_ED1_ALL_ONE-LTE-CP_REV03_user_CL986330.tar.7z <-- ED1 ROM file

Try that file.
[Verizon Droid Charge] TrypWyr:
Yup, tried that ED1, EE4, EP1F, and EP1W.

I don't think the ROM is the issue. We need to find a way to correctly reset the mmcblk0 information back to stock. Does that sound right? I'm still learning this mess... ;)
[Verizon Droid Charge] rj57:
There is something that you may be able to try short of running parted and completely redoing the partitions. The Partition Table appears to be intact and the way that it should be. The problem is likely a file system problem. Most of the format scripts appear to do an rm -R * and call it a format.:rolleyes:

The following procedure should at a minimum fix the ext4 problem with the cache partition and format it to FAT16 like the stock file system. While we are at it you may want to manually format the data partition.

Here are the steps:

Assuming that you have flashed the EE4 package in Odin and are stuck at the movinand error

1.) Flash imnuts' 8/17 CWM

2.) Boot into recovery (CWM)

3.) connect with an adb shell

4.) in adb shell, 'ls -l /bin/fat.format'

5.) if the listing from step 4 shows a file that is 17064 bytes in size, procede to step 6. Otherwise, flash imnuts' voodoo kernel 0730 or 0807 and repeat step 4

6.) unmount /cache and /data from mounts and storage in CWM if they are mounted

7.) execute the following command EXACTLY as listed:

/usr/bin/fat.format -v -S 4096 -s 2 -F 16 /dev/block/mmcblk0p3

8.) note any errors and post them if you get any

9.) to format the data partition, execute the following command EXACTLY as listed:

/usr/bin/fat.format -v -S 4096 -s 4 -F 32 /dev/block/mmcblk0p1

10.) if you get any errors, note them and post them.

11.)Depending on if you had to install a voodoo kernel in step 5 or already had one installed previously:

a) no voodoo kernel: reboot. If it completes the boot, you should be home free

a1) boot fails, flash EE4 with no PIT and then reboot

b)voodoo kernel installed: flash EE4 with no PIT and reboot

​

12.) If boot does not complete, flash EE4+PIT and reboot. Post any boot errors if the boot is unsuccessful.
[Verizon Droid Charge] trparky:
That has got to be the most f**ktarded thing I've seen in a while!

But then again, probably the most f**ktarded thing is that Samsung didn't use EXT4 for the file system of this phone. That and taking out the EXT4 file system kernel driver from the default kernel. That was stupid! EXT is about as basic to Linux as the kernel itself!
[Verizon Droid Charge] imnuts:
the reason scripts do an rm -rf is because if it were to format it, it doesn't work properly due to bml and rfs.
[Verizon Droid Charge] trparky:
So do you have any insights imnuts into fixing this issue for this user?
[Verizon Droid Charge] TrypWyr:
Flashed EE4+PIT, got mount error.

Installed CWM, unable to locate fat.format.

Flashed imnuts 7/30 kernel, now able to locate file but the file size is slightly different than you listed:

~ # ls -l /bin/fat.format
ls -l /bin/fat.format
-rwxr-xr-x 1 system system 17864 Jul 31 2011 /bin/fat.format

Ran the commands, no errors (One problem here, you command was /usr/bin/fat.format. When I tried that it said "not found". Used /bin/fat.format and it worked fine.):

~ # /bin/fat.format -v -S 4096 -s 2 -F 16 /dev/block/mmcblk0p3
/bin/fat.format -v -S 4096 -s 2 -F 16 /dev/block/mmcblk0p3
fat.format 1.0, 2010.07.01
===================================
- Volume size: 272629760 Bytes
- FAT type: 16 bits
- FAT size: 18 sectors
- Total sectors: 66560 sectors
- Cluster counts: 33115
- Sector size: 4096 Bytes
- Sectors/cluster: 2
- FAT start: 290th sector
- RDIR start: 326th sector
- DATA start: 330th sector
- PBR start: 0th sector
===================================
Success to format
~ # /bin/fat.format -v -S 4096 -s 4 -F 32 /dev/block/mmcblk0p1
/bin/fat.format -v -S 4096 -s 4 -F 32 /dev/block/mmcblk0p1
fat.format 1.0, 2010.07.01
===================================
- Volume size: 1256161280 Bytes
- FAT type: 32 bits
- FAT size: 76 sectors
- Total sectors: 306680 sectors
- Cluster counts: 76559
- Sector size: 4096 Bytes
- Sectors/cluster: 4
- FAT start: 290th sector
- RDIR start: 442th sector
- DATA start: 442th sector
- PBR start: 0th sector
===================================
Success to format

Flashed EE4 with no PIT using Odin, rebooted, same mount errors.

Done this twice now. The second time I did remount the /cache and /data partitions, they still showed up as ext4 after the format.
[Verizon Droid Charge] rj57:
It looks like it should be formatted to RFS on both cache and data now. This is very interesting. Let me put together some instructions a parted binary that you can push with adb and list what the partitions are really.

This is very interesting and I am now thinking that there may be a problem with your stock recovery.bin

Oh, on the file size, I double checked and you were right. Was working off of my laptop today and misread the 8 as a 0.
[Verizon Droid Charge] rj57:
Ok here is how to use parted to list out your partitions. I wouldn't do anything other than list the partition at this point

1) unzip the attached parted.zip into your android sdk platform-tools directory

2) You should have CWM and a voodoo kernel installed

3.) push the parted binary to /usr/sbin/

adb push parted /usr/sbin/

4.) open adb shell

5.) verify that parted is where you pushed it to

ls -l /usr/sbin/parted

it should look like this:

ls -l /usr/sbin/parted -rw-rw-rw- 1 root root 346680 Aug 19 2010 usr/sbin/parted

6.) give it some execute permissions

chmod 0755 /usr/sbin/parted

7.) check your work

ls -l /usr/sbin/parted

It should like this

ls -l /usr/sbin/parted -rwxr-xr-x 1 root root 346680 Aug 19 2010 usr/sbin/parted

8.) run the parted command to list your partitions on mmcblk0

/usr/sbin/parted /dev/block/mmcblk0 print

Post what you get from running the command
[Verizon Droid Charge] rj57:
You should be able able to flash EE4+PIT fine. There is some risk as always when you use Odin to flash something The original instructions in this thread have worked well for me but there have been some issues with others. If you do it, I would recommend the EE4 file from the thread link below and follow the instructions precisely. Don't panic and pull the battery on the first boot if it bootloops at first. Give it up to a good 10 minutes on the Samsung and up to 10 minutes on the boot animation.

http://xdaforums.com/showthread.php?t=1172182
[Verizon Droid Charge] trparky:
EE4? I thought that people had more success with the ED1 file.
[Verizon Droid Charge] rj57:
I suppose that you could go with the ED1 file. The EE4 that I recommended has worked fine on several phones for me. In fact, it's the one that I am on now

_____________________________

Bloat frozen EE4 with Poop 'n Pumpkin theme

PBJT Voodoo 0730

V6 SuperCharger

Loopy Smoothness Tweak
[Verizon Droid Charge] TrypWyr:
Well, with the exception that there does not appear to be a /usr directory, everything working fine. Here is the output from parted:

~ # ls -l /sbin/parted
ls -l /sbin/parted
-rw-rw-rw- 1 root root 346680 Sep 18 2011 /sbin/parted
~ # chmod 0755 /sbin/parted
chmod 0755 /sbin/parted
~ # ls -l /sbin/parted
ls -l /sbin/parted
-rwxr-xr-x 1 root root 346680 Sep 18 2011 /sbin/parted
~ # /sbin/parted /dev/block/mmcblk0 print
/sbin/parted /dev/block/mmcblk0 print
Model: MMC SEM02G (sd/mmc)
Disk /dev/block/mmcblk0: 1959MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags
1 32.8kB 1256MB 1256MB primary ext2
2 1256MB 1686MB 430MB primary linux-swap(v1)
3 1686MB 1959MB 273MB primary ext2

~ #
[Verizon Droid Charge] rj57:
OK, looks like you are on partitions that were formatted with Imnuts' 0807 kernel. Try the fat.format from before and then run the parted list without booting

Edit: you also will need to fat.format /dev/block/mmcblk0p2 just like mmcblk0p3

_____________________________

Bloat frozen EE4 with Poop 'n Pumpkin theme

PBJT Voodoo 0730

V6 SuperCharger

Loopy Smoothness Tweak
[Verizon Droid Charge] TrypWyr:
~ # /bin/fat.format -v -S 4096 -s 4 -F 32 /dev/block/mmcblk0p1
/bin/fat.format -v -S 4096 -s 4 -F 32 /dev/block/mmcblk0p1
fat.format 1.0, 2010.07.01
===================================
- Volume size: 1256161280 Bytes
- FAT type: 32 bits
- FAT size: 76 sectors
- Total sectors: 306680 sectors
- Cluster counts: 76559
- Sector size: 4096 Bytes
- Sectors/cluster: 4
- FAT start: 290th sector
- RDIR start: 442th sector
- DATA start: 442th sector
- PBR start: 0th sector
===================================
Success to format
~ # /bin/fat.format -v -S 4096 -s 2 -F 16 /dev/block/mmcblk0p2
/bin/fat.format -v -S 4096 -s 2 -F 16 /dev/block/mmcblk0p2
fat.format 1.0, 2010.07.01
===================================
- Volume size: 429916160 Bytes
- FAT type: 16 bits
- FAT size: 26 sectors
- Total sectors: 104960 sectors
- Cluster counts: 52307
- Sector size: 4096 Bytes
- Sectors/cluster: 2
- FAT start: 290th sector
- RDIR start: 342th sector
- DATA start: 346th sector
- PBR start: 0th sector
===================================
Success to format
~ # /bin/fat.format -v -S 4096 -s 2 -F 16 /dev/block/mmcblk0p3
/bin/fat.format -v -S 4096 -s 2 -F 16 /dev/block/mmcblk0p3
fat.format 1.0, 2010.07.01
===================================
- Volume size: 272629760 Bytes
- FAT type: 16 bits
- FAT size: 18 sectors
- Total sectors: 66560 sectors
- Cluster counts: 33115
- Sector size: 4096 Bytes
- Sectors/cluster: 2
- FAT start: 290th sector
- RDIR start: 326th sector
- DATA start: 330th sector
- PBR start: 0th sector
===================================
Success to format
~ # /sbin/parted /dev/block/mmcblk0 print
/sbin/parted /dev/block/mmcblk0 print
Model: MMC SEM02G (sd/mmc)
Disk /dev/block/mmcblk0: 1959MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags
1 32.8kB 1256MB 1256MB primary ext2
2 1256MB 1686MB 430MB primary linux-swap(v1)
3 1686MB 1959MB 273MB primary ext2

~ #
[Verizon Droid Charge] rj57:
Let's try to flash EE4 + PIT and force the first boot to stock recovery using the 3 button method

Then, wipe cache, data and then format the internal sdcard in that order.

Then reboot from recovery

_____________________________

Bloat frozen EE4 with Poop 'n Pumpkin theme

PBJT Voodoo 0730

V6 SuperCharger

Loopy Smoothness Tweak
[Verizon Droid Charge] TrypWyr:
Well, after an Odin flash it goes into the stock recovery automatically and immediately gives that mounting error. Tried factory reset, cache wipe, and sdcard wipe, still getting the silent boot animation loop.
[Verizon Droid Charge] rj57:
I think that cache and data are mounted at this point.

Before we do much else it might help to get some more information at this point before flashing anything else.

The point of all of this is to try to find at what point in the init is the phone hanging on boot. I have a suspicion that the /system partition may have a little bit of Gummy in it despite everything that we have done to this point. That would explain it booting most of the way when you flash Gummy onto it. It might also explain the silent boot animation.

1.) boot into stock recovery (3 button method)

2.) get recovery log adb shell cat /recovery.log > lstrecovery_log.txt

3.) get dmesg messages adb shell dmesg tail > lstdmesgr.txt

4.) get mount listing adb shell mount > lstmountr.txt

5.) get listing of root directory adb shell ls -l / > lstrootfs.txt

6.) get listing of /system directory adb shell ls -l /system > lstsystem.txt

7.) reboot from recovery

8.) when it gets to silent boot animation, adb shell dmesg tail > lstdmesg1.txt

9.) get mounts at this point adb shell mount > lstmountb.txt

10.) zip up the listings and post
[Verizon Droid Charge] TrypWyr:
here ya go..

On steps 8 and 9, I couldn't get anything as the device isn't detected on the PC during the boot animation cycle. I just get the msg device not detected.

On the mount log, it doesn't show /cache or /data, I guess they aren't mounted in stock recovery, at least not when they are having issues. This kind of makes sense to me, like the stock recovery can't read ext4 file systems and that's what they are stuck on.
[Verizon Droid Charge] rj57:
Ok, there are some messages in the dmesg log that tell me that the problem is definitely on mmcblk0. It is attempting a format and is failing.

I know that in linux on a hard disk or vm, I would just use parted and be done with it. I have searched a little bit to see if anyone else has done parted on movinand storage and if it has been done, they are't talking about it. I do have concerns about permanantly nuking the mmcblk0 device. I'll take a look at the errors in dmesg and see if we can come up with a plan.

In the mean time, here is the gnu parted manual http://www.gnu.org/s/parted/manual/parted.html#Top