Develop Bugs

[GUIDE] Persistent Temp Root for G2 to SD Card

Problem: Changes to the system partition are lost when Linux flushes the disk cache: http://pastebin.com/cm75Z9UA
These instructions are a workaround to provide temp root like normal plus persistence because /system /data and /cache are partitions on your SD card. This lets you reboot and even factory reset, while being able to easily restore your settings and such by re-rooting and mounting your SD card partitions back over the internal partitions.
Prerequisites:
SD card partitioned with four partitions:
6GB as fat (for your data, can be bigger or small depending on your card size)
400MB ext3 for /system
1.3GB ext3 for /data
200MB ext3 for /cache
On the phone, enable "USB debugging" in Menu -> Settings -> Applications -> Development
On a PC with the Android SDK tools (adb) installed and working:
adb push Superuser.apk /data/local
adb push busybox /data/local
adb push rage /data/local
adb push resume /data/local
adb push root /data/local
adb push rsync /data/local
adb push setup /data/local
adb push su /data/local
adb install Term.apk
adb shell chmod 755 /data/local/busybox /data/local/rage /data/local/setup /data/local/resume /data/local/rsync /data/local/root
On the phone, open "Terminal Emulator" and type:
/data/local/rage
Wait for it to say "[+] Forked NNNN childs." then press the back button.
Open "Terminal Emulator" again and it should force close.
Open it one more time and the prompt should display "#". Then type:
/data/local/root
/data/local/setup
You may need to re-root after it reloads the GUI, but then it will stick. setup is a script that mounts your SD card partitions and copies the existing. It should only be run once unless you want to erase what you have there previously. This step wont work if you SD card is not partitioned properly.
On future power-ons, run this after temp-root instead of setup:
/data/local/resume
and you should get your Android back how it was.

is it suppose to scan through all apps on phone then reboot

