[Q] Simple SD card CM boot?

DeanGibson · Jun 13, 2013

I have a Nook HD+ that I want to root myself, and I'm looking for a simple CM (or whatever) bootable SD card image that does nothing to the HD+'s internal storage. I just want it to boot up so that I can connect via ADB, and do what I want on the HD+'s internal storage myself via ADB and shell commands.

Yes, I know I can use "Universal Root", but that does more than I want, and I think I want to root a different way anyway. I know what I'm doing, having published a similar rooting procedure for the Nook Tablet a year ago. I just need to boot from a SD card and have ADB/shell command-line access to the HD+'s internal storage.

I think I see a couple of bootable images, but they all seem centered around CWR. I do not want to install CWR on the HD+, and the descriptions seem vague as to exactly what the images contain.

leapinlar · Jun 13, 2013

Dean, you can go to my HD/HD+ CWM thread and make a bootable CWM card. It does nothing to internal memory until you flash something. Then you can connect to ADB and it gives you root access, again with no mods yet to internal. Then you can do what you want to the system. But remember, if you change anything on /system, it will reset on the next reboot. Look at my HD/HD+ tips thread item 15 to understand this.

Sent from my Nook HD+ running CM10.1 on emmc.

DeanGibson · Jun 14, 2013

Simple (basic) root

Thanks; I wasn't sure that the CWR images included ADB enabled.

~~I came up with a slightly simpler solution that uses a "remount,suid" on "/data"~~. This is no longer necessary. The prerequisites are:

The HD or HD+ is running B&N v2.1.x or v2.2.0 (other versions unknown/untested).
SuperSU is already installed (but need not be working) on the HD/HD+ via Google Play.

At http://www.mailpen.com/download/HdP_2.1.x-Root_0.05.zip

Note to lurkers: Don't quote this message with the above link intact, as it will change (and has):

Revision history:

2013-06-13 v0.01: Original release.
2013-06-14 v0.02: Avoid CWR set_perm bug?
2013-06-14 v0.03: Modify to use /system/bin/clrbootcount.sh. Include busybox and sqlite3.
2013-08-13 v0.04: Add updateSU.sh for easy update after su binary change.
2013-08-30 v0.05: Install files in /system/xbin/.bin and create links to them. Remove installation of a custom /system/bin/clrbootcount.sh. Add /system/xbin/.bin/busybox.sh (but don't execute it), which the user can use to create the required busybox links in /system/xbin (from where it should be run).

You are free to adapt this as you see fit.

leapinlar · Jun 14, 2013

You really should include an assert statement there for ovation (or ovation/hummingbird) in case it somehow gets out somewhere else. And the title says HD+, but inside the script it says HD/HD+. Also this should work on all versions of stock.

It does not install busybox or its symlinks.

Edit: Verygreen's original root did something similar where he put the su in /res, I think, set suid and symlinked it. But his root also failed to address busybox.

Edit 2: also some of my other zips will not work with your root because you removed the userinit.d implementation from install-recovery.sh. I suggest that you move your root to /system/bin/clrbootcnt.sh and symlink that. It also gets run on each boot. Then it would not interfere with my other zips that use install-recovery.sh to set up userinit.d.

Sent from my Nook HD+ running CM10.1 on emmc.

DeanGibson · Jun 14, 2013

Details, details ...

leapinlar said:
...

It does not install busybox or its symlinks.

Edit #1: Verygreen's original root did something similar where he put the su in /res, I think, set suid and symlinked it. But his root also failed to address busybox.

Edit #2: also some of my other zips will not work with your root because you removed the userinit.d implementation from install-recovery.sh. I suggest that you move your root to /system/bin/clrbootcnt.sh and symlink that. It also gets run on each boot. Then it would not interfere with my other zips that use install-recovery.sh to set up userinit.d.

#2: OK, I don't have a problem with that. Stand by for v0.3 ...

#1: I personally install busybox (and sqlite3) in /data/local/sbin, and they work there. The reason I don't create the busybox links is due to the PATH value, which usually has the value:

Code:

/sbin:/vendor/bin:/system/sbin:/system/bin:/system/xbin

In most busybox installations, busybox is in /system/xbin, and so when the links are created, if there is a name conflict between a busybox link in /system/xbin and a pre-existing one in /system/bin, the one in /system/bin takes precedence in a PATH search. That means that pre-existing apps that count on a particular standard behavior, will find the one in /system/bin. I think the probability of a problem due to a pre-existing app finding different behavior is very small, but it's one less thing to think about. Note that "mount" on the Acer Iconia A500 is nonstandard ...

Also, in most installations, /system/xbin is empty, or very nearly so, so putting the busybox links there (which I certainly could do on the HD+ as well) made it "cleaner" for maintaining that directory.

However, there are good arguments for putting the busybox links in /system/sbin (now aka /data/local/sbin). In addition to the same "cleaner" argument above, the busybox links would now supercede names in /system/bin. That might be an advantage, since usually the busybox versions of common utilities are more capable (more options) than those provided by the tablet vendor (usually in a similar program named "toolbox").

The point of all this is that I didn't want to rush in making a decision. Suggestions/comments welcome!

DeanGibson · Aug 30, 2013

PATH priority

DeanGibson said:
...
In most busybox installations, busybox is in /system/xbin, and so when the links are created, if there is a name conflict between a busybox link in /system/xbin and a pre-existing one in /system/bin, the one in /system/bin takes precedence in a PATH search. That means that pre-existing apps that count on a particular standard behavior, will find the one in /system/bin. I think the probability of a problem due to a pre-existing app finding different behavior is very small, but it's one less thing to think about.

...

However, there are good arguments for putting the busybox links in /system/sbin (now aka /data/local/sbin). In addition to the same "cleaner" argument above, the busybox links would now supercede names in /system/bin. That might be an advantage, since usually the busybox versions of common utilities are more capable (more options) than those provided by the tablet vendor (usually in a similar program named "toolbox").

The point of all this is that I didn't want to rush in making a decision. Suggestions/comments welcome!

OK, I tried creating links in /system/sbin, and that caused SuperSU (and other apps requiring root) to not work. The apps work if the links are in /system/xbin. I've added a "busybox.sh" script to the above .ZIP to allow the user to create the links wherever he/she wants.

Topics

Topics

[Q] Simple SD card CM boot?

DeanGibson

Senior Member

leapinlar

Senior Member

DeanGibson

Senior Member

leapinlar

Senior Member

DeanGibson

Senior Member

DeanGibson

Senior Member

Similar threads

Top Liked Posts

New posts