Database Users

[how-to] Install CM6 on Nexus One (SLCD version) with HBOOT 0.35.0017

Ok so I decided to put this up together because it took me two days of forum searching to gather the different bits and to understand what was happening.
Update: see the complete wiki here : http://forum.xda-developers.com/wiki/index.php?title=Nexus_One/Recovery_Images
This applies to some latest N1 stock models as such:
MODEL: Nexus One (SLCD version)
HBOOT: 0.35.0017
RADIO: 32.41.00.32U_5.08.00.04
BUILD: FRF91
WHAT YOU WILL GET :
- Root without unlocking your bootloader
- Successfully Install Recovery
- Successfully Install CM6
WARNING: This method worked for me, It should work for you in the same conditions. If you intend to install a moded rom over your stock N1 , you are supposed to know what you 're doing. I can't be held responsable if you brick (not likely) your phone, break-up with your lover or witness a nuclear explosion.
----- Since I'm a new subscriber, ALL links in the guide don't work , just paste them in your browser -------
A- Root your phone​Get latest Universal Androot from (blog.23corner.com/tag/universalandroot/) install the app and follow the instructions.
This has the benefit of rooting your device without unlocking your bootloader and thus NOT voiding your warranty.
B- Install Recovery.​Since you got an S-LCD device you can't use the default Clockwork Recovery (for example if you install Rom Manager). If you do you'll end up with a black screen when rebooting into recovery and will not be able to go on to proceed to flashing the Rom.
You need to get Amon_RA Recovery v1.8.0.1 (I think v1.8.0.0 also works)
you can get it here : (alternate-coding.com/recovery-RA-nexus-v1.8.0.1-aw.img)
Since you didn't unlock the bootloader I believe you can't use the fastboot commands to flash the recovery, so it's a bit tricky but you have to install it with another method :
First you need to have Adb installed in your computer.
follow this guide: (forum.xda-developers.com/showthread.php?t=690362)
First save the file flash_image (get it here benocharm.lensworks.org/flash_image) to the root of you SD card
1) also put the recovery-RA-nexus-v1.8.0.1-aw.img to the root of your SD:
- next unmount the SD put keep your phone connected to the USB
2) Open a terminal prompt (if you do Windows type "CMD") and navigate to your adb "Tools" folder, type "adb shell" and hit Enter (don't write the quotes "" from now on)
3) On the terminal write "su" and hit enter
- Caution: At this point your phone should ask you permission to use the SuperUser app (if it does not you have to allow it specifically)
- Now on your terminal window the "$" symbol should change to a "#"
4) Still on the terminal, write "mount -o rw,remount /dev/block/mtdblock4 /system" and hit Enter
5) on the terminal, write "cat /sdcard/flash_image > /system/bin/flash_image" and hit Enter
6) on the terminal, write "chmod 775 /system/bin/flash_image" and hit Enter
7) on the terminal, write "flash_image recovery /sdcard/recovery-RA-nexus-v1.8.0.1-aw.img" and hit Enter
8) on the terminal, write "rm /system/etc/install-recovery.sh" and hit Enter
9) on the terminal, write "rm /system/recovery-from-boot.p" and hit Enter
10) Next: type exit + Enter till you get out of Terminal
You'll find that maybe steps 8 and 9 give you an error because the files don't exist, so don't worry anyways.
Now you should be set,
next, reboot the phone holding the Power button on + volume down and go into
recovery to see if anything went OK.
C- install CM6​
Get yourself the latest Cyanogen ROM.
Since your phone has got HBOOT 0.35.0017, if you try to flash CM6 from recovery, it will give you an error and fail.
This is because the update script of CM6 checks for HBOOT 0.33.0012 and fails.
Some people have got a way around this by reverting phone to HBOOT 0.33, (just do a search in this forum if you need this) but personally I prefer a less "destructive" and simplier method.
What you need to do is to get winrar, or another zip/compress tool and unzip the rom.
Navigate to folder "META-INF\com\google\android\updater-script" and open "updater-script" with your favorite text editor.
What you need to do is to comment 3 lines of it:
Almost in the beginning of the script look for this part :
Code:
assert(getprop("ro.product.device") == "passion" || getprop("ro.build.product") == "passion" || getprop("ro.product.board") == "passion");
assert(getprop("ro.bootloader") == "0.33.2012" ||
getprop("ro.bootloader") == "0.33.0012");
ui_print(" ");
ui_print(" ");
ui_print(" ");
You need to change it so that it goes like this.
Code:
# assert(getprop("ro.product.device") == "passion" || getprop("ro.build.product") == "passion" || getprop("ro.product.board") == "passion");
# assert(getprop("ro.bootloader") == "0.33.2012" ||
# getprop("ro.bootloader") == "0.33.0012");
ui_print(" ");
ui_print(" ");
ui_print(" ");
That's it !
Now repack the rom (CAUTION: if you did unzip it don't zip the resulting folder, just zip ALL the files IN IT, otherwise it will give you an error later)
Next copy the Rom to the root of you phone SD card.
Now reboot into Recovery and flash your Rom.
Welcome to CM6 !!
I hope this will help someone.
Please keep in mind I'm by no means a specialist, and that there are maybe other (better) ways to achieve this (I didn't find them). Also my knowledge of Android is very limited so I won't probably be able to help you if you run into problems following this how-to. I repeat, I did it and worked ok for me.
I will be happy that some of you maybe correct or contribute to what I have exposed if you fell like it.
Cheers

Thank you for posting this.
Where did you get an SLCD nexus one from though?

They ship them now in Vodafone Spain

Has been fixed in the nightly builds.
github.com/CyanogenMod/android_device_htc_passion/commit/6d19e88c86f01b68a206fa27a49bf58567ff255e
I am not allowed to post links, normally just lurk here and post on the CyanogenMod forums.

I'm surprised that ROM Manager still hasn't been updated to include recovery images that support SLCD Nexus Ones.