Thanks muchly, I'll try this when my G2 arrives.
I have a question about this method. It looks to me that what setup does is copy the entire system, data, and cache to the SD card. Then, when you run resume, it uses rsync to bring the main system (in the onboard flash) up to date from the SDcard version, and then any changes, even if not actually written to the main system partition due to the HTC copy protection, get written to the sdcard copy of the system. Very clever (if I'm reading this write, otherwise, still clever, but me not so clever as I mis-understood).
The question is this: Are there any glitches or instabilities generated by suddenly changing the system files after the OS is already booted? Do I have to make sure to do this before I begin using my phone after boot or risk making changes that I will then loose when I run resume?
Thanks again for the work putting this together!
Sheep

Sheep, you understand almost completely. Setup does copy the existing data from the internal phone memory to the SD card. However, it then (like resume) doesn't copy anything back, it just mounts the system, data, and cache partitions from the SD card on top of the internal ones.
I had issues with the internal memory reverting back after I make changes to it. It seemed to happen over a short time, or was triggered by things like mounting the SD card to a computer.
I've been using this for about 24 hours with no problems. I've done a couple fresh boots and ran resume. But I didn't test the instructions from scratch, so if anyone tests and finds a problem, let me know!

Any performance hit because of running from SD?

I haven't really noticed any.

How does this impact battery life?
Sent from my T-Mobile G2 using XDA App

Can't say, I've had my phone hooked up most of the time through adb looking for root. Just did this for fun and because I was sick of re-rooting all the time.

looks interesting I'll try it out tomorrow
Sent from my T-Mobile G2

so your sd card has to be partitioned pryor to trying this

pre-partitioned card?
thatruth132 said:
so your sd card has to be partitioned pryor to trying this
Click to expand...
Click to collapse
yes it does

texasaggie1 said:
yes it does
Click to expand...
Click to collapse
and how do i do this on a non-rooted device

thatruth132 said:
and how do i do this on a non-rooted device
Click to expand...
Click to collapse
Use your G1 to partition the card.
Brad

You can also connect your phone to a Linux computer (a LiveCD would be fine) and use gparted or fdisk. Don't forget to backup the contents of your card first!

Pretty cool. But I think I'm gonna wait for a more permanent solution....

sheek360 said:
Pretty cool. But I think I'm gonna wait for a more permanent solution....
Click to expand...
Click to collapse
There are no roms available yet any ways, so to a non dev, non cook like me, the Root is pretty much useless

I'd read that the currently available root was good until a reboot, then I saw this thread that made rerooting after a reboot much easier. Since then I've seen some posts that seem to indicate that a root may spontaneously disappear even without rebooting. Is this the case, some permissions may be lost even if you don't reboot?
I was ready to pull the trigger on this permanent-temporary root until I read that. I'd like to be able to import my old wpa_supplicant.conf file and get my corp ipsec vpn working. I'd also like to be able to get wifi-tether working (although I rarely use it), but if root won't stay 100% until a reboot, then I'm not going to bother.

Dalamak said:
There are no roms available yet any ways, so to a non dev, non cook like me, the Root is pretty much useless
Click to expand...
Click to collapse
Not true. I'm not a dev or a cook, but there are things that you can make the phone do with root besides adding a theme or ROM.
wifi tether
ipsec vpn
backups
etc...

smasraum said:
I'd read that the currently available root was good until a reboot, then I saw this thread that made rerooting after a reboot much easier. Since then I've seen some posts that seem to indicate that a root may spontaneously disappear even without rebooting. Is this the case, some permissions may be lost even if you don't reboot?
I was ready to pull the trigger on this permanent-temporary root until I read that. I'd like to be able to import my old wpa_supplicant.conf file and get my corp ipsec vpn working. I'd also like to be able to get wifi-tether working (although I rarely use it), but if root won't stay 100% until a reboot, then I'm not going to bother.
Click to expand...
Click to collapse
With temp root on the internal system partition, writes would revert back after certain things (after mounting the sd card to a computer through the phone and disconnecting it, I'd always loose root). When running /system from an sd card, no writes can be reverted because none are made, so I've never had to re-root.

how to partition an SD card?
thatruth132 said:
and how do i do this on a non-rooted device
Click to expand...
Click to collapse
I used gparted in ubuntu to do mine. Like SAINTH said, the install disk for ubuntu is also a livecd so you dont even have to install ubuntu if u dont want to

[DEV][Proof-of-Concept] Boot from SD on Optimus V

I've tested this and it works. I only have a class 2 SDcard, so my testing shows it's really slow, a faster card would probably help.
With just this class 2 SD card, the boot-from-sd process is really only useful to see if the ROM being tested will straight-up brick your device or not.
Edit!
A class 6 card works fabulous! I'm posting from a tweaked version of mmarz's port of ath3nos' port of cm7 running from my brand-new class 6 card right now.
This process is hacked together from multiple other devices' howtos here on xda, sorry I don't know who to credit for the bits and parts. All of it is pretty generic, actually, and might well be applicable to other devices when tried as a whole.
For the moment, I'm only posting a brief skeleton how-to without specific walkthroughs for the steps, and I don't really want to upload many files until more of the bugs are swatted.
The following info should be enough for you, the savvy dev, to put the ROM of your choice on your SD card and boot it (or watch it fail to boot) without risk of bricking your device!
noobs, don't you dare, bricking is always a risk if you don't know your way around fastboot and adb!
Of course, savvy dev or not, a fresh nandroid backup is MANDATORY before hacking at your phone like this.
Standard disclaimer:
There is always a possibility of bricking your phone when messing with adb and fastboot.
If you're not willing to take that risk, don't try this at home (or at work, or school....)
Here goes:
The basic plan I followed was:
1) make and format 3 extra ext2 partitions after the default fat32 on the SD card, in this order: data (at least 180Mb) , system (170Mb to match stock), and cache (102Mb stock).
2) split up the boot.img from your chosen ROM so you can mod the ramdisk.
edit: turns out this next step in the quote is not required, there is an easier way.
A nifty command called devwait for init.rc
3) compile a modified init, adding a "pause (5);" after the ANDROID text. It goes on line 569 in the gingerbread init.c from a recent repo of google source.
use the newly compiled init in place of the init from the ramdisk.
since getting the android source uses so much time and bandwidth, I'm being nice and attaching a modified gingerbread init. If you test it with a froyo ROM and it doesn't work, don't blame me. If it does work with froyo ROMS, let me know!
Click to expand...
Click to collapse
3) change your init.rc from the ramdisk as follows:
replace the "mount yaffs2 [email protected] /system" , cache, and data lines with
Code:
devwait /dev/block/mmcblk0p3
mount ext2 /dev/block/mmcblk0p3 /system nodev noatime nodiratime
mount ext2 /dev/block/mmcblk0p3 /system nodev noatime nodiratime ro
devwait /dev/block/mmcblk0p2
mount ext2 /dev/block/mmcblk0p2 /data nodev nosuid noatime nodiratime
devwait /dev/block/mmcblk0p4
mount ext2 /dev/block/mmcblk0p4 /cache nodev nosuid noatime nodiratime
be sure to comment out any other mounts which go to /system anywhere, like the "mount squashfs [email protected]/system/blahblah/blah.sqf /blah/blah" lines in the aospCmod init.rc
4) repack your boot.img, with the correct cmdline ("mem=477M console=ttyMSM2,115200n8 androidboot.hardware=thunderc" works,) etc.
5) prepare the ext2 /system partition with your target ROM /system files.
How to load the ROM:
steps a) to f) done on your PC. step g) is done on the phone.
a) Unzip the ROM on your PC, to get at the files to copy to the new /system directory in adb, and allow you to modify the updater-script.
b) Mod that ./META-INF/com/google/android/updater-script as follows:
As an example, I removed the following from the aospCmodOV-5-16-11 updater-script:
everything except the "ui_print" "symlink" and "set_perm" lines, including the "unmount" line at the end of the script.
I thinned it down because the update-binary wants to write to MTD partition for /system, and I didn't want or need that to happen.
I did need it to install the symlinks and permissions, though.
Without those, the keyboards kept FCing, and the phone couldn't connect to the network.
c) rezip the ROM with the modified updater-script.
d) boot phone into recovery and connect to PC with cable.
e) adb push or otherwise copy the modified ROM.zip to your sdcard.
f) next, copy /system from the unzipped ROM to the new partition with adb
Code:
adb shell
mount -t ext2 /dev/block/mmcblk0p3 /system
exit
adb push /path/to/unzipped/ROM/system /system
g) on phone, in recovery: install .zip from sdcard
select the new ROM.zip you reassembled and pushed to the SD card
select yes, you really want to install the .zip
this should write the /system symlinks and permissions to the new /system partition.
Click to expand...
Click to collapse
6) back on your PC, still connected to phone with cable in recovery;
Code:
adb reboot bootloader
fastboot boot /path/to/boot.img
Step 6 is important!
this will boot from your modified boot.img without actually flashing it into the phone's NAND, so a reboot (or restart after battery pull in case of issues) just goes to your regular installed ROM in the phone.
That's about it for now. It's pretty much a hack as yet, but it's cool in a geeky way to be able to do this.

