[HOW TO] Root the VZW/LTE Samsung Galaxy Nexus

.
There is no "root exploit" required to root the Samsung Galaxy Nexus since it comes with an unlockable bootloader. So, this means that there is not soon likely to be a 1-click or easy rooting app to run that exploits something in Ice Cream Sandwich in order to root the phone.

Here are the basic steps that need to be done in order to root the GNex:

Unfortunately, the biggest hurdle for folks using Microsoft Windows will be issues relating to getting the proper Samsung USB drivers installed and working properly. Please take note of the several options listed at the bottom of this post. For Mac and Linux users, this is fortunately not an issue.

The second biggest hurdle will be getting the adb and fastboot utilities installed and understanding how to use them.

Note: I did experience some hangs while using the fastboot and adb utilities when my USB cable was plugged-in to a USB 3.0 port; these issues disappeared when I reverted back to a USB 2.0 port.

Quick notes about adb / fastboot:

Rooting the Samsung Galaxy Nexus does require use of command-line utilities like adb and fastboot.

If you don't have both adb and fastboot installed anywhere, it might be easiest to download and extract the sdk-tools.zip file referenced in the "Mini-SDK" section of this thread ADB Guide to a folder on your PC of your choosing (take note of this folder/directory's name).

Note for Linux users: you might (probably will) have to resecure the adb and fastboot utilities after installing (i.e., chmod a+x adb and chmod a+x fastboot); additionally, you'll probably have to use the sudo utility when invoking these utilities; for example: sudo ./adb devices or sudo ./fastboot devices

These are two very different tools for use when your device is in a very specific mode:

fastboot

- to use this utility, your phone must be in fastboot mode (also known as bootloader mode) which can be reached by powering-down your phone and restarting it by pressing and holding the volume-up AND volume-down AND the power buttons UNTIL you see the little green Android laying on his back with door on his chest open (you'll also see "Start" in big, green text at the top and "FASTBOOT MODE" in very small red text just below the Android

- other ways to get into fastboot / bootloader mode:

when you are finally rooted, you can use an app like Quickboot and selecting "Bootloader"

when you do have fastboot working, you can also use the fastboot reboot-bootloader (Windows) or ./fastboot reboot-bootloader (Mac / Linux) command to re-launch the fastboot/bootloader mode

- you can verify that you have fastboot USB connectivity by issuing a fastboot devices (Windows) or ./fastboot devices (Mac / Linux) from a command session wherever you have the fastboot utility installed

- the output of an "fastboot devices" command should be look something like this:

Code (Text):

sdk-tools> [B][COLOR="purple"]fastboot devices[/COLOR][/B]

[COLOR="Blue"]<device serial #> fastboot[/COLOR]

adb (Android Debug Bridge)

- you can use the adb utility at two different times/modes on your phone:

when you are booted normally into Android and have enabled USB debugging (Settings -> System -> Developer options -> USB debugging (checked))

when you are booted into a custom recovery (like ClockworkMod); custom recoveries support adb connectivity so you can invoke a shell, push / pull files, etc.

- you can verify that you have adb USB connectivity by issuing a adb devices (Windows) or ./adb devices (Mac / Linux) from a command session wherever you have the adb utility installed

- the output of an "adb devices" command should be look something like this:

Code (Text):

sdk-tools> [B][COLOR="purple"]adb devices[/COLOR][/B]

[COLOR="Blue"]<device serial #> device[/COLOR]

If you are a Windows user and you have trouble establishing connectivity when using these utilities, try installing a different set of USB drivers (see the list of USB drivers at the end of this post).

Your best bet will be to take your time, do your reading and research, and make sure you understand what you are about to do before doing it. Perusing the threads and posts here will go a long way towards letting you see what other issues folks have encountered.

Click the Show button below for in-line instructions to unlock the bootloader:

A. if you already have the Android SDK installed with both the adb and fastboot utilities, go ahead and skip to step B.

If you don't have both adb and fastboot installed anywhere, it might be easiest to download and extract the sdk-tools.zip file referenced in the "Mini-SDK" section of this thread ADB Guide to a folder on your PC of your choosing (take note of this folder/directory's name).