kibje said:
Has been fixed in the nightly builds.
github.com/CyanogenMod/android_device_htc_passion/commit/6d19e88c86f01b68a206fa27a49bf58567ff255e
I am not allowed to post links, normally just lurk here and post on the CyanogenMod forums.
Click to expand...
Click to collapse
Thanks ! good to know
cmstlist said:
I'm surprised that ROM Manager still hasn't been updated to include recovery images that support SLCD Nexus Ones.
Click to expand...
Click to collapse
Yes indeed I am surprised too, but I think koush will be working on this sooner or later, tweeted asking for plans about this but no news so far.

I'd imagine it wouldn't be too big a change, seeing as versions now exist which support the SLCD Desire.
Sent from my Nexus One using XDA App

Hi!
I'm stuck with a boot partition with bad blocks which prevents me from flashing other custom ROMs than CM6. I read somewhere that the new hboot 0.35.0017 changed the partition sizes so that might help me.
Could you do a
#cat /proc/mtd so I can see if the sizes differ from mine?

ollegut said:
Hi!
I'm stuck with a boot partition with bad blocks which prevents me from flashing other custom ROMs than CM6. I read somewhere that the new hboot 0.35.0017 changed the partition sizes so that might help me.
Could you do a
#cat /proc/mtd so I can see if the sizes differ from mine?
Click to expand...
Click to collapse
Ok so that's what I get:
Code:
# cat /proc/mtd
dev: size erasesize name
mtd0: 000e0000 00020000 "misc"
mtd1: 00400000 00020000 "recovery"
mtd2: 00380000 00020000 "boot"
mtd3: 09100000 00020000 "system"
mtd4: 05f00000 00020000 "cache"
mtd5: 0c440000 00020000 "userdata"
good luck !

cestbibi said:
Ok so that's what I get:
Code:
# cat /proc/mtd
dev: size erasesize name
mtd0: 000e0000 00020000 "misc"
mtd1: 00400000 00020000 "recovery"
mtd2: 00380000 00020000 "boot"
mtd3: 09100000 00020000 "system"
mtd4: 05f00000 00020000 "cache"
mtd5: 0c440000 00020000 "userdata"
good luck !
Click to expand...
Click to collapse
Great! It looks like they grew the boot partition
Guess I should try updating to a ROM with the new hboot that's rootable...
Thanks for the help!

A very concise but complete Wiki has been updated on this matter courtesy of Jack_R1
h**p://forum.xda-developers.com/wiki/index.php?title=Nexus_One/Recovery_Images
**damm I still can't embed links**

didnt work for me, korean slcd

xx_ED_xx said:
didnt work for me, korean slcd
Click to expand...
Click to collapse
What exactly didn't work ?
This is an old thread because by now every major ROM and Recovery work with SLCD N1.
Have you had a look at the wiki ? (see update and link on first page)

The Wiki has been great, though I find myself stuck at the download flash_image (benocharm.lensworks.org/flash_image) step.
I've done some Googling and found it here - cyanogen-files.carneeki.net/flash_image.zip.
I'll update the Wiki link if I can as well.

Non-kernel kernel hacking

hellmonger asked me to repost this as a new thread. I'm not entirely sure he wasn't pulling my chain.. but whatever... here it is.
There's development going on for kernel's that can't be flashed anyway. So every time you boot your phone you need your PC handy for fastboot... fun experiment, but no thanks.
Support for ext2/3/4, and any of the other modular changes the kernel mods do can probably be made (and possibly even made useful) without changing the actual kernel image (flashed or otherwise).
I now see it's not like nobody here thought of this (and I didn't mean to presume otherwise), example here:
http://forum.xda-developers.com/showthread.php?t=929871
The point that I did add was:
From my samsung experience, one click lag fix mounted /data without modifying the kernel by replacing the splash screen binary, which came up before data was mounted needed (other things used this trick too). It's not near as elegant but it may be possible to place kernel modules in /system/extramodules or whatever load them at some time like that, and then get support from then on.
The file on samsung was called playlogos or playlogos1 depending on the device. It did more than just play a logo I think.. and actually it had to be moved, replaced with a script.. and the script then should run the moved copy in the end. I don't see this file on the Motorola, but maybe there is something similar. If being clever, you make the script copy another script in from the sd card, chmod it and run it. Then if you make changes to the real script that cause boot loops, you can just modify it on the sd card, or pull it.
This would then be something that doesn't require a PC to do. Obviously anything requiring changing the actual kernel zImage won't work.
It's not beautiful, but neither is fastboot. For korean sgs it was possible to compile kernel modules for ext4 that would run on the stock kernel. (you should read through that thread I linked though.. some good point made there about that).
If you want to use another filesystem for your primary (as opposed to linked) /data there are some important details that I'm no longer remembering perfectly. The typical boot loop check for /data happened after this splash screen so that was ok, but it was I think still necessary to have the kernel not fail to mount /data before that (Probably the partition will get reformatted if it can't be mounted). If so, one possibility may be to repartition to make a tiny fake data partition and then remount the real one, just and idea. The reason things worked for OCLF was that OCLF left /data partition unmodified, but mounted an ext2 image file sitting on /data, arguably not an appealing thing to do, but it had its uses on Samsung devices depending who you asked.
Mioze7ae since pointed out in passing though that partition tables are burned into the kernel, so this repartition trick may still be a no-go. Anyway I don't know exactly what goals people have for using various filesystems on XT720 devices, and filesystems are not the only modular changes being made to some of these kernels that maybe don't need to be in-kernel, in a flashing sense.
I probably don't intend to be a primary developer on anything this involved... no time, just ideas, testing, etc at most.