<reserved for future use>

Thanks! This should be very helpful to devs and those of us who are adventurous with our phones!

Very interesting concept, I'd love to see how many uses this could have!

bump...
with a class 6 card, ath3nos/blarf cm7 runs great off sd.
even feels a little snappier than running from the phone mtd partitions.
I must benchmark soon to verify.
I'm really surprised no-one seems interested, I guess this is too old-hat, like a debian chroot

bigsupersquid said:
bump...
with a class 6 card, ath3nos/blarf cm7 runs great off sd.
even feels a little snappier than running from the phone mtd partitions.
I must benchmark soon to verify.
I'm really surprised no-one seems interested, I guess this is too old-hat, like a debian chroot
Click to expand...
Click to collapse
This is good work, but I think people require a bit more hand holding. How about publishing some of the modded files?
I personally still have problems recompiling a ramdisk.

mmarz said:
This is good work, but I think people require a bit more hand holding. How about publishing some of the modded files?
Click to expand...
Click to collapse
I can post files one rom at a time, because the ramdisk and kernel will be a bit different for each rom, and so will the permission/symlink updater-script.
first, I'll have to get rom-dev permission, because they get modded, and also cause it's nice to have permission.
I personally still have problems recompiling a ramdisk.
Click to expand...
Click to collapse
fastboot provides a fantastic shortcut for that, if you cpio-gzip the ramdisk together after editing it to your specs
from http://android-dls.com/wiki/index.php
in a command line linux shell, from the directory containing your unpacked ramdisk,
Code:
find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz
will put newramdisk.cpio.gz in the directory above the one containing your ramdisk
Click to expand...
Click to collapse
fastboot can make the boot.img for you and either dump it into the phone (assuming your shell current directory contains your kernel (zImage) and ramdisk (newramdisk.cpio.gz))
Code:
fastboot -c "mem=477M console=ttyMSM2,115200n8 androidboot.hardware=thunderc" flash:raw boot zImage newramdisk.cpio.gz
or boot your phone from the assembled image without actually flashing it in.
Code:
fastboot -c "mem=477M console=ttyMSM2,115200n8 androidboot.hardware=thunderc" boot zImage newramdisk.cpio.gz
those fastboot lines assume an optimus v (or s.)
looking at all the great work you've posted on the forums, I'm surprised you have trouble handling anything to do with these phones!
I'm slowly working up to a modded recovery to install-to-sd directly and avoid all this hacking.

Nice, thanks for that. I had no idea fastboot could do that.

mmarz said:
Nice, thanks for that. I had no idea fastboot could do that.
Click to expand...
Click to collapse
happy to share.
I only learned fastboot could do that when I seriously started in kernel testing after finally getting one to compile without errors. I didn't feel like bricking my phone to test the fresh kernel, and researching fastboot showed me its capabilities... I could've just typed fastboot with no arguments and that makes it list its parameters.
it's really helpful for this mod, because you can just reboot into your stock rom without having to reflash anything.
plus it's nice to just tweak the ramdisk and let fastboot do the work making a new boot.img for you when testing weird stuff like this.

bigsupersquid said:
happy to share.
I only learned fastboot could do that when I seriously started in kernel testing after finally getting one to compile without errors. I didn't feel like bricking my phone to test the fresh kernel, and researching fastboot showed me its capabilities... I could've just typed fastboot with no arguments and that makes it list its parameters.
it's really helpful for this mod, because you can just reboot into your stock rom without having to reflash anything.
plus it's nice to just tweak the ramdisk and let fastboot do the work making a new boot.img for you when testing weird stuff like this.
Click to expand...
Click to collapse
Very cool i loved this idea when it was executed in a way over at Ubuntdroid for the intercept when i was doing alpha testing. Very convenient for many of the scarier tests when i wanted to keep my existing system intact. The big difference was that on the intercept the bootable partitions were written into the kernel. Downside you couldn't use it to test kernels but could switch kernels from the phone and flip-flop between completely isolated systems on the go without a computer. Which was great when i wanted to test a new ROM on the way to work but i needed my phone when i got there and had to have a painless method of switching to my usual running system. So i'd flash a "non SD" kernel and i was back up and running in just a minute or so.
I'm excited to play with this when i have some free time.
Thanks dude!

