Build an Impractical But Awesome Lego Mindstorm Dock

The vast majority of what we cover here on the XDA-Developers News Portal relates to … more

MultiROM Makes its Way Over to the HTC One (M8)

While browsing our forum, you will undoubtedly find more than a few enticing ROMs available … more

Welcome to the New XDA-Developers Portal!

You may recall that a few weeks ago, we opened up the XDA-2015 forum themesto intrepid users … more

An Android Enthusiast’s Apple iPhone 6 Challenge

The media has gone batty again over Apple “revolutionizing” smartphones. … more
Post Reply

[Q] Simple SD card CM boot?

13th June 2013, 04:49 AM   |  #1  
OP Senior Member
Flag Seattle, WA
Thanks Meter: 211
 
293 posts
Join Date:Joined: Apr 2011
Donate to Me
More
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.
13th June 2013, 07:57 AM   |  #2  
leapinlar's Avatar
Recognized Contributor
Thanks Meter: 3,631
 
8,311 posts
Join Date:Joined: Oct 2006
Donate to Me
More
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.
The Following User Says Thank You to leapinlar For This Useful Post: [ View ]
14th June 2013, 05:49 AM   |  #3  
OP Senior Member
Flag Seattle, WA
Thanks Meter: 211
 
293 posts
Join Date:Joined: Apr 2011
Donate to Me
More
Thumbs up 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:
  1. The HD or HD+ is running B&N v2.1.x or v2.2.0 (other versions unknown/untested).
  2. 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.
Last edited by DeanGibson; 20th December 2013 at 10:17 AM. Reason: Verified working on B&N v2.2.0
14th June 2013, 05:59 AM   |  #4  
leapinlar's Avatar
Recognized Contributor
Thanks Meter: 3,631
 
8,311 posts
Join Date:Joined: Oct 2006
Donate to Me
More
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.
Last edited by leapinlar; 14th June 2013 at 08:30 AM.
14th June 2013, 09:44 PM   |  #5  
OP Senior Member
Flag Seattle, WA
Thanks Meter: 211
 
293 posts
Join Date:Joined: Apr 2011
Donate to Me
More
Exclamation Details, details ...
Quote:
Originally Posted by leapinlar

...

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!
Last edited by DeanGibson; 15th June 2013 at 05:04 AM. Reason: Clarity
30th August 2013, 07:19 PM   |  #6  
OP Senior Member
Flag Seattle, WA
Thanks Meter: 211
 
293 posts
Join Date:Joined: Apr 2011
Donate to Me
More
PATH priority
Quote:
Originally Posted by DeanGibson

...
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.
Post Reply Subscribe to Thread
Previous Thread Next Thread
Thread Tools
Display Modes


Top Threads in Nook HD, HD+ Q&A, Help & Troubleshooting by ThreadRank