about mtd partitions
Actually they are passed as parameters to the kernel...
Code:
/$ cat /proc/cmdline
console=ttyS2,115200n8 console=ttyMTD10 rw [email protected] init=/init ip=off brdrev=P3_TABLET_SKT androidboot.bootloader=0x0000 mtdparts=omap2-nand.0:[email protected](pds),[email protected](cid),[email protected](logo),384k(misc),3584k(boot)ro,[email protected](recovery),8960k(cdrom),[email protected](system),[email protected](cache),177280k(userdata),1536k(cust),[email protected](kpanic)
and then they are visible
Code:
/$ cat /proc/mtd
dev: size erasesize name
mtd0: 00180000 00020000 "pds"
mtd1: 00060000 00020000 "cid"
mtd2: 000a0000 00020000 "logo"
mtd3: 00060000 00020000 "misc"
mtd4: 00380000 00020000 "boot"
mtd5: 00480000 00020000 "recovery"
mtd6: 008c0000 00020000 "cdrom"
mtd7: 0c7a0000 00020000 "system"
mtd8: 06a00000 00020000 "cache"
mtd9: 0ad20000 00020000 "userdata"
mtd10: 00180000 00020000 "cust"
mtd11: 00200000 00020000 "kpanic"
for example hex 0xad20000 is decimal 181534720, which divided by 1024 equals to 177280 (e.g. the 177280k(userdata) )
about modules, i use following not included in the stock:
jbd, ext*, overclock, tun, (and some cpu governors)
Also when i was on eclair, i used jit, dalvik-cache was on /cache partition, was able to move all the apps on sdcard (slow), was able to "link" selected (usually big and not often used ones) files to the sdcard.

All kernel modules loaded without kernel.
But some kernel features like swap or thumbee are not kernel-module... they in kernel itself...
So..

peshovec said:
Actually they are passed as parameters to the kernel...
Code:
/$ cat /proc/cmdline
console=ttyS2,115200n8 console=ttyMTD10 rw [email protected] init=/init ip=off brdrev=P3_TABLET_SKT androidboot.bootloader=0x0000 mtdparts=omap2-nand.0:[email protected](pds),[email protected](cid),[email protected](logo),384k(misc),3584k(boot)ro,[email protected](recovery),8960k(cdrom),[email protected](system),[email protected](cache),177280k(userdata),1536k(cust),[email protected](kpanic)
and then they are visible
Code:
/$ cat /proc/mtd
dev: size erasesize name
mtd0: 00180000 00020000 "pds"
mtd1: 00060000 00020000 "cid"
mtd2: 000a0000 00020000 "logo"
mtd3: 00060000 00020000 "misc"
mtd4: 00380000 00020000 "boot"
mtd5: 00480000 00020000 "recovery"
mtd6: 008c0000 00020000 "cdrom"
mtd7: 0c7a0000 00020000 "system"
mtd8: 06a00000 00020000 "cache"
mtd9: 0ad20000 00020000 "userdata"
mtd10: 00180000 00020000 "cust"
mtd11: 00200000 00020000 "kpanic"
for example hex 0xad20000 is decimal 181534720, which divided by 1024 equals to 177280 (e.g. the 177280k(userdata) )
Click to expand...
Click to collapse
I don't think we have any way to change boot parameters because they are signed. In fact when I was testing with fastboot, I tried changing the kernel parameters in Motorola's boot.img and nothing changed. I decided that Motorola's kernels also ignore boot parameters entirely. Other than fastboot, the first point we can hijack anything is when the boot process first executes something from /system which limits our ability to repartition...
Sent from my XT720 using XDA Premium App

agree...
with my limited experience with embedded devices i suppose folowing:
the bootloader loads the so called initrd.img and kernel.img.
Then in very early boot process the mtd partition are created (if needed.
After that the control is passed to the kernel...
In fact when I was testing with fastboot, I tried changing the kernel parameters in Motorola's boot.img and nothing changed
Click to expand...
Click to collapse
may be that was not bad i mean if you give different layout of the mtd flash, then your filesystem data will be very likely mismatched (e.g. not useful readable).
But let me clarify: You have tried to modify the mtd parameters? and nothing happens?

If these things are like samsung, if the filesystem is not readable,they get reformatted early on bootup (at least /data and probably /cache). So early repartitioning /cache and /data wouldn't cause big problems if you managed out how to do it. But doing it with fastboot doesn't interest me much anyway. Of course that reformatting is also big part of the problem. If you manage to repartition later in the bootup (which should be possible right?) things will get reformatted on next bootup before you can get control again.
One bad idea is to hijack recovery mode (which maybe doesn't do that?) and use it as a normal boot mode. Pressing some key combo is better than needing a PC, however, if you ever forgot to press the combo, you get reformatted.. ouch. There does seem to be no nice way out if you're interested in changing the /data or /cache partitioning or fs. For everything else, work on user-friendly late module loading schemes seems much more useful than fastboot. Ok not everything.. fjfaclon makes a good point clearly, but fastboot is not solution as far as I care (of course if others find it useful, I have not complaint).
I get that Mioze7ae probably wants to reallocate memory for /cache and /data, but is there a compelling reason to reformat /data on this device to ext or something? On samsung, rfs (their proprietary fs) was a bit slow (I'm not as critical of it as many, I think it was just set up very safe.. in the end ext4 is not that much faster if setup just as safe... but that's a flame war for another forum) .

Oh one more point... Even if boot paramters aren't doing the partitioning is it entirely clear that it's in the kernel image? Maybe it's hidden somewhere else. With samsung's flash tool there was a pit file separate from the kernel image and not usually required for flashes. That was responsible for defining the partitioning, but it was never clear to me that anyone ever really understood how.

Well, I don't know definitively, but this is why I'm pessimistic about the theory that the partition table is stored outside boot.img. I work a lot with two sbfs. The CBW 2.1 Milestone XT720 and the SKT 2.2.1 Motoroi XT720. These differ in partition structures. Both will run fine on Milestone XT720 if you flash the entire image, but if you take the kernel from one and use nandroid to install it on the other, it doesn't work. To me this indicates that the partition table structure is inside boot.img somewhere. As a practical matter whether it's inside the kernel or the initramfs doesn't matter. A long time ago, I tried using boot parameters on fastboot to get the kernels to boot on the opposite sbfs and I couldn't get it to work. It's possible I was doing it wrong though. At the time we were using the mot_boot_mode hijack (that's still widely used here). There is a sh_hijack that I've been using later that happens very much earlier in boot. Perhaps that could make a difference, but at the time I didn't know to investigate that.
Also, recovery is signature checked on XT720, so we can't touch it. The security on XT720 is much closer to DroidX than it is to Milestone A853.

sh sounds like a really good hijack, might be early enough to mess with /data and /cache. mount might also work. Clearly if filesystems are checked/reformatted before /system is mounted, then there's no hope.
I thought recovery called stuff from /system, but that's probably my ignorance. Anyway, probably no need to beat this bad idea (the recovery idea) any more dead regardless.

Mioze7Ae said:
Well, I don't know definitively, but this is why I'm pessimistic about the theory that the partition table is stored outside boot.img. I work a lot with two sbfs. The CBW 2.1 Milestone XT720 and the SKT 2.2.1 Motoroi XT720. These differ in partition structures. Both will run fine on Milestone XT720 if you flash the entire image, but if you take the kernel from one and use nandroid to install it on the other, it doesn't work. To me this indicates that the partition table structure is inside boot.img somewhere. As a practical matter whether it's inside the kernel or the initramfs doesn't matter. A long time ago, I tried using boot parameters on fastboot to get the kernels to boot on the opposite sbfs and I couldn't get it to work. It's possible I was doing it wrong though. At the time we were using the mot_boot_mode hijack (that's still widely used here). There is a sh_hijack that I've been using later that happens very much earlier in boot. Perhaps that could make a difference, but at the time I didn't know to investigate that.
Also, recovery is signature checked on XT720, so we can't touch it. The security on XT720 is much closer to DroidX than it is to Milestone A853.
Click to expand...
Click to collapse
Have you ever deodexed the thing? On the Defy they deodexed everything on some ROMS. Have you tried that on our XT720 already?