you could easily use an update.zip for each of the sd-boot and regular phone boot.img files and swap between working systems with those in recovery.
before getting the fast sd card, I was looking at this more as for testing foreign roms than two-system operation, but now I see that would work too.
for a second-system option I was looking at a market-enabled rom on sd since I don't use g-apps on my daily driver.
note: the GB rom I'm running on won't 'see' a card with more than four partitions properly, and won't mount the vfat partition with vold, although you can manually mount and access the first four partitions including the vfat. android just won't admit it's there. and I couldn't get at a fifth partition through the phone os, even though my pc could see it fine (to get 5 partitions I had to use an extended partition to contain most of the virtual partitions)
android could read virtual partitions in an extended partition just fine as long as the total number on the card didn't exceed four.

I learned a neat trick today.
going through the init.rc from the stock rom, I noticed a section at the beginning which was labeled 'on emmc' which would imply running from a card if the device hardware lacked nand flash memory.
I'd read on xda while researching this concept of boot-from-sd about an unspecified wait-for-device command in init.rc, but most of the info I've gotten on init scripting language has come from picking apart init scripts, as google has not documented the available commands very well.
long story short, I tried using devwait with the regular init and it worked just fine to mount the ext partitions. yay!
first post edited to reflect the improved method.
I've also been testing a recovery mod. if recovery.fstab is modified in the recovery ramdisk (or a fakeflash recovery) then the recovery will copy a tweaked rom.zip to the ext /system partition with some minimal modifications to the updater-script and a few commands in the adb shell.
the recovery with the modded recovery.fstab can also back up from and restore to the sdcard ext /data and /system partitions.
I will update the first post with more specific instructions as I hammer them into something consistent.
soon I'll be ready to release a modded fakeflash recovery to make experimentation easier, as well.

[WIP] Booting NST from the sd card

This is still a work in progress but the Nook Simple Touch can now boot from the sd card. If you would like to learn how view klausef's comments in post number 27 (http://forum.xda-developers.com/showpost.php?p=25325319&postcount=27).
I will continue to update this post when there is new information
Thanks to klausef for working on this and creating a solution to my question.
Thanks to all of those that contribute to nookdevs and thanks to everyone else that has commented on this topic.

I wonder what would happen if I were to write a backup of the Nook onto an SD card and put it in (with the Nook itself wiped so it can't boot from the internal flash)

Nothing, because the mountpoints are wrong.
It should be possible, but I never tried it:
-partition and format the sd in a similiar way like the nook,
-unpack the uRamdisk and edit the mountpoints in the init.rc from mmcblk0 to mmcblk1
Again, I'm not sure if it works, thats what I read somewhere. And even if it works, it will be slow if you don't use a really fast sd-card.

mali100 said:
Nothing, because the mountpoints are wrong.
It should be possible, but I never tried it:
-partition and format the sd in a similiar way like the nook,
-unpack the uRamdisk and edit the mountpoints in the init.rc from mmcblk0 to mmcblk1
Again, I'm not sure if it works, thats what I read somewhere. And even if it works, it will be slow if you don't use a really fast sd-card.
Click to expand...
Click to collapse
Onwards to experimentation!!!!

mali100 said:
And even if it works, it will be slow if you don't use a really fast sd-card.
Click to expand...
Click to collapse
He meant not SD class (sequential I/O speed), but random (SD brand mostly)
Explained here: http://forum.xda-developers.com/showthread.php?t=1102704

So it is possible thats good news. Do we know of any body thats working on it? or can someone instruct me on how to edit the files that need to be edit?

ApokrifX said:
He meant not SD class (sequential I/O speed), but random (SD brand mostly)
Explained here: http://forum.xda-developers.com/showthread.php?t=1102704
Click to expand...
Click to collapse
Yes, I know that. I wasn't planning on using this for day-to-day use, just testing to see if it would boot.

Googie2149 said:
Yes, I know that. I wasn't planning on using this for day-to-day use, just testing to see if it would boot.
Click to expand...
Click to collapse
Have you got anything to boot off the sd card?

probbiethe1 said:
Have you got anything to boot off the sd card?
Click to expand...
Click to collapse
Haven't tried yet, been busy with a school project. I finish it tomorrow, so I'll try then. Maybe. Probably.

Cool good luck with your school project

Forgive me if this explanation goes through too basic of things for you but I am trying to establish context. Basically here's the status:
When you hit the power button on the nook touch, it calls some bootloader software called UBoot, that's kind of like a BIOS for embedded systems. UBoot looks for a file called UImage and a file called URamdisk. These two files contain the kernel and the root filesystem (and maybe a few other things, I've not taken the time to learn too much about UBoot). When UBoot finds these files, it loads them to RAM and starts executing the kernel.
Now the first thing the kernel is going to do when it starts up is to run the program 'init.' Init performs all the necessary stuff to start the system as you know it. Part of what init does is run a script called 'init.rc.' This script does a lot of things, but an important part of what it does is mount all these partitions.
So all we have to do to run the device off an SD card is to get UBoot to use the UImage and URamdisk from the SD card instead of internal memory! It turns out that this has actually been done before. This method is exactly what touchNooter did to root our nooks. Of course, it was created with other things in mind.
What I did was burn an exact copy of the nook's internal memory to an SD card, but then took the files from the touchNooter image that make UBoot work, and copied them over to the boot partition of the SD card. I'm not sure that you have to copy all the files I did, but anyway here's the ones I took from touchNooter:
u-boot.bin
cfg.bin
boot.scr (This is essentially a UBoot script that tells it what to do with UImage and URamdisk to set up the rootfs and start the Kernel)
I also made all of the boot images black so I would be able to tell if the nook was using the SD card.
When I stuck the SD card in and rebooted, lo and behold, the screen went black all the way through the boot process. It worked! The only issue is, it turns out that init and init.rc are somehow loaded into the UImage or URamdisk, so when init runs, it still mounts the partitions that are on the nook's internal storage. From this, we can deduce that the only thing running from the SD card is the kernel, and everything else is as before.
The solution to this is to recompile the UImage and URamdisk using B&N's provided source with an edited init.rc to mount the SD card's partitions. Another way we could do it is to somehow edit 'boot.scr' to make UBoot to pass an argument to the kernel when it gets started to use a different, modified init. (Much like pushing `esc` on a linux bootscreen and typing init=<binary>)
The first solution is harder but more correct, while the second solution is easier but much more hackish.
I am somewhat new to UBoot so I would appreciate it if someone else could correct any inaccuracies I may have made.