B. turn off (power down) your device

C. connect the USB cable between the phone and your PC if you haven't already

D. on your PC, start-up a terminal session (Windows Command Prompt for Windows; Terminal for Mac or Linux) and navigate to the directory/folder where the adb and fastboot utilities are located:

+ for Windows, you need to start-up a Windows Command Prompt (DOS window) and type the following (for example, assuming that your adb / fastboot files are in the c:\sdk-tools folder):

Code (Text):

[B][COLOR="purple"]cd c:\sdk-tools[/COLOR][/B]

+ for Mac/Linux, start-up a Terminal session and type the following (for example, assuming that your adb / fastboot files are in the sdk-tools folder):

Code (Text):

[B][COLOR="Purple"]cd sdk-tools[/COLOR][/B]

E. next, boot your phone into fastboot mode (press and hold both the volume-UP and volume-DOWN buttons and then press the power button)

F. if you are using Windows, install the appropriate Samsung USB drivers; note: there are several USB driver options listed at the bottom of this post; this one in particular worked very well for me and others:

Also, please note that after you issue the unlock command, you will be asked, on your phone, to acknowledge that you want the bootloader to be unlocked and that you understand that doing so will void your warranty. Use your volume rocker/keys to select the confirmation and press the power button to actually confirm.

J. That's it, your bootloader should now be unlocked and you are ready for your next step. You phone should still be in fastboot mode at this point.

If you simply wanted to unlocked the bootloader and now want to reboot your phone, you can issue a "fastboot reboot" (for Windows) or "./fastboot reboot" (for Mac/Linux) to reboot the device normally (note/warning: since unlocking the bootloader does a factory reset, your next reboot after unlocking will take about five minutes to complete--so be patient and wait for the boot animation to finish-up).

If you are not ready to reboot, but need to do other fastboot-related operations, then your phone is still in fastboot mode and ready for you.

C. place both the su.zip and the selected ClockworkMod recovery .img file in the directory with your fastboot and adb utilities

D. next, boot your phone into fastboot mode (press and hold both the volume-UP and volume-DOWN buttons and then press the power button)

E. start-up a command prompt (Windows) or Terminal (Mac / Linux) session as outlined in the Unlocking The Bootloader section above and change to the folder / directory where your fastboot utility, adb utility, su.zip, and selected recovery .img file are located

Note for Windows users: we will be using both the adb and the fastboot utility below, so you'll need to make sure you have USB drivers installed that will recognize your device while in both modes. The [ADB/FB Driver] Naked Samsung Driver 1.7 - xda-developers works very well and there are other USB driver options listed at the bottom of this post.

F. now, at this point, we will start-up ClockworkMod custom recovery; we can either soft-boot (load it from your PC into your phone's memory; this method will not replace the currently installed recovery partition on your phone) or flash it (overwrite the currently installed stock recovery image on your phone):

- after you've flashed the recovery, use the [B]volume keys[/B] to change the

green "[COLOR="Green"]Start[/COLOR]" arrow/banner to the red "[COLOR="Red"]Recovery mode[/COLOR]" one

- select that mode by pressing the [B]power button[/B]--that will actually

launch the new custom recovery

G. after you see ClockworkMod custom recovery appear on your phone

- okay, if you haven't already put the su.zip file in the /sdcard, then we'll need to push (send) it over to your phone from the PC; there is an issue that I finally figured-out that ClockworkMod won't mount the /data partition (and therefore, your /sdcard directory that's symbolically linked to the /data/media folder) until you've done this sequence at least once:

- > from the main ClockworkMod Recovery screen / menu- > select install zip from sdcard- > that will take you to the Apply update from .zip file on SD card screen / menu- > select choose zip from sdcard- > you'll see a slight pause while the /data partition is mounted- > now, you'll see a list of files on your /sdcard in the Choose a zip to apply screen- > don't choose anything right now, navigate to +++++Go Back+++++ to return to the previous menu- > hang here on the Apply update from .zip file on SD card screen / menu for now