Vistaus said:
Have you ever deodexed the thing? On the Defy they deodexed everything on some ROMS. Have you tried that on our XT720 already?
Click to expand...
Click to collapse
I've never quite understood what is meant with deodexing. From what I understand an odexed ROM has *.odex files external to the apks instead of *.dex inside the apks? Is that right? If so, I don't think any of the XT720 ROMs are odexed. None of the XT720, XT701 or A853 ROMs I have contain *.odex files. I did download a stock Defy ROM at one point and it did have *.odex files. Maybe Motorola only odexes MotoBlur ROMs? Or am I totally on the wrong path? The disadvantage of odex is that they're difficult to theme? Or is there another disadvantage?

Mioze7Ae said:
I've never quite understood what is meant with deodexing. From what I understand an odexed ROM has *.odex files external to the apks instead of *.dex inside the apks? Is that right? If so, I don't think any of the XT720 ROMs are odexed. None of the XT720, XT701 or A853 ROMs I have contain *.odex files. I did download a stock Defy ROM at one point and it did have *.odex files. Maybe Motorola only odexes MotoBlur ROMs? Or am I totally on the wrong path? The disadvantage of odex is that they're difficult to theme? Or is there another disadvantage?
Click to expand...
Click to collapse
WanHu Deodex already no?
see this
http://www.droidforums.net/forum/xeudoxus/47283-release-xultimate.html

Acer A200 - BRICKED, cannot mount /data /sdcard

I did something stupid. Got an A200 that could not get OTA 4.0.3, so I managed to get it updated manually. However, I then proceeded to try to root it using the "SimpleRoot" scripts on Acertabletforum, and at this point, the thing is bricked. In Recovery, I cannot get anything to mount. /SDCard, /data, etc
Bootloader is Unlocked
I tried with some different Recoveries with slightly different results:
1) Hbwelch CWM v5.5.0.4 (the one that comes with SimpleTool) - All mounting attempts fail
2) nics-TWRP_stable (twrp v 2.1.4) - Seems to be able to mount System and Cache, but not DATA or SDCARD (Internal or External)
3) thor v 5.5.0x (thor2002ro rev1.7) - errors mounting data, sdcard and /mnt/sdcard. Is able to mount system, cache, flexrom and flex.
Any idea how to fix it? I am afraid that if I try to return the tablet where I bought it as it is now, it will get rejected. (even though the damn thing was supposed to be ICS upgradable in the first place, but wasn't... long story)
Thanks
Jerry

I finally got the tablet working again. Was very close to sending it back. Got bits and pieces of info from various other posts on this forum and on acertabletforum. For the sake of anyone else that may find this thread, here are a few things that were wrong, and how to fix them
(I cannot post outside links, so just google the file names when relevant)
1) /SDCard would not mount. Solution - PARTITION the SD card. NOTE: The card worked on a PC, and even on that tablet when Android was fully booted. However it would NOT mount in recovery until I explicitly partitioned it. Doing a FORMAT on the PC does NOT count. I had to partition it within Recovery.
NOTE: This may also be why people are unable to get the update.zip thing working.
2) /Data would not mount - I have no idea how this got screwed up, but the solution was:
* Connect the tablet to the PC in RECOVERY. At this point, ADB should work. If not, check the drivers on the PC - I had to manually specify the Acer ADB Composite driver.
* Open a Command prompt window
* Start ADB shell by typing:
ADB SHELL
* Now execute the following:
mke2fs -j -b 4096 /dev/block/mmcblk0p8
tune2fs -O extents,uninit_bg,dir_index -C 1 /dev/block/mmcblk0p8
e2fsck -fy /dev/block/mmcblk0p8
After this is done your file system on /data will be fixed. (solution posted by spoupard on XDA-Developers.com)
3) Putting it all together:
* Flashed the BOOT partition with Honeycomb 3.2.1_boot.img
* Flashed the RECOVERY partition with nics-TWRP_stable.img
* At this point, I noticed that the Bootloader was once again LOCKED. So, start into FASTBOOT mode and execute the following from the command prompt again:
fastboot oem unlock
* Re-Start in Recovery and select MOUNT and make sure that everything is mounted. If /SDCARD or /DATA refuse to mount, fix that issue first (step 2 above)
* Now I select to INSTALL Acer_AV041_A200_1.037.00_PA_CUS1.zip
Upon reboot, I noticed that it said "Updating Bootloader", then got the Acer screen and locked up. I restarted again into Recovery and again selected the option to install INSTALL Acer_AV041_A200_1.037.00_PA_CUS1.zip and reboot. This time it restarted, indicated that it has a new version of bootloader (previously was 3.1.3) and proceeded to boot up into Android 4.0.3. At that point, I think my neighbors heard me scream YES!, considering I spent 2 days on this
I hope I got all the steps. Most of it is from memory and some notes, since I did not want to experiment and go through this hell again.
Jerry

Great info but you might want to add fixed to the title. For the time being doesn't look like I will be rooting till these issues are sorted out. I am see too many people saying they are bricking with this root method.

