Hi folks. I have tried the Odin process three times to try to get CWM functioning on my I/O tab with no luck.
The actual Odin process seems to work fine; however, when I reboot the tab to enter recovery mode; I never get the recovery option. I only have the USB symbol and the downloading option. Also, in the upper left corner, I have:
Fastboot USB download protocol
bootloader version unknown
baseband version %s
serial number:
lock state unlocked
What am i missing? Can the I/O tab use CWM?
Thanks!!
I had the same thing, but when I am trying to root the device it just lock on boot screen. I am not a dummy but something is wrong where several users have diffrent symptoms. I would wait until further development is done. This is still a little shaky.
Odin CWM doesn't work for some reasons ..
Use this post to get rooted
http://forum.xda-developers.com/showpost.php?p=15735928&postcount=2
Follow the instructions carefully !!
Download CWM and do an Install on CWM (it will install 4.0.0.4)
copy the required files to the root directory /sdcard/ (main directory if you don't know)
-Get the roms from HERE
-Get the su_busybox_misc-sam_tab_10.1-051511 HERE
Flash in the ROM 1st .. the apply the SU update (in RECOVERYMOD BEFORE you reboot)
Data / wipe
THEN REBOOT
I missed that 2nd update zip .. and trust me its a pain to get it rooted after that ..
The same procedure will not work again once you're on TW3.1 rom .. you will need an image of the system files and NVflash now..
BTW if you can do NVflash .. then I can send you the image files for 3.1TW rooted ..
fgarcia25 said:
I had the same thing, but when I am trying to root the device it just lock on boot screen. I am not a dummy but something is wrong where several users have diffrent symptoms. I would wait until further development is done. This is still a little shaky.
Click to expand...
Click to collapse
Ha .. I have 3 IO to play with (from friends)..
1st one is rooted out of the box ..
2nd one cannot communicate on FASTBOOT
3rd one does everything nicely (thats the one I had the image extracted with NVFlash)
I'll say it nicely before someone comes to say it rudely, this probably belongs in a general section rather than the development section (that is, until you develop a method to get around the restriction you've found )
Workaround method
http://forum.xda-developers.com/showpost.php?p=16196597&postcount=3
Plus I have the images to go with in case you brick yours
bill.allrobots.org said:
I'll say it nicely before someone comes to say it rudely, this probably belongs in a general section rather than the development section (that is, until you develop a method to get around the restriction you've found )
Click to expand...
Click to collapse
If you have fastboot working, then rooting is as simply as 'fastboot boot [cwm recovery filename].img'
I spent a long time getting fastboot to work, but the only fix was to finally download PDANET software to my PC and install it while it was connected to my tab. After that I got fastboot working.
Fastboot made the rooting process 100% easier. You can root any stock ROM with it and not have to reflash to 3.0.1.
Questions or Problems Should Not Be Posted in the Development Forum
Please Post in the Correct Forums and Read THIS
Moving to General
I had the same problem with my I/O. I finally got a recovery option. What I did was flash the Euro version of TW located in the development section (which is buggy as ****).. After that I Installed CWM and flashed pershoot's root tools. Then I flashed the latest TW Rom. Everything is running smoothly, despite the samsung apps fc. Be weary of the disclaimers located on all the sections I have suggested. All of these steps are at your own risk...
Odin worked on my I/O tab after i put TW on it. I had to boot the tab into CWM via fastboot from a mac
Hi. To introduce myself, I came from iPhone universe and I'm new to Android system.
I'm used to linux systems and I'm also a developer...
Here, I just want some answer about "hacking" actions on my fresh Nexus 7 device because I red a lot of articles but I still don't understand all this stuff..
Correct me if I'm wrong but in order to install a custom ROM (which it's my goal), these are the steps:
1. Unlock bootloader (--> wipe all datas)
2. Root the device (manually with "adb" or automatically with a toolkit : "nexus 7 toolkit" or "wugs")
3. Install custom recovery (TWRP or CWM)
4. Flash a kernel
### My Questions ####
a) Coming from Linux world I can't get with the wiping of data while unlocking the bootloader. A bootloader is a simple portion of code which locate the kernel for booting the system. So, in my head, it just can't wipe or deal with user's data!!!
b) Rooting the device. Huuum, that's the part that I fully understand. I will probably use a toolkit because I'm on Mac and I don't want to download all the SDK packages, drivers, ect.. only to type 5 commands. Althought, I've red all the adb and fastboot commands
c) The purpose of the custom recovery is to replace the bootloader by an advanced one which can deal with flashing partitions and caches, backuping, exact?!
d) Flashing the kernel. LOL, it sounds like "compiling the kernel" which is the noob's favorite expression Personally, I only do one compilation of my kernel for 10 years.. So do I really need to "flash" the kernel?
e) I red that I have to choose a specific kernel to work with the custom ROM. WTF?! And I don't speak about overcloaking or kernel governors/schedulers.... I'm lost
==> All I wan't to do is trying some custom ROMs like CM, Paranoid, Smooth.... to find which fits the best for me
Thank you for your help and sorry for this beginner post but I really need advices and to summary into a single place.
xozeus said:
Hi.
Click to expand...
Click to collapse
Hi
xozeus said:
1. Unlock bootloader (--> wipe all datas)
2. Root the device (manually with "adb" or automatically with a toolkit : "nexus 7 toolkit" or "wugs")
3. Install custom recovery (TWRP or CWM)
4. Flash a kernel
Click to expand...
Click to collapse
#3.5 Make a full Nandroid Backup with the custom recovery. Get a copy of it off the device, too. You will thank me profusely for this later - mark my words.
#4 Should be "flash a ROM", not "flash a kernel" : the boot partition (a binary blob containing a Linux kernel plus it's initial ramdisk) plus 100% of the files that live in the /system mount point). A custom kernel is optional as 100% of ROM devs provide a default boot image, or let you choose one as part of their installation.
xozeus said:
a) Coming from Linux world I can't get with the wiping of data while unlocking the bootloader. A bootloader is a simple portion of code which locate the kernel for booting the system. So, in my head, it just can't wipe or deal with user's data!!!
Click to expand...
Click to collapse
That is a security feature if the tab is stolen - a thief can't get your creds. By unlocking the boot loader you are making things easier for a bright thief. Of course, not using a screen lock, or having a custom recovery on the tab gives a thief the same opportunities.
xozeus said:
b) Rooting the device. Huuum, that's the part that I fully understand. I will probably use a toolkit because I'm on Mac and I don't want to download all the SDK packages, drivers, ect.. only to type 5 commands. Althought, I've red all the adb and fastboot commands
Click to expand...
Click to collapse
Do as you will. Google makes things more difficult than it need be; but all you really need on a Mac is the adb and fastboot executables plus supporting link libraries (I recall using both on a live Linux CD boot with a thumb drive - I think only one additional shared lib was needed - three files total.)
xozeus said:
c) The purpose of the custom recovery is to replace the bootloader by an advanced one which can deal with flashing partitions and caches, backuping, exact?!
Click to expand...
Click to collapse
No concerning the boot loader - Yes sorta for the rest of it. Bootloader is analogous to BIOS - it is not the same as the "boot partition". Just as with a BIOS, you should probably avoid fooling with it. The bootloader and recovery boot are completely separate. There are two Linux kernel bootable partitions: boot and recovery. These partitions both hold a Linux kernel and a ramdisk. In fact, the kernel is usually identical in both - the only difference between them is that the recovery ramdisk starts up *nothing* which needs either /system or /data to be mounted. This means that it has a small toolset built to live in the ramdisk AND can perform offline file system maintenance on /data and /system - including destroying them completely and rebuilding them. Contrast that to booting the regular "boot image" that will start up regular ole Android - all that Dalvik code needs both /system and /data to be mounted, thus making it impossible to do aggressive filesystem updates (e.g. OTAs) without wedging the OS
Think of the recovery as being similar to "single user mode" in Linux. The only difference is that completely separate kernels and ramdisks are used, and the don't live inside file systems... they are stored in raw partitions (boot and recovery)
xozeus said:
d) Flashing the kernel. LOL, it sounds like "compiling the kernel" which is the noob's favorite expression Personally, I only do one compilation of my kernel for 10 years.. So do I really need to "flash" the kernel?
Click to expand...
Click to collapse
By convention, ROMs come with a boot image (Note: NOT bootloader) so flashing a kernel is always optional. When it is done though, it needs to be done after flashing a ROM bundle (see previous sentence for the why of it)
xozeus said:
e) I red that I have to choose a specific kernel to work with the custom ROM. WTF?! And I don't speak about overcloaking or kernel governors/schedulers.... I'm lost
Click to expand...
Click to collapse
Not true. However, there probably are ROM+kernel combinations that don't mix and match well. Some kernel devs ship an entire boot image (kernel + ramdisk), and some of them ship kernel only along with an installer that patches the prior existing boot image. Suffice it to say you should expect some bumps in the road.
They will only be bumps if you have backups, and big headaches if you don't.
Thank you so much, I forgot to reply and thank you because you made me read a lot lol muchas gracias !
Sent from my GT-I9195 using Tapatalk
Hi guys,
1. What is the advantage/disadvantage of flashing a custom kernel?
2. I recently flashed Cyanogenmod. It automatically installs a custom kernel right?
3. Using the Nexus 7 toolkit I reverted my N7 to stock recovery (from CWM) How should I make sure that it's been reverted to the latest stock version?
4. What does N7's stock factory image contain? (Stock ROM + Stock recovery + Stock kernel?) (found here: https://developers.google.com/android/nexus/images)
5. Is this correct? You can install a custom ROM without changing the kernel but in order to have more customization you have to flash a different kernel than the stock one.
6. Is this the correct order? Unlocking bootloader>rooting>Flashing custom recovery>Flashing custom kernel>Flashing custom ROM>...?
7. Difference between unlocking bootloader and rooting.
8. How to find out N7's latest stock kernel version.
Many thanx
Sent from my Nexus 7 using Tapatalk 4 Beta
valapsp said:
1. What is the advantage/disadvantage of flashing a custom kernel?
Click to expand...
Click to collapse
Same as those for a stock kernel. That is to say, every kernel has advantages and disadvantages. Some trade performance for battery life, others do the reverse. Some are more feature-heavy and potentially more unstable, others are feature-light but designed to be rock solid. With custom kernels on a Nexus device, you avoid one of the biggest dangers of custom kernels (instability due to lack of kernel source for developers to base their work on), but you still need to be careful. You don't necessarily know how proficient the author of a given kernel is, and the wrong one can make your device unusable/kill it.
valapsp said:
2. I recently flashed Cyanogenmod. It automatically installs a custom kernel right?
Click to expand...
Click to collapse
I believe it does. I don't remember which one though, since I don't use CM.
valapsp said:
3. Using the Nexus 7 toolkit I reverted my N7 to stock recovery (from CWM) How should I make sure that it's been reverted to the latest stock version?
Click to expand...
Click to collapse
You need to be more specific-- the latest stock ROM, or the latest stock recovery? If you're wondering about the ROM, you can check in Settings > About tablet > Status. When it comes to determining recovery version, I'm not so sure.
valapsp said:
4. What does N7's stock factory image contain? (Stock ROM + Stock recovery + Stock kernel?) (found here: https://developers.google.com/android/nexus/images)
Click to expand...
Click to collapse
I believe it contains stock ROM and kernel.
valapsp said:
5. Is this correct? You can install a custom ROM without changing the kernel but in order to have more customization you have to flash a different kernel than the stock one.
Click to expand...
Click to collapse
Generally correct. There's a subset of features that are kernel-dependent, not ROM dependent, so you should think of it as ROM customizations vs. kernel customizations. Some examples of the former include PIE menus and Paranoid Android's Halo feature. Examples of the latter might include tap2wake (double tap on a powered-off screen to turn it on), NTFS drive support for OTG, and so on.
valapsp said:
6. Is this the correct order? Unlocking bootloader>rooting>Flashing custom recovery>Flashing custom kernel>Flashing custom ROM>...?
Click to expand...
Click to collapse
Yes and no? It's one way of going about it, save for the last two things, which should be reversed. Since some ROMs include custom kernels, flashing a kernel and then a ROM runs the risk of having your kernel choice overwritten.
If all you need to do is flash a different ROM, you can go straight form unlocking the bootloader to flashing a recovery. You can also flash ROMs and kernels independently, so long as whatever kernel/ROM you're running initially doesn't have known incompatibilities with your new ROM/kernel.
valapsp said:
7. Difference between unlocking bootloader and rooting.
Click to expand...
Click to collapse
Unlocking your bootloader is like getting the key to a house. Rooting is getting permission from the landlord to do whatever the heck you want to the house. A locked bootloader means that the device is checking to ensure no unauthorized code is running at boot time, which prevents custom recoveries from being installed. Rooting only really matters when the device is booted up.
valapsp said:
8. How to find out N7's latest stock kernel version.
Click to expand...
Click to collapse
Google. Sorry, can't help you with this one.
That was a great answer @Rirere
Rirere said:
Same as those for a stock kernel. That is to say, every kernel has advantages and disadvantages. Some trade performance for battery life, others do the reverse. Some are more feature-heavy and potentially more unstable, others are feature-light but designed to be rock solid. With custom kernels on a Nexus device, you avoid one of the biggest dangers of custom kernels (instability due to lack of kernel source for developers to base their work on), but you still need to be careful. You don't necessarily know how proficient the author of a given kernel is, and the wrong one can make your device unusable/kill it.
I believe it does. I don't remember which one though, since I don't use CM.
You need to be more specific-- the latest stock ROM, or the latest stock recovery? If you're wondering about the ROM, you can check in Settings > About tablet > Status. When it comes to determining recovery version, I'm not so sure.
I believe it contains stock ROM and kernel.
Generally correct. There's a subset of features that are kernel-dependent, not ROM dependent, so you should think of it as ROM customizations vs. kernel customizations. Some examples of the former include PIE menus and Paranoid Android's Halo feature. Examples of the latter might include tap2wake (double tap on a powered-off screen to turn it on), NTFS drive support for OTG, and so on.
Yes and no? It's one way of going about it, save for the last two things, which should be reversed. Since some ROMs include custom kernels, flashing a kernel and then a ROM runs the risk of having your kernel choice overwritten.
If all you need to do is flash a different ROM, you can go straight form unlocking the bootloader to flashing a recovery. You can also flash ROMs and kernels independently, so long as whatever kernel/ROM you're running initially doesn't have known incompatibilities with your new ROM/kernel.
Unlocking your bootloader is like getting the key to a house. Rooting is getting permission from the landlord to do whatever the heck you want to the house. A locked bootloader means that the device is checking to ensure no unauthorized code is running at boot time, which prevents custom recoveries from being installed. Rooting only really matters when the device is booted up.
Google. Sorry, can't help you with this one.
Click to expand...
Click to collapse
First of all many many thanx to you because of your help. Yes I meant stock RECOVERY in question 3 also the way you explained question #7 is awesome.
Now I'm running stock ROM on CWM recovery and Franco kernel. My question is that will I be able to upgrade to Android 4.3 with this recovery and kernel? Or I have to flash the stock kernel or stock recovery or both?
Also how can I extract the stock kernel from the factory stock image file?
Thanx again.
valapsp said:
First of all many many thanx to you because of your help. Yes I meant stock RECOVERY in question 3 also the way you explained question #7 is awesome.
Now I'm running stock ROM on CWM recovery and Franco kernel. My question is that will I be able to upgrade to Android 4.3 with this recovery and kernel? Or I have to flash the stock kernel or stock recovery or both?
Also how can I extract the stock kernel from the factory stock image file?
Thanx again.
Click to expand...
Click to collapse
The OTA updates are normally only applied to the rom/system, so in theory you should be able to just run the OTA update with the stock rom, the worst that would mainly happen is losing rooting because the system partition gets replaced with a fresh install of the newest operating system (but your /data retains your settings and user data).
I use TWRP recovery instead of CWM, and TWRP when you're bout to exit it will detect if your system has Supersu or not and will offer to install it for you (from there once you boot into the system you can use it to install the su binary for you thus re-rooting).
In the end it's a personal choice. With custom roms like I'm using, there's no real "OTA" update (just a notice that the rom creators use to notify you of new versions which are downloaded to the device, and you just reboot into recovery to flash them). Custom roms typically get updated a few days to a few weeks after google updates if they're AOSP based.
The stock kernel would normally be the boot image, I don't know how you would do it with clockwork mod, but in TWRP you can simply make a backup of the boot partition to retain the original stock kernel. (It will of course only work on AOSP-based roms if you choose to just flash the stock kernel, but the ones that are made for the rom, or custom kernels tend to offer optimizations over the original stock one).
Thanks, I meant extracting the stock kernel from factory image file found here:
https://developers.google.com/android/nexus/images
By the way I don't have the stock kernel anymore to back it up.
Sent from my Nexus 7 using Tapatalk 4 Beta
valapsp said:
Thanks, I meant extracting the stock kernel from factory image file found here:
https://developers.google.com/android/nexus/images
By the way I don't have the stock kernel anymore to back it up.
Sent from my Nexus 7 using Tapatalk 4 Beta
Click to expand...
Click to collapse
Ahh I see, well if your's is the Wifi-only version then would be something like this https://developers.google.com/android/nexus/images#nakasijdq39
The firmwares are basically gzipped tarballs (in a linux system tar zxvf would normally unpack em, otherwise 7zip for windows does a good job of unpacking it into a folder).
Alternatively you can just download the kernel itself (Post #3) http://forum.xda-developers.com/showthread.php?t=2151154
Edit: Yes if you un-gzip/untar the original firmware, then unpack image-nakasi-jdq39.zip inside of that, there will be a boot.img that's where the kernel lives. The boot.img can be flashed via fastboot to the boot partition (I'd advise reading up on this first before actually doing it). Though like linked above, there are some recovery-flashible versions of the stock kernel you can use instead.
kbeezie said:
Ahh I see, well if your's is the Wifi-only version then would be something like this https://developers.google.com/android/nexus/images#nakasijdq39
The firmwares are basically gzipped tarballs (in a linux system tar zxvf would normally unpack em, otherwise 7zip for windows does a good job of unpacking it into a folder).
Alternatively you can just download the kernel itself (Post #3) http://forum.xda-developers.com/showthread.php?t=2151154
Edit: Yes if you un-gzip/untar the original firmware, then unpack image-nakasi-jdq39.zip inside of that, there will be a boot.img that's where the kernel lives. The boot.img can be flashed via fastboot to the boot partition (I'd advise reading up on this first before actually doing it). Though like linked above, there are some recovery-flashible versions of the stock kernel you can use instead.
Click to expand...
Click to collapse
thanks, I actually did unzip the stock firmware seconds ago and was posting the results then I saw your edit.
Just there are some confusions here: what is that userdata.img? also what is bootloader-grouper-4.18.img
valapsp said:
thanks, I actually did unzip the stock firmware seconds ago and was posting the results then I saw your edit.
Just there are some confusions here: what is that userdata.img? also what is bootloader-grouper-4.18.img
Click to expand...
Click to collapse
bootloader img would be the original stock bootloader for the Nexus 7, chances are you never replaced it, you only unlocked it. There's usually no reason to replace the bootloader with a custom one since all you need to do is unlock it.
userdata.img would be the /data partition. The firmware download basically has a image for all of the partition in the original out-of-the-box stock state. Technically you don't even to flash it, as long as you wiped /data before rebooting (since that would be the same as a clean install if you instead flashed the system and boot partition).
Edit: If I were messing with it to get back stock rom (but not messing with recovery, cuz custom recovery is still handy to have), I would only flash the boot.img and system.img , then log into Recovery and wipe data (ie: factory reset which wipes cache and /data but doesn't touch /data/media), Then I would be able to reboot into a clean stock install of the rom.
(from there I could just make a backup from recovery so I wouldn't have to do a fastboot flash again).
kbeezie said:
The OTA updates are normally only applied to the rom/system, so in theory you should be able to just run the OTA update with the stock rom, the worst that would mainly happen is losing rooting because the system partition gets replaced with a fresh install of the newest operating system (but your /data retains your settings and user data).
I use TWRP recovery instead of CWM, and TWRP when you're bout to exit it will detect if your system has Supersu or not and will offer to install it for you (from there once you boot into the system you can use it to install the su binary for you thus re-rooting).
In the end it's a personal choice. With custom roms like I'm using, there's no real "OTA" update (just a notice that the rom creators use to notify you of new versions which are downloaded to the device, and you just reboot into recovery to flash them). Custom roms typically get updated a few days to a few weeks after google updates if they're AOSP based.
The stock kernel would normally be the boot image, I don't know how you would do it with clockwork mod, but in TWRP you can simply make a backup of the boot partition to retain the original stock kernel. (It will of course only work on AOSP-based roms if you choose to just flash the stock kernel, but the ones that are made for the rom, or custom kernels tend to offer optimizations over the original stock one).
Click to expand...
Click to collapse
Unfortunately, how many times does should matter? Theoretically, you should be able to do OTAs while rooted by downloading the ZIP and flashing in recovery, but if you've made changes to /system (uninstalling a system app, or adding a helper), you might get the stupid script_assert error. Of course, you could just push the whole /system back to your device...although that can be just as annoying.
I wish there were away to turn off the script_asserts safely, but they do exist for a reason.
@valapsp
Small but important clarification.
valapsp said:
5. Is this correct? You can install a custom ROM without changing the kernel but in order to have more customization you have to flash a different kernel than the stock one.
Click to expand...
Click to collapse
Essentially 100% of custom ROMs install a kernel. (Actually, a kernel plus a ramdisk packaged together as a single ("bootable image") file, typically named "boot.img".) So your preexisting boot image containing the kernel is always overwritten during a ROM installation. See next answer.
valapsp said:
6. Is this the correct order? Unlocking bootloader>rooting>Flashing custom recovery>Flashing custom kernel>Flashing custom ROM>...?
Click to expand...
Click to collapse
Almost, but not quite. If you want to use a different kernel than what ships with a given ROM, you flash it after you have installed the ROM, not beforehand. See prior answer.
One more thing. Since you are new to this stuff, I'll make a suggestion:
Learn how to create and restore full Nandroid backups (using the custom recovery) immediately. And get in the habit of copying them off your tablet to your PC. You will thank me later for this advice.
have fun
Rirere said:
Unfortunately, how many times does should matter? Theoretically, you should be able to do OTAs while rooted by downloading the ZIP and flashing in recovery, but if you've made changes to /system (uninstalling a system app, or adding a helper), you might get the stupid script_assert error. Of course, you could just push the whole /system back to your device...although that can be just as annoying.
I wish there were away to turn off the script_asserts safely, but they do exist for a reason.
Click to expand...
Click to collapse
Hi, Rirere...
This is my understanding as well... (sort of! - I've always been a bit hazy on this topic).
My take on it is this...
The OTA would only fail, if it found files in /system that SHOULD BE THERE, but have been removed, modified, or replaced by the user (or via some app run by the user).
Logically (one would think), the OTA can't check for files THAT SHOULDN'T BE THERE (How would it know what to look for?) but have been ADDED by the user... like the su binary that confers root.
So, an OTA on pure ROOTED (but in all other regards, unadulterated) stock you would expect to succeed... you'd just lose root (and from what I've read elsewhere, your Custom Recovery). Both of which are trivial to recover.
Is my understanding correct... or have I missed something?
Rgrds,
Ged.
GedBlake said:
Hi, Rirere...
This is my understanding as well... (sort of! - I've always been a bit hazy on this topic).
My take on it is this...
The OTA would only fail, if it found files in /system that SHOULD BE THERE, but have been removed, modified, or replaced by the user (or via some app run by the user).
Logically (one would think), the OTA can't check for files THAT SHOULDN'T BE THERE (How would it know what to look for?) but have been ADDED by the user... like the su binary that confers root.
So, an OTA on pure ROOTED (but in all other regards, unadulterated) stock you would expect to succeed... you'd just lose root (and from what I've read elsewhere, your Custom Recovery). Both of which are trivial to recover.
Is my understanding correct... or have I missed something?
Rgrds,
Ged.
Click to expand...
Click to collapse
I believe you are correct! Theoretically, the script could rather easily check for added files by checksumming the entire /system partition before running the update (using a fast hash algorithm-- you're only looking for the presence of any changes, afterall). And I did have one OTA that went fine, other than losing root back on my Galaxy Nexus.
Again though, it's a classic case of should versus real life. Some root methods might alter things in /system without your knowing, or root actions might alter permissions. Either way, it's a tricky, nasty little game.
So far as recoveries go: yeah, OTAs have a nasty habit of trying to do that. Some of the more advanced recoveries can resist being overwritten though/slipstream a root ZIP into the update process.
GedBlake said:
The OTA would only fail, if it found files in /system that SHOULD BE THERE, but have been removed, modified, or replaced by the user (or via some app run by the user).
Click to expand...
Click to collapse
Typically the OTAs also update the boot image, so the boot partition (LNX) is also checked. The stock recoveries almost always use the same kernel (with a different ramdisk) as the boot image, so they are usually rewritten too.
Owners of tilapia N7 devices have reported successful flashing of everything but radio firmware images when they used a custom recovery to process the OTA bundle. Not a disaster, as their devices will still function with old radio firmware, but it puts them in an unusual position of being unable to use the OTA to subsequently update the radio, even if they restore the stock recovery (the system files and boot images will have been changed, so almost all of the checksums will fail). At that point, using fastboot is an alternate option, but then the newbs will need to read about OTA images, unpack them, yadda yadda yadda.
IMO it is just a dumb idea applying OTAs to anything but a pure stock device. And when I say pure stock, I mean including the stock recovery. The boot loader can be left unlocked, but that's about it.
There are a lot of ways to skin the cat, but IMO the best way to proceed is to operate with two parallel but independent tracks of Nandroid backups/restores: one track is a sequence of pure stock, and the other your customized ROM du jour.
Let's presume you have a Nandroid backup of the pure stock ROM. Make a backup of your current (customized) ROM & get it copied off the tablet (in the event of a disaster), restore the pure stock ROM nandroid backup, flash the stock recovery back to the tab, and then take the OTA.
At this point:
[ unlocked bootloader ] soft-boot (no flashing) a custom recovery using fastboot, and then make yet another Nandroid backup of the newly updated stock ROM including the recovery image. (This becomes the new baseline for future OTAs)
[ locked bootloader ] re-root with motochopper, capture the (new) stock recovery partition using 'dd', flash a custom recovery ('dd' or other method), make a Nandroid of this. (These two backups become the new baseline for future OTAs)
Then, repeat any rooting customizations (if you are a "lightly customized rooted stock" kinda person), and restore apps (Market apps only!) with TiBu.
This may seem like a great deal of work, but it is the only way to insure that you can revert to a prior starting position. Look: after going down a road like this you can even restore the old customized ROM backup to make TiBu app backups after the fact, simply because you can return to any point in time if you have made a backup (and kept a copy of it off the tablet).
Everybody makes mistakes - even the experts. But the lazier folks are (read: toolkit user) the more likely is a disaster. Everybody needs to make backups.
What will happen if I change some values in build.prop editor? I won't be able to install stock ROMs anymore? Or what?
Sent from my Nexus 7 using xda app-developers app
valapsp said:
What will happen if I change some values in build.prop editor? I won't be able to install stock ROMs anymore? Or what?
Sent from my Nexus 7 using xda app-developers app
Click to expand...
Click to collapse
Depends on how you mean "install", you can always install via .img or recovery flashing method, but course that will overwrite your build.prop with the provided version and you would just have to re-edit the values again.
Did you mean OTA wise? If the update doesn't check for the hash of the build.prop, it will likely just replace it with a newer version if anything has changed from the last version to the new version.
As others have said, worse case scenario, the OTA fails to proceed due to errors and you would just have to manually update it yourself, as you could just flash a new boot.img and system.img from google's site (just have to remember anything you added on top of system or custom kernels will of course be reverted, so they will need to be reapplied).
Settings and user apps and such all live in /data , so it should just simply boot up as an upgraded system but with everything else intact (course I always make a backup via my custom recovery just in case).
kbeezie said:
Depends on how you mean "install", you can always install via .img or recovery flashing method, but course that will overwrite your build.prop with the provided version and you would just have to re-edit the values again.
Did you mean OTA wise? If the update doesn't check for the hash of the build.prop, it will likely just replace it with a newer version if anything has changed from the last version to the new version.
As others have said, worse case scenario, the OTA fails to proceed due to errors and you would just have to manually update it yourself, as you could just flash a new boot.img and system.img from google's site (just have to remember anything you added on top of system or custom kernels will of course be reverted, so they will need to be reapplied).
Settings and user apps and such all live in /data , so it should just simply boot up as an upgraded system but with everything else intact (course I always make a backup via my custom recovery just in case).
Click to expand...
Click to collapse
Thanks, and does backing up thru cwm also back up the build.prop?
valapsp said:
Thanks, and does backing up thru cwm also back up the build.prop?
Click to expand...
Click to collapse
Yes, but not in the way you're thinking. If you back up the whole system, CWM will package each partition up (/system /data , etc), so when you flash a new rom or system on, you can't just selectively restore build.prop since restoring in CWM Would also restore the entire system partition.
You can while in recovery, mount /system and do something like
adb pull /system/build.prop , and save a copy of it on your computer, so you can go back in and change the affected values back if for some reason you needed to.
If you're familiar with ghosting, nandroid backups (what CWM and most others do, minus some variations), are basically exact clones of all the files on each partition. Older recoveries actually took an image snapshot, newer ones basically pack all the files in a compressed archive (With some kind of note of what partition type it was, ext4, etc). The latter can easily be unpacked with tar, or 7zip, etc, but disk images are a different matter.
I can't remember which one CWM does exactly since on my DZ I use 4EXT, and on my Nexus devices I use TWRP.
kbeezie said:
Yes, but not in the way you're thinking. If you back up the whole system, CWM will package each partition up (/system /data , etc), so when you flash a new rom or system on, you can't just selectively restore build.prop since restoring in CWM Would also restore the entire system partition.
You can while in recovery, mount /system and do something like
adb pull /system/build.prop , and save a copy of it on your computer, so you can go back in and change the affected values back if for some reason you needed to.
If you're familiar with ghosting, nandroid backups (what CWM and most others do, minus some variations), are basically exact clones of all the files on each partition. Older recoveries actually took an image snapshot, newer ones basically pack all the files in a compressed archive (With some kind of note of what partition type it was, ext4, etc). The latter can easily be unpacked with tar, or 7zip, etc, but disk images are a different matter.
I can't remember which one CWM does exactly since on my DZ I use 4EXT, and on my Nexus devices I use TWRP.
Click to expand...
Click to collapse
Thanks, an easier way is to copy the build.prop thru a file manager.
But since I'm on my geek mood today I wanna know if it's possible to extract the backed up (Nandroid) file and find the build.prop somewhere there.
Sent from my Nexus 7 using xda app-developers app
valapsp said:
Thanks, an easier way is to copy the build.prop thru a file manager.
But since I'm on my geek mood today I wanna know if it's possible to extract the backed up (Nandroid) file and find the build.prop somewhere there.
Sent from my Nexus 7 using xda app-developers app
Click to expand...
Click to collapse
If it's a backup done with 4EXT or TWRP most certainly since it's just a tarball package (or tar+gzipped if you enabled compression) and can be easily unpacked by tar, or any popular archive utility like 7Zip for windows. (restoration generally just looks at the file info to see what partition type it's supposed to be, formats the partition as such, and then just un-tars the content, with the permissions and such retained).
If it's older where it's an actual jaffs (may have spelled that wrong) disk image, I'm not sure off the top of my head how you would mount it as a disk , and then mount the ext4 or ext3 partition in order to get to it. I would assume ClockworkMod would have upgraded their backup method to the same as TWRP or 4EXT, but it's possible that they didn't for compatibility reasons.
Device: Nexus 7 (Wi-Fi) (Old one)
Android: 4.3
When i go to flash cyanogenmod 10.2.0-grouper.zip i get this error
Updating partition details...
Installing 'usb-otg/cm-10.2.0-grouper.zip'...
Checking for MD5 file...
Skipping MD5 Check: no MD5 file found.
assert failed: getprop("ro.product.device") == "grouper" | | getprop("ro.build.pr
E:Error executing updater binary in zip '/usb-otg/cm-10.2.0-grouper.zip'
Error flashing zip 'usb-otg/cm-10.2.0-grouper.zip'
Updating partition details...
Can anyone please help this has been going on forever now and its getting super annoying.
What recovery are you using? Last I heard TWRP over 2.6.3.0 had issues. Try that certain version or use CWM
Sent from my Nexus 5
Pirateghost said:
What recovery are you using? Last I heard TWRP over 2.6.3.0 had issues. Try that certain version or use CWM
Sent from my Nexus 5
Click to expand...
Click to collapse
Lol ok ill try that. I'm on 2.6.3.1 ill try the other version of TWRP first.
How Did You Solve This?
HVC FOG3Y34 said:
Lol ok ill try that. I'm on 2.6.3.1 ill try the other version of TWRP first.
Click to expand...
Click to collapse
So can you give me a little more detail on what you did? This is my first unlock, root, custom recovery, and custom ROM ever, so if I made a mistake, I'm not sure I could even identify it. I used wugfresh's Nexus Root Toolkit to reach this point.
I have TWRP 2.6.3.1. Is the solution to flash a previous version of TWRP? If so, can you direct me to instructions for that?
StarSphere said:
So can you give me a little more detail on what you did? This is my first unlock, root, custom recovery, and custom ROM ever, so if I made a mistake, I'm not sure I could even identify it. I used wugfresh's Nexus Root Toolkit to reach this point.
I have TWRP 2.6.3.1. Is the solution to flash a previous version of TWRP? If so, can you direct me to instructions for that?
Click to expand...
Click to collapse
Hey im sorry. i don't really remember what i did, it was a very annoying time for me. All i remember is googling most of the stuff. Just google how to flash custom recovery on nexus 7 jelly bean or something. sorry...
StarSphere said:
So can you give me a little more detail on what you did? This is my first unlock, root, custom recovery, and custom ROM ever, so if I made a mistake, I'm not sure I could even identify it. I used wugfresh's Nexus Root Toolkit to reach this point.
I have TWRP 2.6.3.1. Is the solution to flash a previous version of TWRP? If so, can you direct me to instructions for that?
Click to expand...
Click to collapse
Fastboot flash recovery nameofrecoveryimage.img
It's that simple
Sent from my Nexus 5
Complete Instructions
I'm a newbie, and this is what I did. I can't take responsibility for anything that happens to anyone's device, nor answer any questions, because I only half understand it myself. I am sorry I can't include links. I am too new, and the website won't trust me to do that. So, you will have to search for these things on your own.
Download Stuff to your PC Note: Some antivirus software may trigger false positives on these kinds of files and block them from downloading, so you may have to temporarily disable the website shielding portion of your program.
1) The fastboot.exe file. If you want a big download, you can get it in the Android SDK. However, I got it from the CyanogenMod Installer. The installer failed to work with my device, but conveniently downloaded the fastboot.exe file for me. I'm not sure I would recommend this route if you don't want CyanogenMod.
2) TWRP 2.6.3.0. You can get it from androidfilehost.
Safety Stuff
1) Compare the MD5 code on the website to the one in your downloaded TWRP image.
A Windows utility to do that is called MD5 SHA Checksum Utility.
An Android utility to do that is called MD5 Checker.
2) Completely back up your current Android ROM. Nexus Root Toolkit is great for this and many other things. It can be downloaded from wugfresh.
The Custom Recovery Flash
1) Make sure USB debugging is still enabled on your Android device. The video links on wugfresh's page can show you how to do that.
2) Make sure your Android device is connected to your PC via USB cable.
3) Boot your Android device into the bootloader. I used Nexus Root Toolkit -> Advanced Utilities Launch -> Reboot Bootloader to do this, but I think you can also do it by turning your device off, then holding down the Power and Volume Down buttons simultaneously (don't quote me on that).
2) Search for the location of fastboot.exe on your PC. Mine was in my user directory, where CyanogenMod's installer left it: C:\Users\{Username}\cminstaller\bundle\win32
3) On your PC, open a command line. Go into the directory where you found fastboot.exe above.
4) Type fastboot flash recovery {Complete directory location and file name of TWRP image}. If you would rather not be using the complete directory location, you can always copy the TWRP image into the same directory as the fastboot.exe file, before doing this step.
5) The command window should soon say "finished". Mine took under 2 seconds.
6) On your Android device, the bootloader should currently have a big green arrow that says "Start". Press the volume down button until the arrow says "Recovery". Then press the power button. Your device should now start TWRP 2.6.3.0.
Best of all, using TWRP 2.6.3.0 for custom recovery, instead of the newest version, really did solve the original problem. Yeah!
Unfortunately, the next time I used Nexus Root Toolkit, it insisted on updating back to TWRP 2.6.3.1. So, hopefully I won't have to flash another ROM in the near future and the next TWRP version will fix the problem more permanently.