- use the volume key / rocker to navigate
- use the power button to select an entry

what to do:

note: if you've already navigated in ClockworkMod to the Apply update from .zip file on SD card screen / menu, then you can skip this next line and go right to the "choose zip from sdcard" entry, otherwise:

- select the "install zip from sdcard" entry

- select the "choose zip from sdcard" entry

- navigate to the bottom of the displayed menu options, you should see your "su.zip" entry there; select it

- after you flash the su.zip file, navigate to the "*****Go Back*****" entry; select it to return to the prior menu screen

-- simpler method for rooting (installs root binaries for you)
-- works for both GSM and LTE versions of the device

Cons: you'll still need to use fastboot to unlock your bootloader (if you haven't already)

This method automates the installation of the su / Superuser binaries for you; click the "Show" button below for details on how this works:

I unpacked the boot.superboot.img file into its kernel and ramdisk components and saw that the init.rc script (in the ramdisk) was modded to invoke the /superboot/superboot.sh script which temporarily remounts /system as read/write and installs/secures the su binary and the Superuser app.

The only caveat about using the Superboot method is that you'll still have to unlock your bootloader (if you haven't already) with the fastboot oem unlock command which Superboot cannot directly address.

This means you'll still need to follow the instructions in the section Unlocking The Bootloader above.