klausef said:
The solution to this is to recompile the UImage and URamdisk using B&N's provided source with an edited init.rc to mount the SD card's partitions.
Click to expand...
Click to collapse
You can easily unpack/edit/pack URamdisk
mali100 explained everything and posted scripts here. I’m reposting his scripts below:
Unpack (xuramdisk)
Code:
#!/bin/bash
#if (test $# -eq 1 && -f $1)
if [ -f $1 ]; then
dd if=$1 bs=64 skip=1 of=rdisk.gz
# Uncompress
gunzip rdisk.gz
# Extract
mkdir ramdisk
cd ramdisk
cpio -iv < ../rdisk
else
echo "No Ramdisk found"
fi
pack (mkuramdisk)
Code:
#!/bin/bash
find . -regex "./.*"| cpio -ov -H newc | gzip > ../ramdisk.gz
mkimage -A ARM -T RAMDisk -n Image -d ../ramdisk.gz ../uRamdisk

klausef said:
-snip-
Click to expand...
Click to collapse
That's great! Even as you have it right now, this could be a great way to test new kernels!

Googie2149 said:
klausef said:
-snip-
Click to expand...
Click to collapse
That's great! Even as you have it right now, this could be a great way to test new kernels!
Click to expand...
Click to collapse
If nook doesn’t boot, but respond to shutdown button still,
you can replace uImage or uRamdisk on nook internal SD by booting from noogie (well known fact)
or removing external SD card.
Otherwise (nook doesn't respond to shutdown button - semi-bricks)
you need to open it and disconnect battery or wait till it got discharged completely
And you may need to pop nook open to start it charging again in some cases
Either way, I don’t see how booting from external SD card helping much with kernel testing.
Am I missing something obvious?

I use my Nook to read textbooks for all my classes so I cannot afford to experiment through the internal memory.
At any rate, digging around the forum it turns out that people have known this for a while (OP even mentioned it in the first post), so I apologize for the bulk of that post.
I tried editing the init.rc to mount the SD card's partitions (replaced all /dev/block/mmcblk0 with /dev/block/mmcblk1) and it seems to just hang. ( I made sure to wait a long time to make sure it wasn't just lagging from the speed of the card reader, although I may not have waited long enough... )
This lead me to believe that the card reader is not initialized yet. To test this hypothesis I edited init.rc back to something that worked, but this time added `ls /dev/block/ > /data/blocks` right after the data partition is mounted, to find out all the block devices the Nook sees at this point. Unfortunately, after the system starts up I found no file named 'blocks' in /data/blocks.
EDIT: Found the culprit! After boot, I looked at dmesg:
Code:
init: /init.rc: 19: invalid command 'ls'
So we can't use `ls` for this. No problemo, I'll just pack busybox into the uRamdisk and use `ls` from there.

klausef said:
I use my Nook to read textbooks for all my classes so I cannot afford to experiment through the internal memory.
At any rate, digging around the forum it turns out that people have known this for a while (OP even mentioned it in the first post), so I apologize for the bulk of that post.
I tried editing the init.rc to mount the SD card's partitions (replaced all /dev/block/mmcblk0 with /dev/block/mmcblk1) and it seems to just hang. ( I made sure to wait a long time to make sure it wasn't just lagging from the speed of the card reader, although I may not have waited long enough... )
This lead me to believe that the card reader is not initialized yet. To test this hypothesis I edited init.rc back to something that worked, but this time added `ls /dev/block/ > /data/blocks` right after the data partition is mounted, to find out all the block devices the Nook sees at this point. Unfortunately, after the system starts up I found no file named 'blocks' in /data/blocks.
EDIT: Found the culprit! After boot, I looked at dmesg:
Code:
init: /init.rc: 19: invalid command 'ls'
So we can't use `ls` for this. No problemo, I'll just pack busybox into the uRamdisk and use `ls` from there.
Click to expand...
Click to collapse
Wow sounds like your really making progress. Let me know if there is anything I can do to help.

klausef said:
So we can't use `ls` for this. No problemo, I'll just pack busybox into the uRamdisk and use `ls` from there.
Click to expand...
Click to collapse
Would it be easier to use cat? (this is not a snarky remark)