FIXED - Acer A200 - BRICKED, cannot mount /data /sdcard
agapecs said:
Great info but you might want to add fixed to the title. For the time being doesn't look like I will be rooting till these issues are sorted out. I am see too many people saying they are bricking with this root method.
Click to expand...
Click to collapse
Didn't see a way to edit the title. As for rooting, note that after all was said and done, I am still not rooted. I just managed to get updated to 4.0.3, which should have been done OTA anyway. I may try again now that I am a bit more confident that I can get it back to working state, but will do a full backup in ADB first. Too much of a pain in the *** to have to reconfigure everything again once the OS is installed.

I cannot get the device to connect to my PC at all, or get the correct driver selected. Any tips?

crazyjimbo said:
I cannot get the device to connect to my PC at all, or get the correct driver selected. Any tips?
Click to expand...
Click to collapse
what state is the tablet in when you try to connect? Fastboot, Recovery, or fully booted up and operating?
What do you see in the device manager when the tablet is connected?

ext3 oder ext4?
1) /SDCard would not mount. Solution - PARTITION the SD card. NOTE: The card worked on a PC, and even on that tablet when Android was fully booted. However it would NOT mount in recovery until I explicitly partitioned it. Doing a FORMAT on the PC does NOT count. I had to partition it within Recovery.
Try to do this with twrp v.2.1.4: do I use ext3 or ext4 for the Partition? And which size needs the ext Partition?
Thanx
teacherHH

teacherhh said:
Try to do this with twrp v.2.1.4: do I use ext3 or ext4 for the Partition? And which size needs the ext Partition?
Click to expand...
Click to collapse
Don't think it matters. I picked the defaults.