Note for VZW LTE Galaxy Nexus phones: it appears that the boot.superboot.img file, when used on the VZW LTE Galaxy Nexus, might hang (it did for me, but not for others; I suspect I just didn't wait long enough) and not finish booting. It will, however, get the root apps (su / Superuser.apk) installed and root your phone. You'll just need to do a battery-pull and restart after waiting a few minutes after executing the above installation scripts.

Quick note / disclaimer: as always, you are ultimately responsible for any root-related activities on your phone. You should understand not only the benefits of rooting, but also any possible consequences (voided warranty, boot-loops, bricking, etc.) that might occur as a result of your root-related actions.

AndroidForums.com / Phandroid.com, its owner, and staff are not liable for any root actions you might undertake as a result of information used from this site.

Reading, researching, understanding, and carefully following the published steps and instructions can go a long way towards helping to make your rooting efforts a successful one.

-=< Credits (Peter Alfonso / Paul O'Brien / XDA's davioxx) >=-

All credit goes to the following folks (I'm just re-summarizing what has already been developed and published by them):

* Peter Alfonso for the insecure boot.img file which allows the system partition to be remounted in read/write mode so that the root programs may be installed.

OK, I've got a technical question. It seems as though the easiest way for now is to either flash CWRecovery or boot recovery CWRecovery, then use the provided "su.zip" file to finish the job. However, my goal is to install busybox at the same time.

A tiny bit of background, I sort of know how to make custom "update.zip" files (at least for the A855/OG Droid), I have template files and guides to do so. With these 'template' files, there is always a path that goes like this:

Code (Text):

META-INF/com/google/android/

and contained therein are usually two files:

Code (Text):

update-binary

updater-script

and it is the "updater-script" file that I know how to manipulate.

However with the "su.zip" file posted here, in the root directory is a META-INF folder and another .zip file starting with "Superuser". If you follow the path to the end in the root META-INF directory, all you find is an "update-binary" file. If you open the "Superuser[etc.].zip" file in the root, then you find the stuff I'm used to seeing; again down to the end of the "META-INF" path, i.e. a "updater-script" file.

Obviously this "su.zip" file works, but how? Is this an update contained in ICS, or the CWRecovery for the i515? I guess what I'm saying is why have a modified "update-binary" that is going to then further install another "update.zip" style file. Is this needed? Or could I just create my own "update.zip" style file to install via CWRecovery; su, Superuser.apk, and busybox through the "updater-script" commands that I am used to?

OK, I've got a technical question. It seems as though the easiest way for now is to either flash CWRecovery or boot recovery CWRecovery, then use the provided "su.zip" file to finish the job. However, my goal is to install busybox at the same time.

A tiny bit of background, I sort of know how to make custom "update.zip" files (at least for the A855/OG Droid), I have template files and guides to do so. With these 'template' files, there is always a path that goes like this:

Code (Text):

META-INF/com/google/android/

and contained therein are usually two files:

Code (Text):

update-binary

updater-script

and it is the "updater-script" file that I know how to manipulate.

However with the "su.zip" file posted here, in the root directory is a META-INF folder and another .zip file starting with "Superuser". If you follow the path to the end in the root META-INF directory, all you find is an "update-binary" file. If you open the "Superuser[etc.].zip" file in the root, then you find the stuff I'm used to seeing; again down to the end of the "META-INF" path, i.e. a "updater-script" file.

Obviously this "su.zip" file works, but how? Is this an update contained in ICS, or the CWRecovery for the i515? I guess what I'm saying is why have a modified "update-binary" that is going to then further install another "update.zip" style file. Is this needed? Or could I just create my own "update.zip" style file to install via CWRecovery; su, Superuser.apk, and busybox through the "updater-script" commands that I am used to?

Click to expand...

Ted,

Actually, things are a little different than what it first seems () re. what is going on with this particular flashable su.zip file. There are two very interesting little twists that the authors of this file have implemented and there's nothing unusual involving ICS or even ClockworkMod.

The first twist is the Superuser-3.0.7-efgh-signed.zip file contained within the su.zip. It is a little bit of a red-herring in that while it is indeed a flashable .zip file on its own (at your own risk, of course), it is simply a payload file for the overall su.zip file and it is from here that the su binary and the Superuser.apk file is taken from (and where you would put a busybox if you were so inclined).

The second twist is the real beauty: the update-binary that "belongs" to the su.zip file is actually a shell script and not a compiled binary file at all. It is this file that controls the actions of what takes place when the su.zip file is being flashed--all without the need for the usual updater-script file.

Let me know if you want me to post the one I built and tested with up here...just remember if you do build a "traditional" flashable script that I think CWM now uses the edify format vs. the old ammend format.

Actually, things are a little different than what it first seems () re. what is going on with this particular flashable su.zip file. There are two very interesting little twists that the authors of this file have implemented and there's nothing unusual involving ICS or even ClockworkMod.

The first twist is the Superuser-3.0.7-efgh-signed.zip file contained within the su.zip. It is a little bit of a red-herring in that while it is indeed a flashable .zip file on its own (at your own risk, of course), it is simply a payload file for the overall su.zip file and it is from here that the su binary and the Superuser.apk file is taken from (and where you would put a busybox if you were so inclined).

The second twist is the real beauty: the update-binary that "belongs" to the su.zip file is actually a shell script and not a compiled binary file at all. It is this file that controls the actions of what takes place when the su.zip file is being flashed--all without the need for the usual updater-script file.

Let me know if you want me to post the one I built and tested with up here...just remember if you do build a "traditional" flashable script that I think CWM now uses the edify format vs. the old amend format.

Cheers!

Click to expand...

Sean, ah yes, now I see.

For the readers, this may get way over your head, but if you are so inclined you can learn as well . . . . however, much reading before posting should be a requisite.

Scary, the reason I asked, as you well may know, is because in other 'update.zip' style files, the 'update-binary' file was just that, in binary code. But I have had great success using notepad++ to view/edit/modify the 'updater-script' file to my liking and purposes. But now you have enlightened me. The 'update-binary' file in the root /META-INF/com/google/android directory of this particular file is in fact a script that one can view via notepad++.

And for future reader/learners. 'Google' Notepad++, install it, learn how and when to use it, and profit.

Read more, post less.

So that said, even though you say it's not an ICS, nor a CWR thing, I guess I will go ahead and modify the /META-INF/com/google/android/updater-script file within the Superuser-3.0.7-efgh-signed.zip file to include an install of busybox as well. As that is my whole goal. No sense rooting your phone without installing busybox at the same time.

That is why I made my own reservation in this thread in post #4, hehe.

Oh and p.s. to scary and the readers. I only know the 'edify' format as that is why it is now called 'updater-script'. With 'ammend' it was called 'update-script'.

After further looking at your CWRecovery method, I see that you have two different commands to 'push' the "su.zip" file to the phone:

You have a disclaimer/comment about the second command saying it worked better, however, if you modified the first command to be:

Code (Text):

adb push su.zip /sdcard/su.zip

wouldn't that work just as well and negate the need for the second command?

Just saying/asking . . . .

Click to expand...

Ted,

I experienced many instances while testing the root methods and particularly the one where you flash the su.zip from CWM where pushing the su.zip to the "/sdcard" mount, with and without the filename, didn't make the filename show-up in the list of files that CWM showed as available for flashing.

Using the alternate path when the first worked (or just doing both) always made the file show-up.

I'm thinking that there's some reason why CWM is not always able to get the mount point for "/sdcard" installed by the time one tries to flash a file (perhaps due to its very large size? Dunno).

I might do some testing and watching the recovery.log file to see if there's anything reported in there that would tell the tale.

@scary: Thanks for putting up with my incessant questions about the SCHi515; especially since i have yet to get this device in my hands.

Unless I see a Motoroogle Developer device available when I finally have the funds to buy this one (~30 days from now), I hope to be able to 'pay it forward' with my own hands on experience(s). And if it goes that way, maybe I/we can figure out where exactly on the phone's internal storage is the partition that CWR 'sees' as "/sdcard/".

@scary: Thanks for putting up with my incessant questions about the SCHi515; especially since i have yet to get this device in my hands.

Unless I see a Motoroogle Developer device available when I finally have the funds to buy this one (~30 days from now), I hope to be able to 'pay it forward' with my own hands on experience(s). And if it goes that way, maybe I/we can figure out where exactly on the phone's internal storage is the partition that CWR 'sees' as "/sdcard/".

Click to expand...

Ted,

Hey, no problem...this is a fun device to research with and play around with...

As far as the wonky SD card mount issues in ClockworkMod goes, we do already know that /sdcard is soft-linked to /data/media:

that is NOT found running in ClockworkMod custom recovery--indeed, the "virtual SD card" service is not found in the init.rc file of the ramdisk that's packed with CWM and it appears that /sdcard is simply soft-linked to /data/media (although I can't see an obvious place in the ramdisk or in Koush's code where this is done).

For some strange reason, whenever I go into "choose zip from sdcard" I get

Code (Text):

Couldn't open directory.

No files found.

I've tried both push methods you listed, but I get the same result with both. If it makes any difference, I'm on a Mac and I used the flash method for CWM.

Click to expand...

Wow...I just keep seeing more and more folks having problems with seeing their SD card files while in ClockworkMod...

Can you just try restarting CWM and seeing if they show-up?

There is a spot that I've seen in the CWM recovery.log file that shows CWM will wait for 20 seconds to allow the mount for the SD card to finish, but since its really just symlink to the /data/media area, that shouldn't take long (unless its really taking a long time for /data to be mounted).

Dunno...try restarting CWM and see if the su.zip file (I'm assuming that's what you're trying to flash) is now present.

Wow...I just keep seeing more and more folks having problems with seeing their SD card files while in ClockworkMod...

Can you just try restarting CWM and seeing if they show-up?

There is a spot that I've seen in the CWM recovery.log file that shows CWM will wait for 20 seconds to allow the mount for the SD card to finish, but since its really just symlink to the /data/media area, that shouldn't take long (unless its really taking a long time for /data to be mounted).

Dunno...try restarting CWM and see if the su.zip file (I'm assuming that's what you're trying to flash) is now present.

How about this...try rebooting back into CWM and give it a minute or two before trying the "chooze zip from sdcard" thing...

Maybe it just needs more time for the mount of /data to finish...?

I'm pretty sure the early times that I had problems with testing of trying to push the su.zip file to the SD card, I was doing things pretty quickly and tried to invoke that function pretty soon after I started-up CWM.

How about this...try rebooting back into CWM and give it a minute or two before trying the "chooze zip from sdcard" thing...

Maybe it just needs more time for the mount of /data to finish...?

I'm pretty sure the early times that I had problems with testing of trying to push the su.zip file to the SD card, I was doing things pretty quickly and tried to invoke that function pretty soon after I started-up CWM.

Click to expand...

Nope, that doesn't work either. :/
Well, looks like I won't be able to root. Bleh.

While I don't have the device yet, and I don't know exactly how far 'back to stock' you took it, but I have read that if you get bootloops, go ahead and boot into recovery and do a factory data reset. That should fix the booting problem. Then you will have to re push the su.zip file, since it will have been wiped. Then try again.

I don't even use push for this phone most times. Hook up phone, locate the device Galaxy Nexus and drag/drop the zip into an open area of the storage. They show up in cwr as contents of "SD card". I don't know much about osx but it works nicely on a windows machine. Might give that a shot if you're having push problems.

I don't even use push for this phone most times. Hook up phone, locate the device Galaxy Nexus and drag/drop the zip into an open area of the storage. They show up in cwr as contents of "SD card". I don't know much about osx but it works nicely on a windows machine. Might give that a shot if you're having push problems.

Click to expand...

Wow! I just had a revelation when reading your post, iowabowtech!

It made me think about what I did last night when I was discussing the /sdcard mounts and /data partition clears with Yeahha...

Okay, I think I might have figured-out the issue with pushing files to the /sdcard and why it doesn't work at times.

Here's the deal: the /data partition is not mounted until you've navigated to the Apply update from .zip file on SD card menu and you have selected the "choose zip from sdcard" entry!

You'll notice a slight delay the first time you enter that menu--that's when the /data partition is mounted.

So, you can make sure your symlinked /sdcard is mounted by making it to the Choose a zip to apply menu, selecting "+++++Go Back+++++", pushing your .zip file, and then re-selecting "choose zip from sdcard", your file will be present.

I'm thinking that when you push the file to /sdcard or to /data/media too early, i.e., before /data is actually mounted, that file is lost because its actually being done in the ramdisk and not in the proper /data partition.

While I don't have the device yet, and I don't know exactly how far 'back to stock' you took it, but I have read that if you get bootloops, go ahead and boot into recovery and do a factory data reset. That should fix the booting problem. Then you will have to re push the su.zip file, since it will have been wiped. Then try again.

Or there's the manual method(s).

good luck

Click to expand...

All the way back, locked bootloader, stock OS, etc.
I got it figured out and I'm rooted and good to go. It was a really stupid mistake on my part that made it not work. For some reason I'm not surprised.

All the way back, locked bootloader, stock OS, etc.
I got it figured out and I'm rooted and good to go. It was a really stupid mistake on my part that made it not work. For some reason I'm not surprised.

It made me think about what I did last night when I was discussing the /sdcard mounts and /data partition clears with Yeahha...

Okay, I think I might have figured-out the issue with pushing files to the /sdcard and why it doesn't work at times.

Here's the deal: the /data partition is not mounted until you've navigated to the Apply update from .zip file on SD card menu and you have selected the "choose zip from sdcard" entry!

You'll notice a slight delay the first time you enter that menu--that's when the /data partition is mounted.

So, you can make sure your symlinked /sdcard is mounted by making it to the Choose a zip to apply menu, selecting "+++++Go Back+++++", pushing your .zip file, and then re-selecting "choose zip from sdcard", your file will be present.

I'm thinking that when you push the file to /sdcard or to /data/media too early, i.e., before /data is actually mounted, that file is lost because its actually being done in the ramdisk and not in the proper /data partition.