Wow sounds like your really making progress. Let me know if there is anything I can do to help.
Click to expand...
Click to collapse
Haha thank you but nah, most of the stuff that I have done is known. I'm mostly just trying to replicate and document what has been done as precisely as possible.
Would it be easier to use cat? (this is not a snarky remark)
Click to expand...
Click to collapse
I am not sure cat would work in this case since we are trying to get a directory listing of the directory /dev/block/, not concatenate or list two files.
Anyhow, it turns out that 'init.rc' is not a bash script, but instead uses the syntax described here: http://www.kandroid.org/online-pdk/guide/bring_up.html (See 'Android Init Language' section)

klausef said:
Anyhow, it turns out that 'init.rc' is not a bash script, but instead uses the syntax described here: http://www.kandroid.org/online-pdk/guide/bring_up.html (See 'Android Init Language' section)
Click to expand...
Click to collapse
Thats correct, but you can call your own bash script from it. Take a look on how clrbootcount.sh is called in the init.rc

Per the documentation I have invoked a script through init.rc. The script is very simple. I included a busybox binary in the uRamdisk at /busybox, so that's what it's based on:
Code:
#/busybox ash
/busybox ls /dev/block/ > /data/blocks;
I have verified that the script works by first running it on an up-and-running nook and it worked properly. (That is, it created a populated file in /data/blocks and then terminated)
The script is called through the init.rc right after it finishes mounting all the partitions:
Code:
service lsdev /lsdev.sh
oneshot
When I start up the nook with this init.rc it hangs on boot. I also tried calling the script using `exec` instead of `service` but it still hangs.
In other news, I noticed dmesg finds mmcblk1 (the SD card) around the same time it finds the internal memory. See this dmesg snippet:
Code:
<6>[ 22.080810] twl4030_rtc twl4030_rtc: setting system clock to 2012-04-15 00:48:42 UTC (1334450922)
<6>[ 22.090759] mmc0: new high speed MMC card at address 0001
<6>[ 22.096801] Freeing init memory: 164K
<6>[ 22.106384] mmcblk0: mmc0:0001 SEM02G 1.82 GiB
<6>[ 22.111450] mmcblk0: p1 p2 p3 p4 < p5 p6 p7 p8 >
<4>[ 22.238494] EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
<4>[ 22.321990] mmc1: host does not support reading read-only switch. assuming write-enable.
<6>[ 22.330841] mmc1: new high speed SDHC card at address 1234
[B]<6>[ 22.337280] mmcblk1: mmc1:1234 SA04G 3.67 GiB [/B]
<6>[ 22.342651] mmcblk1: p1 p2 p3 p4 < p5 p6 p7 p8 >
The Nook is failing to boot for some other reason than because it doesn't see the SD card. I previously assumed the opposite, which is why I've been going through this big init.rc exercise to verify it. (I was expecting not to see a /dev/mmcblk1p*)
It is my assumption that this has something to do with how the stock userland is set up, so I'm going to call it a day, then shift my focus to compiling a new kernel and userland instead of just aimlessly trying to get this one to run off the SD card.
Please don't let that doesn't discourage any of you from further contributing to this thread's original goal, because it would still be immensely useful to the development process.
Good day, all. Thanks for the help.

[Root] NookManager - graphical rooter for 1.2.x and beyond