mke2fs -j -b 4096 /dev/block/mmcblk0p8
Thanx j_medved for yor reply!
So I did and just faced the next problem: I can conect my Tablet to the PC and can finde it with adb devices and can start the shell with adb shell.
But then when I start: mke2fs -j -b 4096 /dev/block/mmcblk0p8
nothing seems to happen....waited about 30 minutes....
in the next turn I get the reply, that mmcblk0p8 is allready in use....next turn again: nothing seems to happen....
any ideas? .-(
teacherhh

teacherhh,
If I remember correctly, that command should finish pretty quick. You may want to try leaving it for a bit longer, but it seems that you may have something else wrong. I am not that familiar with this area. Haven't dealt with Linux much. Sorry.

Okay. Thanx anyway!
Sent from my GT-I9300 using xda app-developers app

again mke2fs
Once again j_medved...
did it look likes this, wenn you run mke2fs ?
Regards,
teacherhh

teacherhh said:
Once again j_medved...
did it look likes this, wenn you run mke2fs ?
Regards,
teacherhh
Click to expand...
Click to collapse
Don't remember what it was for me (was a month ago ) , but another couple users that ran it had the following:
Code:
~ # mke2fs -j -b 4096 /dev/block/mmcblk0p8
mke2fs -j -b 4096 /dev/block/mmcblk0p8
mke2fs 1.40.8 (13-Mar-2008)
Warning: 256-byte inodes not usable on older systems
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
1831424 inodes, 7311872 blocks
365593 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
224 block groups
32768 blocks per group, 32768 fragments per group
8176 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000
Writing inode tables: 52/224
Couple users that were hosed, were stuck at this point. Did not see any indication of resolution for those users

Driver Problems
Hi Guys,
I've the same problem. I can't wipe the Data, so I've found this instruction. unfortunenately will my PC not found my Tab. I've installed the drivers many times, but it will not work. Can anybody help, how to install? btw. fastboot is working, but not adb.
I'm using an Samsung Netbook with Win 7. THe PC's trying to install drivers, altough they are already installed, but can'T find any drivers.
If you need more informations, just let me know.

@Benninator,
If you look in Windows 7 Device Manager, does the device show up there OK? Or does it show up as unrecognized device, or as some device code with a yellow triangle and exclamation on it? Or not at all?

Yes, their is a yellow triangle. I've tried to install the driver manually, but with no success. In my driverlist were the Acer driver not listed. furthermore I've tried to configure the usb-adb.ini with also no success. I have absolutly no idea what I can do.

In device manager, and does it show up as a200 or unknown device?
Is the device I am recovery at the time?
And also, and which recovery?

Tab is missing recovery and won't boot in to android
FASTBOOT WORKS BUT I GET THIS MESSAGE EVERY TIME I TRY TO FLASH RECOVERY.IMG says unknown partiton 'C:\James\Downloads\recovery.img'
error: cannot determine image filename for 'C:\James\Downloads\recovery.img'
Please help me

jram0421 said:
FASTBOOT WORKS BUT I GET THIS MESSAGE EVERY TIME I TRY TO FLASH RECOVERY.IMG says unknown partiton 'C:\James\Downloads\recovery.img'
error: cannot determine image filename for 'C:\James\Downloads\recovery.img'
Please help me
Click to expand...
Click to collapse
I think you may be mistyping the command. What is the exact command that you are typing in that gets you this error?

cant get adb drivers installed in my pc
adb driver seems not to work at all when i try to boot my tablet on cwd when i boon on fastboot only fastboot recognice my device and when i let my acer a200 try to boot itself it gets stuck on acer screen whit this on top ( bootloader version 0.03.06-ics ) but windows recognice it but fails when installing the mtp usb drivers.
what can i do to get adb working so i can fix my mount issues so i can install my room again ?
hope you can help me tnks

Flashing Now Fails

I've been flashing N7 with no issues as recently as over the weekend. Today I tried to flash a new ROM and it failed. Tried a second, different ROM, same result. Do not know what I did. Any thoughts?

Error log would help greatly.

How do I get/generate the log? Haven't had to do it before.
Thanks,
Paul

The logs= errors displayed on the screen provided by the interface you use to flash the rom (recovery, computer...)

Does this help any?
TWRP V2.4.4.0
Updating partition details
E: Unable to open zip file
Error flashing zop
Updating partition details...

do I need to create a partition? Never get more details despite the tease.
Thanks,

First -
Try and download a different (NEWER) TWRP. Re-flash TWRP. Try again
or
Have you tried completely wiping the device? And pushing a ROM from ADB or using a USB OTG and Memory stick?
I had issues with my nexus becoming VERY unstable. Leading to issues.
I completely, and I mean completely, wiped. To the point that all that device basically had was a recovery, and a bootloader.
I proceeded to flash again, BOOM all fixed up.

Is there a new TWRP?
I did a factory restore after wiping everything thing, if that is what you mean?
It was working as expected last week, don't know what I did to screw it up

Boot recovery try the operation, choose advanced then copy log to sdcard. The paste the log results.
sent via electromagnetic radiation.

ibsk8 said:
Boot recovery try the operation, choose advanced then copy log to sdcard. The paste the log results.
sent via electromagnetic radiation.
Click to expand...
Click to collapse
Did this, and it said it copied but I am unable to locate it. It says 0\media\data But that folder structure doesn't exist, at least according to file expert

Will a complete wipe/restore create a partition?

pmgreen said:
Will a complete wipe/restore create a partition?
Click to expand...
Click to collapse
None of the instructions currently found in this forum alters the partitioning of the N7. Not fastboot & not the custom recovery, either.
You are chasing a red herring I think. That message you see is about the recovery performing a scan to check to see if there is a change in file systems (or partitioning of external devices) ... which might have occurred in preceding (custom recovery) operations, but didn't in this particular case.
pmgreen said:
Does this help any?
TWRP V2.4.4.0
Updating partition details
E: Unable to open zip file
Error flashing zop
Updating partition details...
Click to expand...
Click to collapse
Focus your efforts here; it certainly looks like a first-order problem.

bftb0 said:
None of the instructions currently found in this forum alters the partitioning of the N7. Not fastboot & not the custom recovery, either.
You are chasing a red herring I think. That message you see is about the recovery performing a scan to check to see if there is a change in file systems (or partitioning of external devices) ... which might have occurred in preceding (custom recovery) operations, but didn't in this particular case.
Focus your efforts here; it certainly looks like a first-order problem.
Click to expand...
Click to collapse
Think reinstalling TWRP would help? It was working fine so I'm a bit stumped what changed and why

pmgreen said:
Think reinstalling TWRP would help? It was working fine so I'm a bit stumped what changed and why
Click to expand...
Click to collapse
You can also soft-boot a recovery without actually flashing it, e.g.
Code:
fastboot boot custom-recovery.img
I suppose you could then poke around and see if it is having troubles mounting any of the normal partitions (/data, /system, or /cache). Look in the kernel boot log of the recovery (cat /proc/kmsg or "dmesg") to see if anything looks strange, etc.
There have been a couple of reports from folks who developed problems that looked like eMMC flash media errors - loss of partitions, failure to mount /data, et cetera. At the moment though, your symptoms are very generic and non-specific, as in "it doesn't boot".
I suppose you saw no errors at all reported on the screen during that stock-install-via-fastboot procedure?

bftb0 said:
You can also soft-boot a recovery without actually flashing it, e.g.
Code:
fastboot boot custom-recovery.img
I suppose you could then poke around and see if it is having troubles mounting any of the normal partitions (/data, /system, or /cache). Look in the kernel boot log of the recovery (cat /proc/kmsg or "dmesg") to see if anything looks strange, etc.
There have been a couple of reports from folks who developed problems that looked like eMMC flash media errors - loss of partitions, failure to mount /data, et cetera. At the moment though, your symptoms are very generic and non-specific, as in "it doesn't boot".
I suppose you saw no errors at all reported on the screen during that stock-install-via-fastboot procedure?
Click to expand...
Click to collapse
The only error is that it can't open the zip. I've tried downgraded TWRP, then upgrading back. Tried flashing the existing rom.
Nothing has worked. The N7 is functional, just will not allow me to flash

pmgreen said:
The only error is that it can't open the zip. I've tried downgraded TWRP, then upgrading back. Tried flashing the existing rom.
Nothing has worked. The N7 is functional, just will not allow me to flash
Click to expand...
Click to collapse
Well, if the source material can't be opened, then there is nothing to be flashed.
So maybe it is better to call this a "can't open files" problem instead of a "can't flash" problem.
Are there any special characters in the file name ... or spaces? If so, try renaming the file so the name only contains [a-z], [A-Z], [0-9] plus dash, underscore, and dot.
The other thing that can happen is if you drop a file in /data/media/0 as the root user, it will show up under /sdcard, but can't be read by non-privileged users via the /sdcard/ path. I'm not sure what the exact details are here - much less why this would effect the recovery (as you would expect everything to be running as root there) - but you can detect this problem by using a terminal emulator, and looking for differences in ownership or file permission:
Code:
$ su
# cd /data/media/0
# ls -ld *
use chown and chmod as appropriate to fix files as needed

bftb0 said:
Well, if the source material can't be opened, then there is nothing to be flashed.
So maybe it is better to call this a "can't open files" problem instead of a "can't flash" problem.
Are there any special characters in the file name ... or spaces? If so, try renaming the file so the name only contains [a-z], [A-Z], [0-9] plus dash, underscore, and dot.
The other thing that can happen is if you drop a file in /data/media/0 as the root user, it will show up under /sdcard, but can't be read by non-privileged users via the /sdcard/ path. I'm not sure what the exact details are here - much less why this would effect the recovery (as you would expect everything to be running as root there) - but you can detect this problem by using a terminal emulator, and looking for differences in ownership or file permission:
Code:
$ such
# cd /data/media/0
# ls -ld *
use chown and chmod as appropriate to fix files as needed
Click to expand...
Click to collapse
Thanks bftb, you are correct it's a can't open zip. No error than fail and it can't open the zip. It says updating partition but nothing changes
The file names are from the developers, once of which I recently successfully flashed. Tried coping the log to the SD card, but unable to find /data/media/0. Do I need to recreate a partition?

(FYI there was an auto-correct typo in my prior post - "su" not "such". Derp)
pmgreen said:
Do I need to recreate a partition?
Click to expand...
Click to collapse
No. (There is no way to do that with the tools we have anyway)
Unless what you mean by "recreate" is rebuild/reinitialize a filesystem in a partition - that's a possibility.
You need to try and figure out why you can't read files.
As a workaround, you can put files on a USB key (FAT formatted, not NTFS) and using TWRP access them by putting the USB key on the other end of a OTG cable.
Your posts are a bit vague - I can't even tell if you have tried other ROM files, whether you checked them to see if they are the correct size/checksum, etc.

pmgreen said:
Tried coping the log to the SD card, but ...
Click to expand...
Click to collapse
At this point, your best approach is still to follow the initial advice of 'ibsk8'. Look in the log file for any further details about errors that occurred.
The logs are typically in /cache/recovery/ or (while the custom recovery is running) in /tmp
Use "adb pull" to get the log file to your PC and have a look at it. If you can't find anything obvious in there, then cut-n-paste the file to http://pastebin.com and provide the link to us.

bftb0 said:
At this point, your best approach is still to follow the initial advice of 'ibsk8'. Look in the log file for any further details about errors that occurred.
The logs are typically in /cache/recovery/ or (while the custom recovery is running) in /tmp
Use "adb pull" to get the log file to your PC and have a look at it. If you can't find anything obvious in there, then cut-n-paste the file to http://pastebin.com and provide the link to us.
Click to expand...
Click to collapse
I am not familiar using ADB pull. Tried using a root file manager to access the log but don't see.
Greatly appreciate your help, let me know what other info I should paste.
Thanks,

[Q] Nexus 7 reboots constantly every 2 mins or so

My stock/unlocked nexus 7 2012 updated to android 4.4.0 KRT16S after being idle about 12 hours, i picked it up and just a couple minutes into browsing it started rebooting on it's own.
The weird things don't end here, since after every reboot it goes back to the exact same state it was before: if it were done updating an app, or I enabled ADB or turned off the wifi or whatever, and then suddenly reboots, all these things would go to the state they were before (WIFI on, ADB off, changes in apks, even files sideloaded).
I tried to clear the cache through recovery, but it didn't work, I also tried sideloading the ota update to 4.4.2, but it won't find the file in the root folder, as it just disappears. When i went to the nexus tool kit i was not able to unlock the bootloader, or to factory reset( not even from the device itself) or do anything to get out of this situation.
The only thing i can do for now is turn the tablet off and do nothing with it.
Has anyone an idea i can try?

Can really nobody help?
Sent from my Nexus 4 using Tapatalk

You have to create a hypothesis and then perform an experiment that tests that hypothesis. (There's a ferociously complicated processor and millions of lines of code involved; nobody is going to put their finger on the exact cause of a vaguely described problem from across the internet)
For instance:
Hypothesis A: There is a significant hardware problem which causes spontaneous reboots, and it doesn't matter what software is running for the fault to appear.
Test A: Plug the tablet in to the charger and boot it in to the recovery. Let it sit a while. Does it spontaneously reboot?
Hypotheses B: There is a software problem with the ROM I am using that causes sponateous reboots.
Test B: Back up your data, wipe the tablet, install a brand new ROM, and use it for a while. Does it still reboot?
Hypotheses C: The userdata partition got corrupted somehow which causes it to remount automatically in read-only mode. (Changes are not persistent and the ROM reboots all the time as a result)
Test C: Similar to test B, but destroy the userdata partition and reformat it using fastboot. Put a new ROM on a USB memory stick and use the OTG mounting features of the recovery to deliver a new ROM to the tablet. Is it still rebooting?
See how that goes?
Not trying to be mean or anything, but the lack of responses are probably due to several things; the leading candidate of which is that you mentioned using a toolkit - a sure sign of lack of understanding of how most of this stuff actually works.
It's OK to not understand everything - all of us are learning all the time, and everybody has to start at the beginning. Toolkits surely make some jobs faster - at the cost of hiding the details of how things actually work - and making their users helpless when something goes wrong. Try to avoid them if you can.
good luck

Thank you for the long and elaborate response! I will be the first to admit that I have limited knowledge about these things but the main reason that I used the toolkit was that everything else I tried failed. Of course, as you said there are plenty of things I could have tried, and I tried to explain everything I did to make the job easier for someone to help me out, surely not to let my questions unanswered!
So thank you for the answer, and i'll try everything as soon as possible and keep it posted up
Sent from my Nexus 4 using Tapatalk

Ok after a series of tests, and by the looks of it I think that the right hypothesis is number C, every time it boots back up it loses every change in the system. In the few minutes the tablet stays on, I managed to download the ota update to 4.4.2 but once it rebooted itself into recovery it said no command, hence the files it downloaded were erased and this was also the reason why I couldn't install the update via recovery myself, every time I put the update into the root folder and rebooted into recovery, it told me no command available. And the files would just disappear. The only option i'm left with is to destroy the user data partition using fastboot ( a method i'm not familiar with, but that i'm willing to try) I'll look for a guide, or if you be so kind to recommend one i'd be extremely thankful!
Sent from my Nexus 4 using Tapatalk

Googsx said:
Ok after a series of tests, and by the looks of it I think that the right hypothesis is number C, every time it boots back up it loses every change in the system. In the few minutes the tablet stays on, I managed to download the ota update to 4.4.2 but once it rebooted itself into recovery it said no command, hence the files it downloaded were erased and this was also the reason why I couldn't install the update via recovery myself, every time I put the update into the root folder and rebooted into recovery, it told me no command available. And the files would just disappear. The only option i'm left with is to destroy the user data partition using fastboot ( a method i'm not familiar with, but that i'm willing to try) I'll look for a guide, or if you be so kind to recommend one i'd be extremely thankful!
Sent from my Nexus 4 using Tapatalk
Click to expand...
Click to collapse
Normally user-level changes would be recorded in the /data partition, so if it got corrupted some way AND the OS mounts that filesystem with a errors=remount-ro then that would explain lack of persistence.
However, not every OS or recovery boot uses the same mount options. I'm looking at a CM boot right now and I don't see that
Code:
/dev/block/platform/sdhci-tegra.3/by-name/UDA /data ext4 rw,seclabel,nosuid,nodev,noatime,errors=panic,user_xattr,acl,barrier=1,nomblk_io_submit,data=ordered 0 0
But anyway, if you are going to reformat your "userdata" partition, try and rescue everything off of the tablet.
Is the recovery boot stable? If so, you might want to use "adb pull" to recursively pull everything off of the /sdcard. If it doesn't reboot every couple minutes, that could be of some use for backing up the /sdcard. Otherwise it will be impossible if your ROM reboots every 2 minutes.
Yes you can use fastboot to format the userdata partition. You can also use "mke2fs" as a shell command (that is, with adb) when the recovery is running.
TWRP 2.6.3.1
Code:
mke2fs
Usage: mke2fs [-c|-l filename] [-b block-size] [-f fragment-size]
[-i bytes-per-inode] [-I inode-size] [-J journal-options]
[-G meta group size] [-N number-of-inodes]
[-m reserved-blocks-percentage] [-o creator-os]
[-g blocks-per-group] [-L volume-label] [-M last-mounted-directory]
[-O feature[,...]] [-r fs-revision] [-E extended-option[,...]]
[-T fs-type] [-U UUID] [-jnqvFKSV] device [blocks-count]
.
If you use an ext2/3/4 filesystem formatter (e.g. mke2fs) running under the recovery, you need to be very very careful about specifying the exact partition name (e.g. /dev/block/mmcblk0p9 for GROUPER - data might be at a different partition number on a Tilapia device).
You can check by doing a
Code:
adb shell ls -l /dev/block/platform/sdhci-tegra.3/by-name/*
the userdata partition is "UDA".
BTW, before you go nuking your data partition, it might be useful to check to see if it is actually corrupted. For instance, with TWRP you can unmount all partitions, and then check using the program "e2fsck" :
Code:
C:\> adb shell
# e2fsck -f -n /dev/block/mmcblk0p9
the above command will perform a check (p9 = grouper /data partition) without attempting to make any repairs. You'll know if there are any problems: you will get page after page of error messages. If the filesytem is free of errors, you will only see 8-10 summary lines.

bftb0 said:
Normally user-level changes would be recorded in the /data partition, so if it got corrupted some way AND the OS mounts that filesystem with a errors=remount-ro then that would explain lack of persistence.
However, not every OS or recovery boot uses the same mount options. I'm looking at a CM boot right now and I don't see that
Code:
/dev/block/platform/sdhci-tegra.3/by-name/UDA /data ext4 rw,seclabel,nosuid,nodev,noatime,errors=panic,user_xattr,acl,barrier=1,nomblk_io_submit,data=ordered 0 0
But anyway, if you are going to reformat your "userdata" partition, try and rescue everything off of the tablet.
Is the recovery boot stable? If so, you might want to use "adb pull" to recursively pull everything off of the /sdcard. If it doesn't reboot every couple minutes, that could be of some use for backing up the /sdcard. Otherwise it will be impossible if your ROM reboots every 2 minutes.
Yes you can use fastboot to format the userdata partition. You can also use "mke2fs" as a shell command (that is, with adb) when the recovery is running.
TWRP 2.6.3.1
Code:
mke2fs
Usage: mke2fs [-c|-l filename] [-b block-size] [-f fragment-size]
[-i bytes-per-inode] [-I inode-size] [-J journal-options]
[-G meta group size] [-N number-of-inodes]
[-m reserved-blocks-percentage] [-o creator-os]
[-g blocks-per-group] [-L volume-label] [-M last-mounted-directory]
[-O feature[,...]] [-r fs-revision] [-E extended-option[,...]]
[-T fs-type] [-U UUID] [-jnqvFKSV] device [blocks-count]
.
If you use an ext2/3/4 filesystem formatter (e.g. mke2fs) running under the recovery, you need to be very very careful about specifying the exact partition name (e.g. /dev/block/mmcblk0p9 for GROUPER - data might be at a different partition number on a Tilapia device).
You can check by doing a
Code:
adb shell ls -l /dev/block/platform/sdhci-tegra.3/by-name/*
the userdata partition is "UDA".
BTW, before you go nuking your data partition, it might be useful to check to see if it is actually corrupted. For instance, with TWRP you can unmount all partitions, and then check using the program "e2fsck" :
Code:
C:\> adb shell
# e2fsck -f -n /dev/block/mmcblk0p9
the above command will perform a check (p9 = grouper /data partition) without attempting to make any repairs. You'll know if there are any problems: you will get page after page of error messages. If the filesytem is free of errors, you will only see 8-10 summary lines.
Click to expand...
Click to collapse
Ok before I start with all this i have to say a few things! The tablet now started rebooting even in recovery! and also since the first time it started rebooting I tried enabling usb debugging, but as I explained earlier after every reboot every change disappears, meaning usb debugging is not enabled when i enter the recovery! Will I be able to do anything at all with fastboot if the usb debugging is not enabled? If not do I have any other option?

Googsx said:
Ok before I start with all this i have to say a few things! The tablet now started rebooting even in recovery! and also since the first time it started rebooting I tried enabling usb debugging, but as I explained earlier after every reboot every change disappears, meaning usb debugging is not enabled when i enter the recovery! Will I be able to do anything at all with fastboot if the usb debugging is not enabled? If not do I have any other option?
Click to expand...
Click to collapse
The settings you (try to) apply when the ROM is running (eg the USB debugging toggle) do not affect the recovery. The entire point of a recovery is to have a standalone boot that doesn't depend on other partitions.
Having said that, the use of a "pseudo" SD card that is actually part of the userdata filesystem sometimes does cause problems for the recovery - it tries to mount /data to get you access to ROM files, nandroid backups, etc. I recall getting my N7 into a condition where TWRP's touch interface wouldn't come up because of problems with the userdata partition. But, adb was still available as was fastboot (in the bootloader mode). Also, I was not having spontaneous reboots.
The fact that you are observing spontaneous reboots in the recovery indicates that you might have Hypothesis A going on - flaky hardware. At a minimum however, it means you will not be able to run any long duration backups... for instance, trying to make a rescue backup of your SD card.
You could try and do
Code:
fastboot erase userdata
fastboot format userdata
with the tablet in bootloader mode. Obviously this step will destroy all of your data.
If your tablet is still spontaneously rebooting after that (in the recovery) then your only option will be to return it for repair (motherboard replacement).