Originally Posted by verkerria
Here is a question I've never seen asked before. We have succeeded in hijacking the bootloader and getting clockworkmod recovery working. We have succeeded in using genius methods to run android via a zip, off an sd card, and even flashing nand on many different types of phones. Now here is my question... I'm going to use some metaphors here... let's say the kernel loads up during startup... what if we "shoved" the GB kernel into a closet after the 2nd system initializes, and load a custom kernel instead? ( don't know if its possible, as I don't really know how android boots up... but it is just a question, and if you have time to explain it, I would feel rewarded for my thoughts
Droid 1 Rooted (ChevyNo1 0.9MV Kernel, LGB2.6)
Droid 3 Rooted (Hashcode gave me some Ice Cream)
this may help some till some one can get more in depth.
http://www.androidenea.com/2009/06/a...-power-on.html
it shows the booting process from power on.
__________________
Originally Posted by verkerria
That's was a rather informative article. At what point during that process does the safe rom start loading? Could a second kernel load and take over after the safestrap loads into the second rom, and the first kernel confined somewhere in the background?
Droid 1 Rooted (ChevyNo1 0.9MV Kernel, LGB2.6)
Droid 3 Rooted (Hashcode gave me some Ice Cream)
that kinda depends if you use safestrap, bootstrap or flash from rom manger
if im not mistaken using safestrap you are dual booting the two roms. with the other two you are replacing the rom.
Originally Posted by verkerria
I'm talking about putting a different kernel in the safe system rom of a safestrapped device, instead of trying to run the safe system rom off of the kernel in the non safe system
Droid 1 Rooted (ChevyNo1 0.9MV Kernel, LGB2.6)
Droid 3 Rooted (Hashcode gave me some Ice Cream)
maybe this will help
hash explains how it works.
http://rootzwiki.com/topic/8752-romd...ost__p__248383
__________________
I got the general gist of the function when I started using it. My mind works in kind of a weird way, I'm trying to figure out if the system just checks to see if the kernel is intact and continues loading, and if the system would notice if we put a script into the bootup process to squash the original kernel after it is checked and load a custom one in its place. I apologize if I am confusing anyone, I'm trying my best to iterate it the way I'm thinking it lol
I got the general gist of the function when I started using it. My mind works in kind of a weird way, I'm trying to figure out if the system just checks to see if the kernel is intact and continues loading, and if the system would notice if we put a script into the bootup process to squash the original kernel after it is checked and load a custom one in its place. I apologize if I am confusing anyone, I'm trying my best to iterate it the way I'm thinking it lol[/QUOTE]
i understand now what you want to do.
kinda like how we over clock the cpu but have it put a kernel in the place of over clocking
the kernel boots before init dose is the scripting not done in the init part of the bootup?
here is a another good link to how android boots up
http://elinux.org/Android_Booting
verkerria said:
I got the general gist of the function when I started using it. My mind works in kind of a weird way, I'm trying to figure out if the system just checks to see if the kernel is intact and continues loading, and if the system would notice if we put a script into the bootup process to squash the original kernel after it is checked and load a custom one in its place. I apologize if I am confusing anyone, I'm trying my best to iterate it the way I'm thinking it lol
Click to expand...
Click to collapse
I (think) I understand you fine, and think it's a good idea, but whether it can be done I have no idea.
just to clarify, the normal boot order for an android device is
Code:
[B]Ⅰ — firmware[/B]
A — first-stage bootloader runs
• it detects if a special key is held, and can launch the recovery
image, or the 'fastboot' bootloader
[I](I would assume this is where the bootloader protection checks
to see if the officially signed kernel is intact, but I can't find
anything to corroborate)[/I]
B — eventually, a kernel is loaded into RAM (usually with an initrd)
• normally, this will be the kernel from the 'boot' flash partition.
[B]Ⅱ — kernel[/B]
A — the kernel boots
1 — core kernel initialization
• memory and I/O areas are initialized
• interrupts are started, and the process table is initialized
2 — driver initialization
3 — kernel daemons (threads) are started
4 — root file system is mounted
5 — the first user-space process is started
• usually /init (note that other Linux systems
start /sbin/init)
[B]Ⅲ — user space[/B] (I'll skip this since it doesn't apply to the issue)
What you're suggesting is to somehow trick the bootloader protection by letting it keep the correct kernel, but then prevent the official version from loading. instead, loading a different, unofficial kernel. in which case the boot process would look like this:
Code:
[B]Ⅰ — firmware[/B]
A — first-stage bootloader runs
1 — special key detection
[COLOR="Red"]2 — BL protection verifies official kernel is present[/COLOR]
B — eventually, [I]a[/I] kernel is loaded into RAM (usually with an initrd)
• normally, this will be the kernel from the 'boot' flash partition,
[COLOR="red"]but instead is loaded from somewhere else[/COLOR]
[B]Ⅱ — kernel[/B]
[B]Ⅲ — user space[/B]
I think the easiest way to answer this is no. Because the stock kernel is in the boot partition which is locked (locked bootloader) and the stock kernel will always boot no matter what. A kernel module is a lot simpler and way less work. Otherwise this would have most likely been done on previous phones with locked bootloaders. (d2 d2g dx etc..) But the thing is, I don't think anyone is working on a module since there are only a hand full of developers for the D3 (apporx. 8..) and most of them aren't experts on writing kernel modules. The modules were written by other devs that no longer mess with it or have no interest since the phone is already fast stock (and with other system tweaks). Hashcode is our best bet, but its not in his interest at the moment.
Is overclocking the point of this?
Nah, I'm not interested in overclocking, I just want to see hash have an easier time with the things that are still broken, like memory management, graphics accelleration, and the camera, which would be easier for him to diagnose if we could get a tailored ics kernel up and running, nobody ever thought dual booting roms would happen, and Hash/Koush made it happen, now its becoming a standard on fastboot phones. Hash is an extremely talented programmer, and he has come a long way very quickly on a few devices, I'm just throwing things out there to stir out ideas
Droid 1 Rooted (ChevyNo1 0.9MV Kernel, LGB2.6)
Droid 3 Rooted (Hashcode gave me some Ice Cream)
There's kexec that allows booting a kernel within Linux. I was using it with xdandroid. Kind of like a hotboot. It was orignally set up for when a new zImage was compiled. I used it when a reboot was needed rather than rebooting into Windows Mobile. But if i'm not mistaken the currently loaded kernel had be be patched to be able to use it.
[edit] Just found this for Atrix, development seems to have stopped http://forum.xda-developers.com/showthread.php?t=1079097
This kholk guy has a lot of crazy ideas, I like his style. A lot of people were saying his idea work, and he abandoned the thread after getting a Razor it looks like
Droid 1 Rooted (ChevyNo1 0.9MV Kernel, LGB2.6)
Droid 3 Rooted (Hashcode gave me some Ice Cream)
So let me see here, when we switch to safe system, a patch is applied which causes bootloader panic mode, initializes kexec, loads custom kernel over the resident one into the proper ram address, initializes/reinitializes radio, rom boots under new environment, that's what i get out of that project info wise. Now.. as to whether or not its possible with all the info/expertise we have accumulated over the past 7 months, that's the question
Droid 1 Rooted (ChevyNo1 0.9MV Kernel, LGB2.6)
Droid 3 Rooted (Hashcode gave me some Ice Cream)
eww245 said:
There's kexec that allows booting a kernel within Linux. I was using it with xdandroid. Kind of like a hotboot. It was orignally set up for when a new zImage was compiled. I used it when a reboot was needed rather than rebooting into Windows Mobile. But if i'm not mistaken the currently loaded kernel had be be patched to be able to use it.
[edit] Just found this for Atrix, development seems to have stopped http://forum.xda-developers.com/showthread.php?t=1079097
Click to expand...
Click to collapse
I think the main problem is that kexec isn't working correctly w/our omap4 devices and causes a crash when rebooting to the new kernel. If we had kexec working 100% this might be possible (running a second kernel on our devices) but then we might be stuck loading a second moto-signed kernel still.
could some thing like this be used to help
http://www.linuxfordevices.com/c/a/News/Ubiquitous-QuickBoot/?kc=LNXDEVNL032410
not so much for the boot up speed but to switch kernels. i was reading one of these last night that said it loaded the kernel but stoped part way through then loaded the ram/scripts then when back to finish the kernel. so could it not go back and load a custom kernel.
oostah said:
could some thing like this be used to help
http://www.linuxfordevices.com/c/a/News/Ubiquitous-QuickBoot/?kc=LNXDEVNL032410
not so much for the boot up speed but to switch kernels. i was reading one of these last night that said it loaded the kernel but stoped part way through then loaded the ram/scripts then when back to finish the kernel. so could it not go back and load a custom kernel.
Click to expand...
Click to collapse
I think that's more just restoring certain areas of ram to speed up booting, not really loading another kernel, like if when you turned off your devices it stored everything about the state it was in and just loaded it directly to that state vs a full boot. AFAIK the most promising is Kexec, it already works on the linux kernel on most machines out there it just needs some tweaking and polish for our devices. There are a few sites/gits out there that are getting regular commits (changes to the code) to get it working. Another thing we have to look at though is moto security and wether even with Kexec or something else working we can boot a kernel that wasn't compiled in a moto lab and signed with their tools, afaik they still need to be signed(so I could boot like xt862, razr, bionic kernel on my xt860 but not samsung or htc or kernels I've compiled myself).
Edit: I found this pic helpful to show what quickboot was actually doing, notice how the flow shows that it just skips part of the normal booting process by restoring from rom to ram
Bumping. Interesting thread and idea.
Related
I'm considering rooting my phone, but I'm kind of on the fence. First, I don't really want to void my warranty, but since I bought the phone used do I even have a warranty anymore? Second, I'm not really that interested in custom ROMs at this point since I'm new to Android OS and I'm happy with the way things are stock for now. So my question is... What can I do with a rooted phone running the stock Froyo ROM? Anything cool/interesting, or does it not even pay to bother rooting if I'm going to keep it stock?
I waited 3 months before rooting and I thought the same as you, wasn't interested in custom ROMs and all. Once I finally rooted and loaded cyanogen ROM, it completely changed my thinking. I highly highly recommend using cyanogen if you root. I can't stress enough. Things wkt can do with root are many, 720p video hack, black notification bar, themes, meta morph, audio volume hack, ROM manager, titanium backup, nand backups! The list is endless. Hell nand backup alone is worth rooting.
Is there a place or a link I can find more information about just stuff that I can do with a rooted phone BESIDES installing custom ROMs? Everything I usually find is just about ROMs. I want to just get my feet wet a little before I decide to just jump right in. For now I'm just interested in stuff I can do with plain old vanilla android once it's been rooted.
Look for apps that require root, see what they are and if you need any of them.
Here's my current list of things "to root for", I haven't yet..
Reasons to root:
Just root, nothing else:
- Adblock host file
- ClockSync
- GScripter
- Remove built-in crap (Amazon MP3)
- Screenshots
After installing recovery image
- Nandroid
After installing custom rom
- Black notification bar
Depending on where you live, you might still have warranty. For example, in Europe, the warranty is by default 2 years on the device. So it doesn't matter if you got it second hand, as long as the device still has warranty, you're OK.
Secondly, you can root your device without unlocking the bootloader. Check this thread for more info. At step 18, before doing the 2 'exit' commands, also take the time to rename /system/etc/recovery-install.sh & install + make executable a file called flash_image (google it to find a download) into /system/bin. This way you can install a custom recovery (e.g. for doing nandroid backups) and will make installing custom ROMs later a lot less painful.
A rooted stock FRF91 can already do many things, search for 'root' in the market and you can find tons of apps that require root privileges and that will run fine on stock. However, the really interesting things (like color trackball alert, firewalling, proxy support, ...) will require you to install a custom ROM.
I rooted my stock N1 with the above procedure a couple of weeks ago, and installed Cyanogen6 RC2 ROM to get some of the more advanced functionality. Been working like a charm and I've actually managed to get a lot more out of my device AND have longer battery life
Nook Rooting 101
Author’s Note: This may be long, but it provides useful info to those considering Rooting their Nook. It does NOT tell you how to root your Nook. (A sequel is intended to provide that information. But let’s start with this one.)
To the experts: feel free to post with your corrections and condemnations. The hope is that it will be improved and eventually turned into a Sticky for those new to the forum and the process.
“I got a new Nook for my birthday. What’s all this stuff about rooting?”
The Barnes & Noble Nook eReaders share some of the same electronic architecture as many smart phones and tablets. These devices work using the Android Operating system. The factory installed OS (Operating System) of the Nook limits many of the possible advanced features since it was designed primarily to be a reader. Some tech-savvy programmers have learned how to root the Nook devices to more closely emulate advanced features found on many of the Android devices.
Quick detour: Those wanting to root their Nooks are going to run into a lot of terminology. Here is a link to a glossary of many of these terms.
http://www.acertabletforum.com/foru...-dummies-guide-android-terminology-lingo.html
The number of terms addressed within this post will be a much smaller number. But these are terms that you really should understand before attempting to make changes in your Nook.
What is Rooting?
The term “root” comes from the Unix/Linux world and is used to describe a user who has “Superuser” rights or permissions to all the files and programs in the software OS. Regular users can use the software, but cannot make changes. Superuser privileges allow changes to the software code on the device.
“Rooting” means obtaining “superuser” rights to your Nook’s software. You gain the ability to load custom ROMs, install custom themes, increase performance, increase battery life, and the ability to install software that would otherwise cost extra. Rooting is essentially “hacking” your Nook.
ROMs
A stock ROM is the version of the device’s operating system that comes loaded on it when you buy it. The Nook Readers have a stock ROM.
A custom ROM is a fully standalone version of the OS, including the kernel (which makes everything run), apps, services, etc - everything you need to operate the device, except it's customized by someone in some way..
So what does the "customized" part mean? Since Android is open source, developers are free to take stock ROMs, modify them, remove garbage, optimize them, add things, and pretty much do whatever their imagination and skills allow. (And just so you know, they can also write bad programming too.)
Kernals
Another word you’ll frequently see on this site is kernel. Your Nook’s kernel controls much of the communication between the various electronic parts of the unit. An analogy is that the kernel is like programming stored in the Read Only Memory found on desktop and laptop computers. Think of the BIOS (Binary Input Output System). Some portions of the settings in this memory can be changed, such as when you install a hard disk drive. BIOS also allow other settings to be adjusted to suit the preferences of various users. But other portions of the BIOS should not be changed or your computer’s electronics cannot communicate with one another.
That is a pretty close approximation to how the kernel on your Nook is setup. Some portions of the programming were set at the factory and should not be changed. But other portions of the programming can be changed. And updates to the programming for kernels are made available.
Many of the custom ROMS you can load on your Nook will make at least some changes within the kernel of your unit. Just as there are various versions of the custom ROMs. There are versions of the programming for kernels as well. Let’s stop there for now. The subject can quickly get pretty deep. That should be enough for now.
Two Approaches
Some people who want to use one of these custom ROM systems on their Nook just install the MOD on a SD chip. (SD stands for Secure Digital.) All current Nook readers accept a Micro SD chip. A custom ROM can be loaded onto your Nook from this SD chip. Some people choose to Root their Nook with the Android Operating System operating from the SD chip. Then by powering down the Nook, they can remove the SD card. They can then restart their Nook and the regular Barnes & Noble system will operate.
At least some of the custom ROMs allow users to select whether to run the operating system (ROM) installed on the SD card, or run the native Nook operating system. You don’t need to go through the process of inserting or removing the SD card to change the OS. A series of keys are pressed as the Nook is starting to select the ROM you want it to run. This is called dual booting.
The other method of rooting consists of loading the custom ROM into the emmc. (This stands for Embedded Multi- Media Card.) This is the flash memory of your Nook that contains the original Barnes & Noble operating system. Loading the ROM into the emmc means the original B & N operating system is no longer available to run. Many advanced users report the ROMs operate a bit faster and that there are fewer problems when the Nook is run in this manner. But do remember that this means the original operating system on your Nook will no longer run. There are instructions located on this site that include steps to re-install the original system. So, this may not be as drastic a step as it might seem at first glance. There are also programs which will allow you to save all the data settings – including the OS settings currently loaded on your Nook so they can be restored later. That will not be covered in this post.
Those totally new and unfamiliar with Rooting may find it a little safer to use the SD chip method. As they gain more experience and know better what they are doing they may decide to venture out and try the emmc method for the potential advantages this method offers.
The Downside Of Custom ROMs
Of course, there are dangers of using custom ROMs which you should be aware of.
You May Void Your Warranty
As long as we’re talking about risks, this one needs to be mentioned. It's possible that custom rooting might void your warranty. The manufacturer might be able to tell that the Nook has had a custom ROM installed and not honor the warranty, in case you need to use it. Barnes & Noble hasn’t acted hostile to rooting yet, but that could change.
Something Could Go Wrong
First of all, something may go wrong with the flashing process (that's the process of installing a custom ROM) and leave your Nook in a bricked state. A Bricked Nook means it won’t operate. The chances of this are relatively low – especially if you use the SD chip method. And most of the time you can restore your Nook back to normal. Please take note of the phrase “most of the time”. You should understand that a bricked Nook is a possibility that can happen.
Try to go for a custom ROM that has been tested by time and has lots of positive feedback from users on this site. You are more likely to be successful with such a ROM.
Other Potential Problems
Custom ROMs could have bugs. Bugs are mistakes in the programming. Some are minor and won’t cause big problems. But others can be more serious.
There are appropriate locations on this site where you can post problems due to bugs. Those who post in the ROM forum will likely get an answer back and the bug will probably be acknowledged. Experienced users may even suggest methods to fix the problem.
So What‘s the Bottom Line?
Many of the people at this site have determined that the potential benefits of running these custom ROMs outweigh the risks. There are lots of experienced people here who will offer their advice if you decide to try this. But it is ultimately your responsibility to consider the risks and benefits in deciding what to do.
Quick detour: Let’s be realistic. Your Nook is never going to be an I-Phone. It was designed to be an eReader. (So was the Kindle.) Rooting can add features and capabilities to your Nook that Barnes & Noble probably won’t ever include in their stock ROMs. But rooting won’t really turn your Nook into a smart phone.
“But there are so many choices!”
Yes there are. Let’s try to understand why this is a good thing. Apple and Microsoft own the rights and hold patents on their operating systems. They jealously guard their secrets and strictly enforce their patents. And they make money selling their operating systems.
Unix is also a patented operating system. Linux is an open source operating system based on Unix. It isn’t really owned by anyone. The concept allows many users to tinker with it to improve it. The Android operating system is loosely based on Linux and is also open-source. Developers take stock ROMs and modify them to create their own unique versions. Developers of custom ROMs are able ptimize the software, unlock built-in features, and create an even better version of the Android software. The Android developers who make these custom ROMs release the software to the general public free of charge. We are fortunate to have these developers constantly working and freely sharing these custom ROMs available to everyone.
Stable versus Cool
Since ROMs are constantly being developed by many people, there are multiple flavors of ROMs available to us. Anyone who has ever done any programming knows that sometimes your new code fixes one problem but creates others. Programmers generally call these bugs.
A major portion of the ROMs may work OK, but there may be bugs in portions of the code. Groups of developers collaborate and post their versions of a MOD to be checked out and tested by other users to discover and fix all the bugs.
Then there are some general flavors of the Android system that have become established and are recognized by many. Let’s consider a few of those since you will see these mentioned frequently on this site.
Since April 2009, each Android version has been developed using a codename based on a dessert item. Released in alphabetical order, the names were Cupcake, Donut, Éclair, Froyo, Gingerbread, Honeycomb and Ice Cream Sandwich.
The Android versions distributed within the lifetime of the Nook include:
o Android 2.1 (codename Eclair)
o Android 2.2 (codename Froyo)
o Android 2.3 (codename Gingerbread)
o Android 3.0 (codename Honeycomb)
Quick detour: One further issue confusing to nubes is that at least some people will refer to a MOD by its Android number, example: 2.3. Others will use a number related to its codename, example CM7.0. Remember these people are really into this stuff. These numbers and differences really stick in their heads. Rule of thumb, if the number is below 4, it’s probably the Android number.
Let’s look at these individually. We’ll use the codenames in this list.
Eclair
Eclair is what your Barnes & Noble Nook Color runs as delivered. And even they are replacing it with Froyo.
Froyo
Many consider Froyo an improvement over Éclair. It has been in use for some time and is considered a stable platform for the Nook. Barnes & Noble is currently (as of 2/5/2012) loading this system using a method called push to update Nooks to run a stripped down version of Froyo. It is important to understand that the B & N version does not have all the features of some of the custom Froyo ROMs.
Gingerbread
The Gingerbread version that many people use has become known as CyanogenMod 7. That’s right – sometimes the system is called Gingerbread and sometimes it is called CyanogenMod 7, though many just refer to it as CM7. It was developed from the official Android Gingerbread source code, but was modified for many smart phones. There are many versions of this that will run on Nooks of various kinds. As of this writing, many consider this a good choice for a Nook operating system. It blends many recent features with at least some degree of stability. The CM 7 releases includes Bluetooth support for the Nook, meaning that you can use Bluetooth keyboards and headsets! It should be noted that Bluetooth support is still evolving.
Honeycomb
This Android system first showed up on the Motorola Xoom tablet. It offers some new features, but has not been released by the official development community. Because such development is constantly underway, some may post test versions for downloading. Be careful! This ROM is still very much in the developmental process. As an example, a few developers have been trying to take features of Honeycomb and include them in updated versions of Gingerbread. One of these versions has been given its own name: phiremod nook.
Generally, Éclair and Froyo, are considered to be stable and mostly bug free. Some versions of Gingerbread are close to being bug free, while other Gingerbread versions are still being sliced, diced, tweaked and tested. Honeycomb is still being tested. If this post stays on this site for a few months, there may be newer and more stable versions of Gingerbread. Or a stable version of Honeycomb for the Nook may become available. And some are experimenting with newer Android systems, like one called IceCreamSandwich. (Remember that this is being written in February of 2012.)
FYI: there are even new flavors of these general ROMS. There is also CM7.1 and CM7.2. And there is a version out there called CM9. So the development community is hard at work tinkering and tweaking.
Finally, as you start to explore and consider MODs for your Nook, you will often see some of these letters in the names of custom MODs.
Stable versions are those where all known issues have been addressed and resolved. This version is for everyday use.
-test / -RC versions are similar to the experimental versions, but are in the final stages of testing before being declared as "stable". There may be a few bugs left, but this version is usually stable enough for everyday use.
Experimental / -alpha versions are those where new features are being added, modified, and tweaked, and there are known bugs that are being worked on. This version is for beta / alpha testers.
Nightly builds are daily compiled builds from source. This version therefore has the latest features & tweaks, but it is also the mostly likely to have bugs and issues. These versions are probably poor choices for nubes.
So which do you want to use? Éclair came on your Nook. And currently, Barnes and Noble is pushing their stock version of Froyo out over the Internet automatically to your Nook. Gingerbread – going by the name of CyanogenMod7.0 – may be a good choice for starting out, as of the date of this writing. Yes, you can upgrade this to later versions as you become familiar with what is out there and how to root your Nook.
End of the lesson.
Hope this information was helpful. Happy Rooting!
Great info, and sure to be helpful to many. Here are a some suggestions:
A description of CM versions might be helpful, linking CM versions to Android versions.
CM 7.1 is the latest stable. You might mention nightlies, and the 7.2 RC0 Mirage release.
No mention of ICS? With all the buzz lately, I'd definitely include it in the list of Android versions, and mention it with CM9.
I think there are three choices:
Root stock B&N firmware.
Dual-boot with CM (or similar) on SD (external).
Over-write eMMC (internal) with CM (or similar).
I see a lot of confusion between these, and a lot of misconception that you have to root stock before loading either of the other options.
Was the NOOK color originally shipped with Eclair? I thought they were Froyo from day one. I know a lot of us were disappointed when B&N 1.4.1 shipped as Froyo.
Thanks for the feedback. Remember, this is Nook 101, not 201. I didn't want to provide so much info that it left folks feeling overwhelmed. I suggested they begin with CM7.0. I mentioned CM7.1 and CM7.2. This sucker is already long. I had to narrow the focus to keep from turning it into a novel.
ICS is Ice Cream Sandwich, isn't it? I mentioned that CM9 is under development, but I'm pretty sure nubes should not start with that. Besides, my understanding is that it is still very much in the RC testing phase. Isn't that right?
I said there were two approaches. But I said some MODs allow for dual booting. Again, I didn't want to overwhelm.
I read in two different places (not on XDA) that Eclair was the original OS for the Nook. I think they began to push Froyo in the Fall of 2011.
You will also note that I did not cover the various models of the Nook at all. And I didn't mention the change in the hardware of Nook Color that has happened in the past two or three months. I didn't feel qualified to explain those. I'm still a relative nube myself.
BO
First, thanks for all the hard work with the words. I saw your initial posts and can only figure you are a writer, to be so willing to set everything you have done down in an orderly manner.
I'd like to add a fourth choice to bobstro's list of possibles (and I am not so adept at all this Nooker stuff myself that I believe it is too much for beginners):
Triple boot using Racks' great info and files here in the developer's wing. That way a learner can get a very stable CM7 GB (Kang build) a working - and for an "in process" ROM - quite stable CM9 (ICS) both on one SD card, and still have an untouched B&N stock on their NC.
Believe me; it's not too hard to set up; it has the best of all worlds. And it increases the fun factor by a million!
You know what root is but I don't get a clear picture of why it is called root.
In the unix/linux world if you are a superuser you have root access. Rooting a device is gaining root access to the device. With root access there are no restrictions to what you can do to the device. Including brick it.
BTW: Bricking a device is just that. Turning a beautiful orchestration of electronic components into a paperweight or, brick.
I think I included that the term rooting comes from the unix/linux world and the business about the superuser. See, that's the problem with something so long. It's easy to miss stuff. But I wanted to be clear about some of the essential stuff. It's a balancing act. Anyway, thanks for the input.
Yes. I saw why it was called bricking. I can add that.
BO
Thanks for the suggestion. I'll look into Rack's method and see whether I can include it. Again - this post is intended to be 101, not 201 info.
I wrote some computer manuals for teachers at least for a few years. It's been awhile since I did that. I try to be clear. The problem is that sometimes I try to keep it so simple that I often go overboard - result - very long. Verbose is the word. I could never have worked for Reader's Digest.
I see that nearly 150 people have at least looked at the file (maybe at least scrolled through it), but I haven't seen all that much feedback so far.
Some are making suggestions for improvement. My concern really is have I been accurate about what I actually did include?
BO
BO
You start using the term MOD without having defined it partway down.
I found this bit potentially confusing:
FYI: there are even new flavors of these general ROMS. There is also CM7.1 and CM7.2. And there is a version out there called CM9.
What is CM if this is 101?
Thanks. I'll try to adjust the issue you raised about using MOD before it has been defined. I believe I did explain CM was CyanaMod, but I'll double check it.
BO
It's a sequence thing. You use CM before CyanogenMod, and don't link them together. You might try something like CyanogenMod (CM) to link them.
Maybe a mention of OTA updates?
Gotcha. I'll see what I can do.
Thanks!
BO
This is just purely a great, great post, especially for newbies.
Keep it up, bachon.
Back to bachon, here's a few things
1. "“Rooting” means obtaining “superuser” rights to your Nook’s software. You gain the ability to load custom ROMs, ....."
Rooting has nothing to do with loading custom ROM. In order to be able to install/loading custom ROM, the bootloader must be unsigned/unchecked. Short way of saying, you can root but it doesn't mean after root, you can install custom ROM. It's a function of the bootloader.
2. Personally, I think and I do believe some devs. think that the term "rooting" is only applied to the stock ROM/OS. When you installing/running a custom ROM, the term "rooting" is irrelevant and should not be used (since we already able to access the root directory of that OS/ROM)
3. Not a biggie, but pls rename "Kernals" to "Kernels"
The other way of saying the kernels: are the firmware drivers that handle all the communications between the hardware and the operating system.
4. If you have the "Two Approaches" sections, you should also have "Three Approaches"
5. In the "Downsides of Custom ROMs" you mentioned it will void the warranty. This is only true if you install a custom ROM in eMMC. If you're running one off uSD, you know by removing the uSD, it's back to stock. No warranty voided.
6. Since you listed "o Android 3.0 (codename Honeycomb)", you should add "Android 4.0.x (codename Ice Cream Sandwich), just to complete
7. I do think we should have a short paragraph about what CyanogenMod team and their codenames. I don't want to go way back but CM7, the "7" denotes for Gingerbread builds and on-going "9" is for Ice Cream Sandwich. Why do they skip "8"? 'Cuz "8" was reserved for Honeycomb.
I can't pass out the cigars yet, huh?
votinh said:
This is just purely a great, great post, especially for newbies.
Keep it up, bachon.
Thanks for the kind words, votinh.
Mod, you should sticky this thread.
Back to bachon, here's a few things
1. "“Rooting” means obtaining “superuser” rights to your Nook’s software. You gain the ability to load custom ROMs, ....."
Rooting has nothing to do with loading custom ROM. In order to be able to install/loading custom ROM, the bootloader must be unsigned/unchecked. Short way of saying, you can root but it doesn't mean after root, you can install custom ROM. It's a function of the bootloader.
2. Personally, I think and I do believe some devs. think that the term "rooting" is only applied to the stock ROM/OS. When you installing/running a custom ROM, the term "rooting" is irrelevant and should not be used (since we already able to access the root directory of that OS/ROM)
I'm afraid my understanding for what you are saying is insufficient to write this clearly. Can you say more about this to clarify things? I thought it was obtaining superuser rights that gave users the ability to load ROMs and other software on their Nooks. I'm going to need more information to correct this.
3. Not a biggie, but pls rename "Kernals" to "Kernels"
The other way of saying the kernels: are the firmware drivers that handle all the communications between the hardware and the operating system.
Oops! Good proof reading. Thanks. Is it OK to just add your addition to the final post, or is the rest of what I have said wrong?
4. If you have the "Two Approaches" sections, you should also have "Three Approaches"
OK. Here's my current understanding. 1. Running a custom MOD from the SD Card. 2. Installing a custom ROM in eMMC. 3. Having a dual boot capability.
Someone mentioned having two different ROMs loaded on an SD card. Does this allow the original Nook OS to run with no SD card inserted?
Any clarification needed there? I'm looking to make this VERY clear for newbies.
5. In the "Downsides of Custom ROMs" you mentioned it will void the warranty. This is only true if you install a custom ROM in eMMC. If you're running one off uSD, you know by removing the uSD, it's back to stock. No warranty voided.
Hmmm. Is there no way running or updating a ROM can brick a Nook? It seems to me that someone trying to upgrade from one custom ROM to another could follow the wrong steps and trash the contents of the emmc. Am I wrong?
6. Since you listed "o Android 3.0 (codename Honeycomb)", you should add "Android 4.0.x (codename Ice Cream Sandwich), just to be complete
7. I do think we should have a short paragraph about what CyanogenMod team and their codenames. I don't want to go way back but CM7, the "7" denotes for Gingerbread builds and on-going "9" is for Ice Cream Sandwich. Why do they skip "8"? 'Cuz "8" was reserved for Honeycomb.
Click to expand...
Click to collapse
I wondered what happened to CM8. Thanks for that. I'm so new here that I'm not sure I can really explain the CyanogenMod team and their codenames. Care to give me some tips? It would really help.
While I'm asking: why and when was the codename for Gingerbread changed to CyanogenMod?
I don't mind including Ice Cream Sandwich/CM9, but I don't know that much about it. Input from the seasoned veterans would help.
Frankly, most of the suggestions I've received seem to want to add more information. I wanted things to be clear without overwhelming. Truth is, I cannot write clearly about things I don't quite understand.
If folks will share and explain the info to me then I'm more than willing to try to put it in a form that neophytes can understand.
Finally, MOD and ROM seem to be used interchangeably by many in the Nook forums. Anybody willing to provide their 2 cents worth on the difference?
Thanks
BO
I'm afraid my understanding for what you are saying is insufficient to write this clearly. Can you say more about this to clarify things? I thought it was obtaining superuser rights that gave users the ability to load ROMs and other software on their Nooks. I'm going to need more information to correct this.
Click to expand...
Click to collapse
Obtaining superuser rights is NOT enough to load custom ROMs on the device. Take a look at the Nook Tablet as an example.
Obtaining superuser rights is enough to install other applications. It is still not 100% true. Take side-loading feature as an example, some devices, even rooted, still cannot sideloading.
OK. Here's my current understanding. 1. Running a custom MOD from the SD Card. 2. Installing a custom ROM in eMMC. 3. Having a dual boot capability.
Click to expand...
Click to collapse
What you said is MOST common mistake and should be changed.
Boot from eMMC along with running off uSD is NOT dual-booted, at least not TRUE dual-booted. People here love to call it as "dual-boot" so I go with that, but it isn't, really.
True dual-boot is one ROM in eMMC and another ROM also in eMMC. Same applied for uSD.
This is a true dual-boot:
http://forum.xda-developers.com/showthread.php?t=1448186
Someone mentioned having two different ROMs loaded on an SD card. Does this allow the original Nook OS to run with no SD card inserted?
Click to expand...
Click to collapse
The link I just provided up there is exactly what it for.
And yes, it is INDEPENDENT to eMMC. You can leave stock OS intact.
Hmmm. Is there no way running or updating a ROM can brick a Nook? It seems to me that someone trying to upgrade from one custom ROM to another could follow the wrong steps and trash the contents of the emmc. Am I wrong?
Click to expand...
Click to collapse
Dealing with eMMC, yes, if you screw it up, then you got what you have. If you only dealing with uSD and leave eMMC untouch, everything on eMMC should still be there, cleanly.
Note: the NC is virtually unbrickable unless the hardware parts broken.
While I'm asking: why and when was the codename for Gingerbread changed to CyanogenMod?
Click to expand...
Click to collapse
Gingerbread is Android mobile OS codename by Google.
CyanogenMod is a developer team. Their codename gets their teamname and as I said "7" is Gingerbread version of their work.
Note: CM7 widely known for custom ROMs, not only for NC but for many other devices
Link: http://www.cyanogenmod.com/
See their device list.
Finally, MOD and ROM seem to be used interchangeably by many in the Nook forums. Anybody willing to provide their 2 cents worth on the difference?
Click to expand...
Click to collapse
I rarely see MOD as refer to ROM but I would guess, MOD is shortcut for Modification/Modified.
ROM usually refers to OS.
Votinh (or anyone else),
When you write computer code, you have to break the instructions down into step-by-step commands. Computers have no common sense to guess what you’re telling them to do. You can’t just say, “Print”. You have to be a whole lot more specific.
I’m trying to get you to do that here. Because you (and many others on this site) understand this stuff so well, you’re using broader statements like “It’s a function of the bootloader.” I’m asking you these questions to break it back down into the step-by-step stuff. If you can get me to understand it, I think I can write it down so many other nubes will understand it and MAY stop bugging everybody by asking over and over. Please be patient and bear with me.
OK. Let’s take these one at a time. Rooting first:
You said:
“Rooting has nothing to do with loading custom ROM. In order to be able to install/loading custom ROM, the bootloader must be unsigned/unchecked.”
“Short way of saying, you can root but it doesn't mean after root, you can install custom ROM. It's a function of the bootloader.”
First, I’ve been under the impression that rooting is an absolutely essential first step in order to be able to do things like loading a custom ROM. It isn’t all that is required, but it is the FIRST requirement. Isn’t that correct?
Think of a Nook straight out of the box. If I stick a formatted SD chip in my Nook with no OS, the Nook loads the stock OS. If I stick a SD chip imaged using “generic-sd-v1.3.zip” and with the zipped archive, “Encore_CM72-MIRage-01262012.zip” loaded on the SD chip, then the Nook will expand the “MIRage*.zip” and run the CM7.2 custom ROM. Isn’t that right?
Which of these zipped archives (if any) actually contains the instructions that roots the Nook?
Which of these zipped archives (if any) actually contains the instructions that unchecks the bootloader?
Which of these zipped archives (if any) contains the instructions that alters the bootloader?
Which of these zipped archives (if any) actually loads the custom MOD?
Is it accurate to say that rooting the device is only the first step necessary before the bootloader can be unchecked?
If so, is it also accurate to say that the installation process for any custom ROMs must then uncheck and alter the bootloader before any custom ROM can be installed or loaded?
My way of thinking of it is as follows: rooting only unlocks the first lock on the device. Then the installation process for the custom ROM must unlock other locks before a custom ROM can be loaded or installed.
BO
bachon said:
[...] First, I’ve been under the impression that rooting is an absolutely essential first step in order to be able to do things like loading a custom ROM. It isn’t all that is required, but it is the FIRST requirement. Isn’t that correct?
Click to expand...
Click to collapse
No, that is not correct. Rooting is providing root access on a (in a sensible case) unrooted device. This is typically your stock firmware. You can root a NC which shipped with unrooted (locked) B&N 1.2, 1.3 or 1.4.1 firmware, for example. You can also root a NT which ships with 1.4.x firmware as well.
Loading alternate firmware is where the locked bootloader comes in. On the NC, with no locked bootloader, independent of rooting, you can install alternate firmware, either to SD card (leaving the internal eMMC firmware, rooted or not, unchanged), or over-write the internal eMMC firmware with something new. I'd expect that something new to be rooted in the case of alternate firmware, but I suppose it doesn't have to be. On the NT, this is all complicated (if B&N had their way, impossible) because of the locked bootloader, but progress is being made working around this. See the NT forums for details.
If you're going to load alternate firmware on a NC, rooting is not a requirement. In fact, a lot of people like dual-booting (sorry, the term is descriptive enough without getting into semantics, and I've yet to hear a better term) something like CyanogenMod off of SD while preserving their unrooted stock B&N firmware for "warranty purposes", since they are completely independent of each other. Boot off of SD and you get CM. Pull the SD out and boot and you get B&N.
To make it short, bachon,
bootloader is essentially a piece of low-level code that resides on the non-volatile on boards that handling how the system starts up and how it behaves during powering up. The other way to say: it is the very first thing to run soon the power provided.
If it is "signed/locked" then you have a hard time to manipulate it such loading custom ROM, even preventing alter the stock recovery, and in some case, not even allow us to touch the system kernel.
Think of a Nook straight out of the box. If I stick a formatted SD chip in my Nook with no OS, the Nook loads the stock OS. If I stick a SD chip imaged using “generic-sd-v1.3.zip” and with the zipped archive, “Encore_CM72-MIRage-01262012.zip” loaded on the SD chip, then the Nook will expand the “MIRage*.zip” and run the CM7.2 custom ROM. Isn’t that right?
Which of these zipped archives (if any) actually contains the instructions that roots the Nook?
Which of these zipped archives (if any) actually contains the instructions that unchecks the bootloader?
Which of these zipped archives (if any) contains the instructions that alters the bootloader?
Which of these zipped archives (if any) actually loads the custom MOD?
Click to expand...
Click to collapse
The "generic...." is just a container.
The "encore-...." is the actual custom ROM.
If so, is it also accurate to say that the installation process for any custom ROMs must then uncheck and alter the bootloader before any custom ROM can be installed or loaded?
Click to expand...
Click to collapse
Absolutely true.
---------- Post added at 10:21 AM ---------- Previous post was at 10:20 AM ----------
Oh, and bobstro have provided a very good example of it, down to the very specific case.
Bobstro,
So a lot of people who say "I rooted my Nook" aren't correct. They may have loaded another OS, like CyanogenMod 7.2, but that doesn't mean that they've necessarily rooted their Nook. Is that correct?
These folks would be more accurate to say "I hacked my Nook."
Is that closer to being accurate?
How and why did so many people start calling it rooting? I know about the root user in Unix. Do some of the OS installations go the extra step of actually rooting the Nook?
BO
I think you spelled Bacon wrong.
bachon said:
Bobstro,
So a lot of people who say "I rooted my Nook" aren't correct. They may have loaded another OS, like CyanogenMod 7.2, but that doesn't mean that they've necessarily rooted their Nook. Is that correct?
These folks would be more accurate to say "I hacked my Nook."
Is that closer to being accurate?
How and why did so many people start calling it rooting? I know about the root user in Unix. Do some of the OS installations go the extra step of actually rooting the Nook?
BO
Click to expand...
Click to collapse
I don't mean to jump on bobstro's toe, I hope he allows me to answer the question.
1. Again, I repeat, the term "root" should only be applied when you're dealing with STOCK ROM.
2. If you are running CM7 or any custom ROM such MIUI, .... you DON'T NEED to root since it ALREADY allows you accessing the root directory. Therefore "rooting" process is no need.
3. If you are running any custom ROM, ideally, you should not say "I'm rooting my device".
Why people using that? They say so and no one correct them so the term spreads.
So now that Jelly Bean for Bionic is out and there is a root method that works, what should be kept and discarded as far as apps go such as, ROM Manager, superuser, superuser#, SuperSU, and VoodooOTA Root Keeper, Bootstrap, safestrap.
Obviously I do not know, and many may not also know, which of these apps is essential and which is outdated. Is there a forum that I missed, if so I apologize. I can guess that Voodoo should be kept because Motorola may, as unlikely as it may seem, might update Bionic with a fix or other small software update.
Is there anyone making ROMS that work with Jelly Bean 4.1.2, ? I have been out of the searching for some months and now not knowing where to look for the best answer to these questions.
Well the Liquid Smooth 2.2.1 and the CM10.1 are built on Kexec so they will work on the JB OTA kernel, I'm running both on the OTA rooted .22 build. I'm reading that some odd functionality seems to be happening but they are already being ironed out in the nightly builds. Anything not on a Kexec build i would assume will not work on your JB OTA kernel.
Just keep reading the posts and help out with the nightlies (load new ones and report any bugs or that its all good) b/c that helps them fix the bugs faster and faster to a new stable ROM.
As far as whats what to keep, I'm keeping Titanium Backup, OTA root keeper, Superuser (obviously) I'm on Safestrap v3.11 to flash ROMs
As for ROMs... the JB 4.2.2 ROMs.. Liquid Smooth, CM10.1 and any other JB ROMs i would think would be ported over. Just keep an eye out. People are all giddy over the Bionic again so im sure it will be strong for awhile longer.
Well I know what's next for my Bionic. After I've jumped up an down on it a bunch of times I plan to toss it in my driveway and drive over it...then backup and do it again a few times.
For me it's been a complete disaster and still have never got my lapdock to work right.
Middle of June my contract is up and I'm going for the Galaxy Note II. Depending upon what kind of deal I can get out of VZW I might switch carriers too.
June!? I might be the harbinger of bad news but the Bionic was released in September of 2011 so that means if you got the Bionic at launch, you cant upgrade till September. They used to let you update at the 20 month mark instead of going to the full 24 months. Well 2 weeks ago Verizon announced that they will no longer be letting people upgrade early. Hence you have to go the full 24 months now.
Eric
Eric214 said:
Well the Liquid Smooth 2.2.1 and the CM10.1 are built on Kexec so they will work on the JB OTA kernel, I'm running both on the OTA rooted .22 build. I'm reading that some odd functionality seems to be happening but they are already being ironed out in the nightly builds. Anything not on a Kexec build i would assume will not work on your JB OTA kernel.
Click to expand...
Click to collapse
Someone correct me if I'm wrong, but the fact that a ROM is based off KEXEC means that those ROM's don't care what base kernel you're running, whether you're on the ICS or JB OTA. Those ROMs bring in their own kernel that's booted with KEXEC. Safestrap handles the KEXEC process, and Safestrap works properly on the JB OTA so there's nothing to really worry about.
Also I'm not even sure how you'd ever use ROM Manager on the Bionic. Especially if you have Safestrap installed.
Hey, I just updated and established root with ubuntu method. Now I want to install Liquid (I hate the feel of stock Bionic) but when I reboot, and hit menu for safestrap, it just boots into android... I have deleted TWRP and safestrap folders, uninstalled and reinstalled, but to no avail. any ideas?
Eric214 said:
June!? I might be the harbinger of bad news but the Bionic was released in September of 2011 so that means if you got the Bionic at launch, you cant upgrade till September. They used to let you update at the 20 month mark instead of going to the full 24 months. Well 2 weeks ago Verizon announced that they will no longer be letting people upgrade early. Hence you have to go the full 24 months now.
Eric
Click to expand...
Click to collapse
MyVerizon still says I can upgrade at discount on 6/6/13. I probably won't right away because I want to wait for the Motorola/Google X phone.
Yeah i know and mine still says May 14th but good luck for me getting to update then. My guess is they haven't updated their systems yet. Likely they have instructions to disreguard that and go the full 2 year from start of contract.
If you can update early still then AWSOME! 1 other thing is maybe they are grandfathering in people who are close? like over 16 or 18 months into the contract so they are only 2-4 months from the early update. IDK I just know that 2 weeks or so ago VZ said they are done with allowing ppl to update at 20 months and that you must now go to the full 24 months or just new contracts will get the full 24 months till upgrade?
Eric
Thanks for the info, I am interested in trying some of the Roms you mentioned, so correct me if I am wrong please but I need safestrap, not bootstrap to load a Rom on the side of the JB stock ROM. I am rooted so no problem there.
Thanx in advance
Sqwaller said:
Thanks for the info, I am interested in trying some of the Roms you mentioned, so correct me if I am wrong please but I need safestrap, not bootstrap to load a Rom on the side of the JB stock ROM. I am rooted so no problem there.
Thanx in advance
Click to expand...
Click to collapse
Yes you have to use safestrap and you must install Liquid in the rom-slot 3 or it wont work. Now on the safestrap. I think you also need to have SS v3.11 for Liquid so make sure you have that one. Once you install it make sure you open the Safestrap app and install recovery then reboot. Once it starts to boot up and you see recovery, make sure you're tapping the setting button, not the screen, and just keep tapping it till you feel the vibration then it will enter recovery.
Eric
Eric214 said:
Yes you have to use safestrap and you must install Liquid in the rom-slot 3 or it wont work. Now on the safestrap. I think you also need to have SS v3.11 for Liquid so make sure you have that one. Once you install it make sure you open the Safestrap app and install recovery then reboot. Once it starts to boot up and you see recovery, make sure you're tapping the setting button, not the screen, and just keep tapping it till you feel the vibration then it will enter recovery.
Eric
Click to expand...
Click to collapse
OK sounds good, will work on that this weekend.
Thank You very much I really appreciate the help.!
NewtG
Eric214 said:
Yes you have to use safestrap and you must install Liquid in the rom-slot 3 or it wont work. Now on the safestrap. I think you also need to have SS v3.11 for Liquid so make sure you have that one. Once you install it make sure you open the Safestrap app and install recovery then reboot. Once it starts to boot up and you see recovery, make sure you're tapping the setting button, not the screen, and just keep tapping it till you feel the vibration then it will enter recovery.
Eric
Click to expand...
Click to collapse
I am a little confused about the setting for the 1,2 or 3 GB is this on the external SD or the internal SD that they are asking about. I have a 32 gb card installed but stock JB ROM I have all my usual apps that take up about 3.5 gb of internal space. And can you tell me if the addition of this other ROM slows down my stock ROM games?? no big deal but my son likes to play some multiplayer games with me on his droid x.
You really should go to hashcodes site and read about safe strap. It is asking the amount of space you want to allocate for apps on the phones internal memory. It will show you how much total spacee you have for all 4 room slots.
---------- Post added at 01:22 AM ---------- Previous post was at 01:14 AM ----------
if you use a lot of apps then you would want to use 3 gigabytes if you use few apps then you want to use one gig.for example my Bionic has a 16 gig internal memory which is allocated an unusable for safestrap which leaves me eight gigs to use for my rom slots. it will use roughly one gig for the system and then what you allocate for data space for apps. so since I have eight gigs everyone get partition I use really uses two gigs. hope this helps
projektorboy said:
Someone correct me if I'm wrong, but the fact that a ROM is based off KEXEC means that those ROM's don't care what base kernel you're running, whether you're on the ICS or JB OTA. Those ROMs bring in their own kernel that's booted with KEXEC. Safestrap handles the KEXEC process, and Safestrap works properly on the JB OTA so there's nothing to really worry about.
Also I'm not even sure how you'd ever use ROM Manager on the Bionic. Especially if you have Safestrap installed.
Click to expand...
Click to collapse
KEXEC kicks out the existing (Motorola) kernel after the system is booted, and starts a new boot sequence with a new kernel. The issue with this system is the availability of specific hardware drivers for the custom kernel.
The KEXEC kernel from your custom ROM does not have all the specific hardware drivers needed for, for example, hardware accelerated graphics, because these drivers are generally not available (closed source), and older available drivers are not compatible with newer kernels.
Now that we have a full JB ROM, custom ROM bakers can borrow the drivers and use them in their creations.
This should mean that new revisions of your custom rom can be made fully functional now. Common missing links that can now be completed are: native camera app and hardware accelerated video playback. I also heard Bluetooth may have been a problem but I don't use it.
Hey, I'm having issues getting into safestrap. I have it installed, with root, on OTA, and it boots to the option to go to it, but when I press menu it goes straight to DROID and boots.... Ideas?
Sometimes hitting menu doesn't catch. tap it till you feel the phone vibrate some. I think the spot to hit really is just above the menu key and the actual screen in the black area. Just tap it a few times till you feel it vibrate and it will boot in to the recovery.
Eric214 said:
Sometimes hitting menu doesn't catch. tap it till you feel the phone vibrate some. I think the spot to hit really is just above the menu key and the actual screen in the black area. Just tap it a few times till you feel it vibrate and it will boot in to the recovery.
Click to expand...
Click to collapse
IT does vibrate, that's why im so confused. I used it for cm10.1 before, but I cant even get into SS now!
EDIT: I just noticed it is not creating a safestrap or TWRP folder... I have root... WTH?
Did you try uninstalling it and reinstalling it? Then install recovery. If that doesnt work are you truely rooted and not partially rooted? Have you installed Titanium BAckup and was it granted root?
Eric214 said:
June!? I might be the harbinger of bad news but the Bionic was released in September of 2011 so that means if you got the Bionic at launch, you cant upgrade till September. They used to let you update at the 20 month mark instead of going to the full 24 months. Well 2 weeks ago Verizon announced that they will no longer be letting people upgrade early. Hence you have to go the full 24 months now.
Eric
Click to expand...
Click to collapse
Everyone with an upgrade date prior to 9/1/2013 is being allowed to keep their current date (source is here). So he will be fine in June.
well that is awsome news!
I've never owned a Nexus/Google phone, how long would you all guess it's going to take to root the Nexus 6?
Thanks! :fingers-crossed:
Kidding I hope
Pyros2008 said:
I've never owned a Nexus/Google phone, how long would you all guess it's going to take to root the Nexus 6?
Thanks! :fingers-crossed:
Click to expand...
Click to collapse
Before you even get it
Sent from my A0001 using XDA Free mobile app
Nope, the first time I rooted was a month ago, my Note 3. I take it the device can be rooted off the bat.. or there something else I am missing?
Give Chainfire a couple hours with the phone
Pretty sure the process will be similar to other Nexus devices... Fastboot oem unlock, etc, etc.
http://phandroid.com/2014/11/17/nexus-6-lollipop-root/
all hail king chainfire?
kgeissler said:
http://phandroid.com/2014/11/17/nexus-6-lollipop-root/
Click to expand...
Click to collapse
That has 6 nexus devices with root. Bit not the nexus 6.
I would make sure to wait until Google releases the factory image before rooting just in case something goes wrong
I'm pretty sure that the factory images have to be out as he has to create a modified kernel for the N6 for superuser to work on 5.0.
lordgodgeneral said:
I'm pretty sure that the factory images have to be out as he has to create a modified kernel for the N6 for superuser to work on 5.0.
Click to expand...
Click to collapse
I think he just patches the existing kernel so don't think he would need images. Think being the key word there as I don't know for sure how it works exactly.
You don't need a developer to root a nexus. Boot into the bootloader, connect to your computer, run: fastboot oem unlock, then install the recovery of your choice via fastboot (fastboot flash recovery blahxxx.img), then just flash whatever superuser you want (e.g. SuperSU)
Sent from my XT1053 using Tapatalk
bongostl said:
You don't need a developer to root a nexus. Boot into the bootloader, connect to your computer, run: fastboot oem unlock, then install the recovery of your choice via fastboot (fastboot flash recovery blahxxx.img), then just flash whatever superuser you want (e.g. SuperSU)
Sent from my XT1053 using Tapatalk
Click to expand...
Click to collapse
Sorry but this is no longer accurate. First off, there are no custom recoveries yet. Second, lollipop requires additional work arounds for root other than just flashing superuser.
akellar said:
Sorry but this is no longer accurate. First off, there are no custom recoveries yet. Second, lollipop requires additional work arounds for root other than just flashing superuser.
Click to expand...
Click to collapse
Hm? I'm running oneplus one with root on lollipop. All I had to do was just flash supersu in recovery.
Hopefully we can see a twrp on nexus 6 soon.
Sent from my A0001 using Tapatalk
zephiK said:
Hm? I'm running oneplus one with root on lollipop. All I had to do was just flash supersu in recovery.
Hopefully we can see a twrp on nexus 6 soon.
Sent from my A0001 using Tapatalk
Click to expand...
Click to collapse
It's likely not a complete build with the SELinux improvements that google made to the kernel. You need to modify the kernel on lollipop to have root so your one plus probably just has a ROM not a full image of the lollipop on it. Also as stated earlier you can't root anything without the factory image posted by google for the nexus. Then the developers can have at it. Until your happens we are just left waiting.
Pilz said:
It's likely not a complete build with the SELinux improvements that google made to the kernel. You need to modify the kernel on lollipop to have root so your one plus probably just has a ROM not a full image of the lollipop on it. Also as stated earlier you can't root anything without the factory image posted by google for the nexus. Then the developers can have at it. Until your happens we are just left waiting.
Click to expand...
Click to collapse
SELinux is currently permissive and yep its built off CM12 sources. But to answer OP's question, probably won't take too long but no ETAs.
zephiK said:
SELinux is currently permissive and yep its built off CM12 sources. But to answer OP's question, probably won't take too long but no ETAs.
Click to expand...
Click to collapse
Then that's why you can flash it in recovery. Normally you wouldn't be able to if it wasn't changed.
Chainfire said:
On LPX13D, SELinux, and root
As promised, here are some more details about the current situation.
Why it breaks
Google has really put some effort into better securing Android, and we've seen a lot of SELinux related commits to the AOSP tree over the past months. There is some disconnect between the AOSP tree and actual L preview builds, some things from AOSP are not in the L preview build, and vice versa. Ultimately, it's a pretty good bet these things will mostly align, though.
On most devices and firmwares, SuperSU's daemon is started by the install-recovery.sh service script that runs at system boot time, as user root with the init context. This is what the daemon needs to function.
Recently, they've started requiring all started services to run in their own SELinux context, instead of init. Developers and security guys following AOSP have known this was coming; AOSP builds have been logging complaints about this specific service not having its own context for a while now.
Now this script runs as root, but as the install_recovery context, which breaks SuperSU's operation, as it is a very restrictive context.
In the last AOSP build I have tried (a few weeks old), there were a fair number of other holes that we could use to launch the daemon. At first glance(!), it seems those have all been closed. An impressive feat by the guys working on this, if it proves true.
How to fix it
To fix root, all that really had to be done was ensure the daemon's startup script is run at boot as the root user with the init context.
There are multiple ways to do this, but unfortunately for now it seems that it does require a modified kernel package (changing the ramdisk).
In the modified kernel packages I've posted for the Nexus 5 and Nexus 7, the daemon's startup is fixed by commenting out the line in init.rc that forces the install-recovery.sh script to run as the install_recovery context, so now it runs as init again, and all is well.
Repercussions
As stated above, it seems for now that modifications to the kernel package are required to have root, we cannot attain it with only modifications to the system partition.
Combine that with a locked bootloader (and optionally dm-verity) and a device becomes nigh unrootable - exactly as intended by the security guys.
Exploit-based roots are already harder to do thanks to SELinux, and now because of the kernel requirements for persistent root, these exploits will need to be run at every boot. Exploits that make the system unstable (as many do) are thus out as well.
Of course, this is all dependent on OEMs implementing everything exactly right. If a certain OEM doesn't protect one of their services correctly, then we can leverage that to launch the daemon without kernel modifications. While I'm fairly certain this will be the case for a bunch of devices and firmwares, especially the earlier L firmwares, this is not something you should expect or base decisions on. It is now thus more important than ever to buy unlocked devices if you want root.
It might also mean that every firmware update will require re-rooting, and OTA survival mode will be broken. For many (but far from all) devices we can probably automate patching the kernel package right in the SuperSU installer ZIP. We can try to keep it relatively easy, but updating stock firmwares while maintaining root is probably not going to work as easy and fast as it did until now.
Apps need updates
Unsurprisingly, with a new major Android release, apps will need updates. None more so than apps that go beyond the Android API, as root apps do, but even some non-root apps will be affected by the security changes.
As one example, someone posted in the SuperSU thread of a kernel flashing app that didn't work. From the logcat you could see that it was looking for partitions in /dev/block from its normal non-root user and non-init context. That used to be possible, but now it is restricted: normal apps no longer have read access there.
The solution for that app is actually quite simple: list the /dev/block contents using root instead. But simple solution or not, the app will still need to be updated.
By far most root apps should be updateable for L without too much issue. There are indeed exceptions that will need some special care, but those are rare.
Permissive vs enforcing
The kernel packages I posted for the Nexus 5 and 7 LPX13D firmware keep SELinux mostly set to enforcing. I say mostly, because SuperSU actually switches a small part of the system to permissive, so apps calling su can do most things without much interference. The details on this are lengthy (yes, your apps will be able to modify policies as well if needed, which should be rare), and I will document these for other developers after L retail release, assuming it will all still work at that time.
Alternatively, you can set the whole system to permissive or otherwise disable SELinux. There are other kernel packages released that indeed do this. The advantage here is that it instantly fixes some apps' issues, as the SELinux based restrictions have all gone the way of the dodo. The disadvantage here is that you've just shut down a major part of the security system of the device.
Some would argue that a device with an unlocked bootloader, root, encrypted modem firmwares of which nobody really knows what they're doing, etc, is inherently insecure, and thus disabling SELinux doesn't make much difference.
I personally disagree with this. While I do agree that these things weaken security down from the ideal level, I would still not disable more security features than I absolutely need to. Just because you cannot eliminate all attack vectors, is no reason to just completely give up on defending against them.
It is of course your own choice if you want to run a permissive system or not. I will strive to keep everything working in enforcing mode though, and I hope other root app developers will do the same - as stated earlier in the post, I believe this is still possible.
(everything in this post is subject to change for retail L release, obviously)
Click to expand...
Click to collapse
https://plus.google.com/+Chainfire/posts/VxjfYJnZAXP
http://www.xda-developers.com/android/supersu-beta-2-23-lollipop/
Pilz said:
Then that's why you can flash it in recovery. Normally you wouldn't be able to if it wasn't changed.
Click to expand...
Click to collapse
Good news everyone, starting one of the upcoming SuperSU updates, modified kernels will no longer be needed for root on Android 5.0 ... !
Click to expand...
Click to collapse
https://twitter.com/ChainfireXDA/status/535253476021116928
Long story, but after travails with an Amazon-purchased Oneplus 9 Pro due to it being locked (T-Mobile!) and them refusing to unlock it....
I went to OnePlus and got myself a OnePlus 10 Pro Unlocked. Still have the T-Mobile sim, though.
My question....
I have been out of the rooted phone scene for some time. I had a Oneplus 2 rooted and a Samsung Note 4 and 5 rooted. But things are different now, I'm gathering. Plus this is a new phone and I don't want to toss away hundreds of dollars by bricking it.
I used TWRP back in the day. Flashed many a custom rom back then. But with this OnePlus, I already unlocked it which... is that the same as rooting it? And what are the benefits of rooting / flashing roms vs just going with what is currently on this US phone (Oxygen 13 but not 13.1 yet)? I kinda want to see TWRP on here, and back up my whole set up into files I can then copy to my computer(s) for safety's sake. At least I liked that feature when I had it w/ the OP 2 and others.
Trying to get back up to speed in the world of rooting as it stands now.
Thanks.
TWRP on this device is really, "make of it what you will." It doesn't fully support this phone officially, and the leaked versions don't support device decryption, so you'll be forced to not use a passcode on your phone.
You don't need TWRP anymore, you just need to be careful and know what you're doing. There's guides for every model here, although they're all basically the same. Try to avoid flashing anything from your PC to the phone, just flash inside Magisk and BOOT images.
From my knowledge the reason for this is there's hidden partitions from OPPO all over the filesystem and normal flashers don't take this into account, anyone just trying to flash a full zip has bricked.
Which leads me to, there's no full recovery for this device that's free. If you brick a file and end up boot looping both slots, you're gonna have to pay for a restore. Even with TWRP, from what I hear, full backups sometimes fail to restore properly on this device.
TL;DR Be careful, read guides, you'll be fine. Rooting (on this device, with a lack of full recovery, hence no custom ROMs or Kernels) is really just used for audio mods, photo mods like free google photos, extensive app mods, etc. If you're not actively looking into any of these, stock Android is pretty solid.
Prant said:
TWRP on this device is really, "make of it what you will." It doesn't fully support this phone officially, and the leaked versions don't support device decryption, so you'll be forced to not use a passcode on your phone.
You don't need TWRP anymore, you just need to be careful and know what you're doing. There's guides for every model here, although they're all basically the same. Try to avoid flashing anything from your PC to the phone, just flash inside Magisk and BOOT images.
From my knowledge the reason for this is there's hidden partitions from OPPO all over the filesystem and normal flashers don't take this into account, anyone just trying to flash a full zip has bricked.
Which leads me to, there's no full recovery for this device that's free. If you brick a file and end up boot looping both slots, you're gonna have to pay for a restore. Even with TWRP, from what I hear, full backups sometimes fail to restore properly on this device.
TL;DR Be careful, read guides, you'll be fine. Rooting (on this device, with a lack of full recovery, hence no custom ROMs or Kernels) is really just used for audio mods, photo mods like free google photos, extensive app mods, etc. If you're not actively looking into any of these, stock Android is pretty solid.
Click to expand...
Click to collapse
Thanks for this.
I got as far as unlocking the phone and installing Magisk. But haven't gone further until I understand what the next step is.
Can I root non-destructively? Or is the phone wiped?
If you're unlocked and have Magisk installed, rooting is as easy as booting a patched boot image, then using Magisk to install it to your boot image. You have the choice of finding a matching one in one of the guides or pulling your own from a full zip.
It must match the firmware revision, I know for a fact personally that region matters little in case of NE2215/3, as you're only doing a one time boot.
I recommend @g96818 's guide here, you can find almost every firmware's boot image posted there if you prefer patch it yourself using Magisk or just boot an already patched one.
I have a 10 Pro (NE2215) rooted as a daily driver using TMO US.
Unlocked means 2 things in the android phone scene. Either it's carrier unlocked and can take any sim from any phone company or it bootloader unlocked which is needed to root and load custom roms.
There aren't any custom roms for the 10pro because of the lack of a full recovery system. Basically the ability to force full flash a stock rom in case the custom ROM soft bricks the phone. So that leaves rooting as the reason to unlock your bootloader.
I suggest reading the guide for rooting this phone, it's relatively easy. TWRP is unnecessary as it doesn't offer much without custom ROMs. Also you should back up everything on the phone that you don't want to lose because during the rooting process a factory reset will occur (android safety feature).