This is a graphical, interactive rooting system with the ability to create/restore backups and factory settings.
This has been tested on systems 1.1.5, 1.2.0 (US/UK), and 1.2.1. It will probably work on earlier versions and should be safe to use on future versions. For best results, however, you should be on 1.2.1 before using this tool.
If you've tried rooting your nook unsuccessfully with another utility, it's best to do a factory restore (from NookManager, choose the "Rescue" option and then "Restore factory.zip") and, if your nook came with older firmware, upgrade to the latest 1.2.1 firmware.
Features:
Root your Nook
Backup/Restore
Restore to factory settings
Disable B&N Apps
Custom plugins
How to root:
1. Download NookManager.
2. Unzip the file you downloaded and write the NookManager.img file to an empty SD card. On Windows, you can use disk imager. Linux and mac users can use dd.
Use a real SD card adapter when writing the image, DO NOT USE YOUR NOOK AS THE SDCARD ADAPTER.
If possible, you should use a dedicated SD card for the NookManager image (so you can easily restore from a backup should you ever screw up your Nook). A 512Mb card is big enough for the NookManager image plus a backup of your Nook.​
3. Power off your Nook, insert the SD card and power on.
You should see the NookManager boot screen followed within 15 seconds by the welcome screen.​
4. Choose "No, continue without wireless"
the wireless option is for advanced users looking to connect directly to their device​
5. Make a backup using NookManager! Choose "Rescue" then "Backup" then "Format remaining space on SD card" and finally "Create backup"
Because NookManager cleans the empty space on the Nooks' internal partitions and compresses the backup, it will take at least 15 minutes (and up to 45 minutes) for the backup to complete. Be patient. The final backup file can be as small as only be a few hundred megabytes, depending on the number of downloaded or sideloaded books you have.​
6. Copy the backup image to your computer. Connect your Nook to your computer using the USB cable. Copy the 'backup.full.tgz' and 'backup.full.md5' files from the NookBackup drive to your computer.
This is your backup in case anything happens to your SD card. This backup is tied to your individual Nook so keep it safe. It's important to copy this file while your Nook is still booted from the SD card because Windows will normally hide the NookBackup partition on the SD card. If you ever need access to the NookBackup partition again, just boot your Nook using the NookManager SD card and connect the Nook to your computer with the USB cable.​
7. Root! After your backup, press "Back" and "Back" to return to the Main Menu. Press "Root" and then "Root my device"
8. That's it! After rooting, pres "Back" and then "Exit". Remove the SD card and put it someplace safe, in case you need to restore to your backup later.
After rooting, you can install Google Apps using straygecko's excellent NTGAppsAttack package if you want to use Google Market/Gmail/Calendar/etc.
[/LIST]
Technical stuff:
The actual rooting function is minimal and as non-invasive as possible:
uRamdisk is patched to enable ADB
the internal database setting is changed to allow installation of non-market apps
the DroidSansFallback font is replaced with the updated font from jellybean to add support for extended characters
the su/Superuser binary/package is installed
Relaunch is installed
ADB Konnect is installed for enabling/disabling ADB over wireless
on systems running firmware 1.2+, the ModManager jars and package are installed
on 1.2+ systems, the PackageInstaller.apk from the 1.1.2 firmware is installed to resolve issues with package installers
and, finally, the Amazon appstore is installed just to have some easy way of downloading new apps. You can uninstall it using ReLaunch if you don't use it.
The uRamdisk patching is done with scripts rather than copying pre-compiled binaries, so this should be safe for all existing versions of the Nook firmware and (hopefully) will be forward compatible with any new releases.
The rooting procedure is non-destructive and can be run multiple times without causing problems.
Under the hood, this is a minimal linux environment with the nook drivers/binaries and a few core android binaries. The display is generated with imagemagick and written directly to the framebuffer.
If you're connecting to NookManager wirelessly over SSH, the username/password is root/root
Wherever possible, the parts of this system are compiled from source including the Linux kernel, uBoot, and all of the buildroot utilities. The hardware drivers and associated binaries are extracted from the 1.2.0 upgrade package.
The source for the project, including an automated buildscript is available at GitHub.
Support for custom menu items and scripts is documented here.

https://github.com/doozan/NookManager/downloads
NookManager.zip
17.9MB · Uploaded 14 hours ago
File was not found.
Click to expand...
Click to collapse
??

Weird. I deleted/re-upped the file and the download link seems to be working now.

ok..now it works. Thanks

Will this work with NoRefresh?

Thanks for the work on this - it was easy and worked great. And if you're planning to update, maybe add ES File Explorer or Titanium Backup in the pre-installed apps; that would make it easier to install apks directly from your SD card instead of having to do it over wireless adb. But thanks regardless.

Can confirm no refresh works great. Installed FBReader, Opera Mobile, ES File Explorer and Kindle app. Great
I just came from a firmware that had the ability to change the hardware buttons for page turning, any chance of this being added?

Thanks for this! Giving it a try.
Just curious though... I'm trying to create the backup of the device and it seems to take forever to format the free space. It also took forever to find the wireless network and I eventually just rebooted it. How long does it usually take?
I'm using a NST on 1.2.0 and have tried a 2GB Sandisk and a 8GB Dane-elec microsd card.
Gonna try redownloading and re-installing the image.

Install apk
Hi, i successfully root my NGL(1.2.0) but, if i try to install apk (Cool Reader) i got an error window "Out of space" and i'm almost sure it must be enough space to install, may someone can help with this ?

mobamoba said:
maybe add ES File Explorer or Titanium Backup in the pre-installed apps
Click to expand...
Click to collapse
Good suggestion, I've added ES File Explorer
Gvr4-330 said:
it seems to take forever to format the free space..and wifi
Click to expand...
Click to collapse
Thanks for reporting this. There was a glitch with the script that formats the SD card and with the wifi loading. Both issues have been fixed in the latest release.
asprin said:
if i try to install apk (Cool Reader) i got an error window "Out of space"
Click to expand...
Click to collapse
How are you trying to install the apk? I'm also using Cool Reader it installed with "adb install" and runs just fine. For best Nook compatibility, use coolreader 3.1.2-27 (12/11/2012 build) or later.

Originally Posted by asprin
if i try to install apk (Cool Reader) i got an error window "Out of space"
Click to expand...
Click to collapse
You get this error when you try to install application from an .apk file on sdcard or when you try to update application via it's built in updater.
ADB install works fine.
Good suggestion, I've added ES File Explorer
Click to expand...
Click to collapse
I use
Rhythm Software - File Manager
http://rhmsoft.com/?p=96

osowiecki said:
You get this error when you try to install application from an .apk file on sdcard or when you try to update
Click to expand...
Click to collapse
I'm not able to replicate this: I can copy coolreader to my sd card, and install it from there with no problems using ES File Explorer or ReLaunch. Maybe you really do have a disk space issue. Try openinng an adb shell and run "df -h" to see disk usage on your mounted partitions.
mobamoba said:
maybe add ES File Explorer
Click to expand...
Click to collapse
osowiecki said:
I use Rhythm Software - File Manager
Click to expand...
Click to collapse
It turns out you can install apks using the file browser in ReLaunch, so I'll be removing ES File Explorer in any future versions.

jeff_kz said:
I'm not able to replicate this: I can copy coolreader to my sd card, and install it from there with no problems using ES File Explorer or ReLaunch. Maybe you really do have a disk space issue. Try openinng an adb shell and run "df -h" to see disk usage on your mounted partitions.
It turns out you can install apks using the file browser in ReLaunch, so I'll be removing ES File Explorer in any future versions.
Click to expand...
Click to collapse
Thx for respond, mate, I tried install with file browser in ReLaunch from sd card, and i cant imagine that can be space issue cause i just start procedure after factory reset and rooting, anyway, thanks for tip, will try tomorrow install new build, and adb install. In general great work you did :good:

jeff_kz said:
I'm not able to replicate this: I can copy coolreader to my sd card, and install it from there with no problems using ES File Explorer or ReLaunch. Maybe you really do have a disk space issue. Try openinng an adb shell and run "df -h" to see disk usage on your mounted partitions.
It turns out you can install apks using the file browser in ReLaunch, so I'll be removing ES File Explorer in any future versions.
Click to expand...
Click to collapse
df :
/dev: 116452K total, 0K used, 116452K available (block size 4096)
/sqlite_stmt_journals: 4096K total, 0K used, 4096K available (block size 4096)
/rom: 16116K total, 227K used, 15888K available (block size 512)
/system: 285583K total, 210922K used, 74661K available (block size 1024)
/data: 824424K total, 304344K used, 520080K available (block size 4096)
/cache: 237987K total, 4179K used, 233808K available (block size 1024)
/media: 245484K total, 40K used, 245444K available (block size 4096)
/sdcard: 31149680K total, 6924320K used, 24225360K available (block size 16384)
Are you using UK or US Nook?
I'm on US Nook FW 1.2 + v176 kernel

I'm able to reproduce the apk install problems now. The "Not enough free space" error is what android throws when the internal PackageManager can't create the temporary apk file. In this case, it turns out that it's a permissions-related read error from the sdcard. I don't know if this is a matter of the internal PackageManager not running with elevated permissions, or if it's that the sdcard is mounted too restrictively.
If I re-mount the sdcard without the restrictive permissions, I can install apks from the sdcard without any errors:
Code:
umount /sdcard
mount -t vfat /dev/block//vold/179:17 /sdcard
If anyone else has any ideas for making this work, I'm open to any suggestions. In the meantime, "adb install" works just fine for installing packages.

I really suggest grabbing Android Commander if you're new to adb to graphically install apps.

jeff_kz said:
Thanks for reporting this. There was a glitch with the script that formats the SD card and with the wifi loading. Both issues have been fixed in the latest release.
Click to expand...
Click to collapse
Thanks for the quick update. I'm going to try it out now and will report back. I'm very excited
It works! Thanks so much for this! Very easy way to root and backup.

With your tool now I use this to read comics, RSS and books. First I need to say thank you.
I installed "D7 Google Reader" and "Google Drive" which requires Google Login. How could I use this software? Thanks
Also I installed version 0.2, I saw 0.3 comes out. Can I just update 0.2 to 0.3 directly? Thanks

so glad I decided to check the nook thread. Finally BN apps gone . Thank You

hi all, anyone have test factory reset on nstg US ? my backup is corrupt.
Envoyé depuis mon GT-N7100 avec Tapatalk

Can the internal of an android phone be repartioned

SO basically im trying something out and i need to add a partition to my android device thats about 100mb big. Is this possible? the Sdcard wont work as a partition

I've seen it done, but for some reason the OS will repartition it back to what it was before you edited it.
Best route would be to dump your current PIT file (partition table and other info is included in there) and modify it to fit your needs if possible. There are probably other threads on this if you search up "modifying PIT file"

CNexus said:
I've seen it done, but for some reason the OS will repartition it back to what it was before you edited it.
Best route would be to dump your current PIT file (partition table and other info is included in there) and modify it to fit your needs if possible. There are probably other threads on this if you search up "modifying PIT file"
Click to expand...
Click to collapse
will modifying that file be able create an extra 100mb partition so when i hook it into my comp two partitions show up?

That file can be used to repartition the phone. If you modify it correctly you should be able to resize other partitions and use that extra space to create your own XXX mb partition.

CNexus said:
That file can be used to repartition the phone. If you modify it correctly you should be able to resize other partitions and use that extra space to create your own XXX mb partition.
Click to expand...
Click to collapse
Alright thanks im looking into it know do you know how to dump one from a phone? as google is not bringing up anything besides info on what it is

You need to use heimdall but there are existing ones out there depending on what size your internal storage is
16 gb or 32?

CNexus said:
You need to use heimdall but there are existing ones out there depending on what size your internal storage is
16 gb or 32?
Click to expand...
Click to collapse
its a 16gb lph 710 ill look into heimdall thanks

What's your current bootloader version? If not known, run
Code:
getprop ro.bootloader
In a shell on your device/terminal emulator app
And then post the last three alphanumeric characters

Sorry I realized the bios of a comp doesn't recognize the android phone as a peripheral or a mountable boot device which ruins my plans as of now I'm going to try to find a way to at least get the bios to pickup the SDcard if I can I'm doubtful though