GJSmith3rd · October 8, 2013 23:05
diff --git a/ADB Sideload b/ADB Sideload
 ADB Sideload

 What is ADB sideload?

 ADB sideload is a new feature that was added to AOSP recovery in Jelly Bean.  As of version 2.3, TWRP now supports ADB sideload mode.  ADB sideload is a different ADB mode that you can use to push and install a zip using one command from your computer.  Most likely ADB sideload won't be very useful for your average recovery user, but ADB sideload can be a huge time-saver for a ROM developer.

 How do I use ADB sideload?

 Have a recovery installed on your device that supports ADB sideload like TWRP 2.3 or higher
 Have newer ADB binaries installed on your computer.  If it's been a while since you installed ADB on your computer, you may need to get the latest ADB binaries in platform-tools from the Android SDK.  You will need version 1.0.29 or higher.  You can find your current version by typing "adb version" at the command line.
 Set the device into ADB sideload mode. In TWRP you do this by going to Advanced then ADB Sideload.
 From the command line, type adb sideload /path/to/rom.zip
 The file will be copied to your device to whatever the current storage location is that you have selected in the mount page.  It will always be placed in the root of that storage location and named sideload.zip (e.g. /sdcard/sideload.zip) and it will automatically delete / overwrite any existing sideload.zip you may have on your device.  As soon as the file is copied to your device, it will automatically be installed.  When the install is finished you will be presented with a reboot system button so that you can reboot to test your zip.

 Note that sideload mode is a separate ADB mode. While in sideload mode, regular ADB commands will not work. Once the zip has been copied to the device and the install starts (or if you hit the cancel button) regular ADB mode will resume.
diff --git a/Crontab b/Crontab
 env EDITOR=nano crontab -e

 00 * * * * /usr/bin/wget http://tech.hotspotsystem.com/up.php?mac=MACADDRESS\&nasid=YOUROPERATORID_YOURLOCATIONID\& uptime=`uptime|sed s/" "/\%20/g|sed s/:/\%3A/g|sed s/,/\%2C/g` -O /tmp/up.html 

 To run cron every minute edit crontab to look like this:
 */1 * * * * /bin/echo testing123 >> /home/user/test.txt
diff --git a/How to find boot partition to save boot.img file? b/How to find boot partition to save boot.img file?
 # cat /proc/partitions

 # mount

 # df

 #ls -la
diff --git a/Making a Private Gist Public.txt b/Making a Private Gist Public.txt
 May 11 2011
 Gist is a really nice tool for sharing and storing snippets of code, notes, and any other text you want. It lets you create private or public Gists - basically, sets of text files.

 Sadly, it's not easy to switch a Gist from private to public (or vice versa). You can do this with a little Git-fu, since each Gist is its own Git repo. Here's how to do it.

 Copy the Private Clone URL from the Gist's page and clone the Gist to a temporary directory:

 ~ $ git clone [email protected]:PRIVATEGIST.git gist-private-temp
 ~ $ cd git-private-temp
 From the Gist Web interface, create a new public Gist. You will need to add some dummy text to a file in the Gist since you can't create a totally empty Gist. This file will be deleted in the next step, though.

 Copy the Private Clone URL from this new repo. Add the public Gist as a remote in your cloned copy of the private Gist, and push to it. (You'll need to do a forced push since the public Gist has the dummy file in it.)

 ~/gist-private-temp/ $ git remote add public [email protected]:PUBLICGIST.git
 ~/gist-private-temp/ $ git push -f public
 Finally, to get the new Gist content to appear on your Gist home page, go to the Gist's page, edit it, and resave it (without making any changes).

 I was thinking about making a script to do this, but my understanding is that the necessary Gist API methods are only available in the Github API v3, which is not yet stable; and I couldn't find any Github API libraries that support it yet.
diff --git a/Mount Command System b/Mount Command System
 Mount a filesystem read-write

 Very often when you want to write files to a particular partition on ADP1, you will get a "Permission Denied" if the partition is mounted read-only.
 To get around this, you need to mount the partition read-write. Typically this is done with /system partition

 $ adb shell
 $ su
 $ mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system

 (Replace /dev/block/mtdblock3 & /system with appropriate device path and mount point, as obtained from cat /proc/mounts)
diff --git a/Mount Commands SBIN b/Mount Commands SBIN
 busybox mount -o rw,remount /


 but /sbin is usually in ram so any changes will not be available after a reboot

 better to add to /system/bin
 or /data/local/bin ( with applicable PATH env )

 and in all honesty , if you have to ask.. you don't need it 
diff --git a/Mounts b/Mounts
 $ cat /proc/self/mountinfo better then using the standard cat /proc/mounts

 But if someone could post adb shell "mounts" and "cat /proc/partitions" it would help me see if the problem is worse than I thought regarding partitioning.
diff --git a/Parted b/Parted
 So, I've somehow managed to screw up the partitions on my Incredible. It can't mount DATA or CACHE. I saw on this post that it is possible to re-create them, but the user over there mentions using parted. How do I get parted onto my phone? I tried just running it through the shell but it says the command is not found.

 Any help would be greatly appreciated.

 UPDATE: Fixed it. Thanks goes to -Steveo- and ciwrl over at the Cyanogen forums for helping me figure this out last night.

 Here's the solution.

 The problem was that I managed to screw up the partitions on my internal storage card, so basically nothing would work properly. I could still get into recovery, though. That's key.

 Here's what you'll need:

 Working recovery, basic knowledge of adb & the shell
 Parted (download here)
 stock PB31IMG.zip



 Note also that I had run unrevoked forever (so my phone was S-OFF) ... I'm not sure if that's required or not.

 So, grab parted from the link above. Now you need to extract the individual binaries from the .zip (the 6 files in the sdparted folder within the zip), ideally to your android-sdk\tools directory. Now push all 6 files (adb push [file] /sbin/). Next, we need to make them useable, so go into the shell (adb shell). Change to your /sbin/ directory, and run: chmod 0755 <file> on each of the 6 files.

 Now, we need to fix the partitions. This is assuming that the partitions are there, just the wrong format (which is what happened to me .. I accidentally made them FAT32 instead of ext). So, run the following: parted /dev/block/mmcblk0 mkfs ext2. It will ask if you want to continue, hit yes. When it asks for the partition number, enter 1. Next, when it asks for the format, enter ext2. Let it do its thing. Now, once it's done, run parted again. This time, enter partition 2 (everything else is the same).

 Once all that's done, your recovery program should be able to mount both the /data and /cache partitions. If that's true, you're pretty much done! One thing I found was that I couldn't directly install a new OS (I tried both Cyanogen and Ultimate). In both cases, it would look for stuff in the davik-cache that it couldn't find, so something wasn't installing correctly I think. So, if that happens, flash back to the stock PB31IMG.zip (put it in the root of your /sdcard/ and let hboot install it), and then root your phone anew. That's what I ended up doing.

 Again, huge credit for this goes to -Steveo- and ciwrl for helping me figure out which partitions were the right ones (and for supplying parted, which I hadn't been able to find anywhere). If something doesn't end up working, just drop me a pm and we'll see what we can do.
 Last edited by raskolnik; 10-08-2010 at 06:24 AM. Reason: solved!
diff --git a/Partitions - summary of what partitions exist b/Partitions - summary of what partitions exist
 Partitions - summary of what partitions exist

 Storage structure

 How is storage on the tablet arranged?

 First, storage is split into internal and external. Internal storage consists of a single NAND chip, which in this case is around 4GB capacity total. External storage is on the micro SD card. The internal storage is split into many different partitions, just like a hard drive. These partitions contain things like system, boot, bootloader, recovery etc.

 We need to know what is contained in each partition in order to back up and restore them safely. There is some information on partition structure at http://linux-sunxi.org/Android/partitions but I wanted to have a poke around to see what my device is like.

 Difference between sdcard and extsd

 There caused me some confusion. A region of the internal NAND is called the internal SD card and mounted as "sdcard". The actual physical external SD card is called extsd. HOWEVER, when booted into the CWM recovery, it appears to refer to the external SD card as "sdcard"!

 Viewing output from shell commands

 The best way of viewing the output from a shell command is to pipe it to a text file, pull the text file to the computer over ADB, then view the text file. For example:

 adb shell
 adb shell "cat /proc/devices > /sdcard/output.txt"
 adb pull /sdcard/output.txt
 This runs the cat /proc/devices command to list system devices and pipes the output to output.txt which can then be viewed later.

 Let's see what we can find out. The following is performed on Mum's tablet (the good, original one) with the tablet fully booted up into Android. I'm looking at various files which contain information on devices and partitions.

 /proc/devices

 The output consists of character devices, which we're not interested in, and block devices. Here is the block devices listing:

 Block devices:
 1 ramdisk
 259 blkext
 7 loop
 8 sd
 11 sr
 65 sd
 66 sd
 67 sd
 68 sd
 69 sd
 70 sd
 71 sd
 93 nand
 128 sd
 129 sd
 130 sd
 131 sd
 132 sd
 133 sd
 134 sd
 135 sd
 179 mmc
 254 device-mapper
 The numbers are the major device numbers, which are a way of identifying physical storage devices. The two we are interested in are 93 nand and 179 mmc. These correspond to the internal NAND and external SD card (multimedia card), respectively.

 /proc/partitions

 This lists all current storage partitions. Output:

 major   minor    #blocks name

  93        0      16384 nanda
  93        8      16384 nandb
  93       16      32768 nandc
  93       24     524288 nandd
  93       32    1048576 nande
  93       40      16384 nandf
  93       48      32768 nandg
  93       56     262144 nandh
  93       64     131072 nandi
  93       72    1809408 nandj
 179        0    7761920 mmcblk0
 179        1    7757824 mmcblk0p1
 Note the major device numbers 93 and 179, corresponding to the internal NAND and external SD card. There are a total of 10 partitions on the internal nand, called nanda to nandj, and two on the external SD card. These partitions are all available under /dev/block/ (for example, /dev/block/nanda).

 The sizes of each partition are listed in blocks of 1024 bytes each. For example, nanda is 16384*1024=16777216 bytes=16MB in size. If we add up the sizes of each partition in the NAND (major number 93), we get a total of 3890176 blocks, or 3.98GB - i.e. the 4GB internal storage.

 /etc/vold.fstab

 Doesn't contain much. Relevant line:

 dev_mount	sdcard	/mnt/sdcard	auto	/devices/virtual/block/nandj
 Suggests that nandj corresponds to sdcard (the internal SD card). Size-wise, this is about 1.8GB.

 /proc/mounts

 Output (relevant lines only):

 /dev/block/nandd /system ext4 rw,nodev,noatime,user_xattr,barrier=0,data=ordered 0 0
 /dev/block/nande /data ext4 rw,nosuid,nodev,noatime,user_xattr,barrier=0,journal_checksum,data=ordered,noauto_da_alloc 0 0
 /dev/block/nandh /cache ext4 rw,nosuid,nodev,noatime,user_xattr,barrier=0,journal_checksum,data=ordered,noauto_da_alloc 0 0
 /dev/block/vold/179:1 /mnt/extsd vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
 /dev/block/vold/93:72 /mnt/sdcard vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
 We can see that nandd is /system, nande is /data and nandh is /cache. The external SD card (identified by major:minor numbers 179:1) is mounted to /mnt/extsd, and the internal SD card (93:72) to /mnt/sdcard. The major:minor numbers confirm that the internal SD card is nandj (compare with with /proc/partitions output).

 busybox df

 The df command lists the space usage of current partitions. The busybox version of the command gives a more detailed output:

 Filesystem           1K-blocks      Used Available Use% Mounted on
 tmpfs                   180968        44    180924   0% /dev
 tmpfs                   180968         0    180968   0% /mnt/asec
 tmpfs                   180968         0    180968   0% /mnt/obb
 /dev/block/nandd        516040    269540    246500  52% /system
 /dev/block/nande       1032088     88152    943936   9% /data
 /dev/block/nandh        258016      4236    253780   2% /cache
 /dev/block/vold/179:1
                       7753728        64   7753664   0% /mnt/extsd
 /dev/block/vold/93:72
                       1904156      7852   1896304   0% /mnt/sdcard
 /dev/block/vold/93:72
                       1904156      7852   1896304   0% /mnt/secure/asec
 dmesg

 Another command which gives some very useful information is dmesg (see http://en.wikipedia.org/wiki/Dmesg and http://www.linfo.org/dmesg.html. This lists all messages produced by the kernel during (and sometimes after) startup. Buried in the messages are some on the disk structure. To see these, run this from an adb shell prompt and pull the resulting text file back to the computer for viewing:

 dmesg | busybox grep "disk name" > /sdcard/dmesg.txt
 The output from dmesg is piped to grep, which displays only those lines containing the text "disk name", and the output from grep is dumped into the dmesg.txt text file. Here's the result:

 <4>[    0.185665] The 0 disk name = bootloader, class name = DISK, disk size = -544396252
 <4>[    0.185684] The 1 disk name = env, class name = DISK, disk size = -544396188
 <4>[    0.185694] The 2 disk name = boot, class name = DISK, disk size = -544396124
 <4>[    0.185704] The 3 disk name = system, class name = DISK, disk size = -544396060
 <4>[    0.185713] The 4 disk name = data, class name = DISK, disk size = -544395996
 <4>[    0.185723] The 5 disk name = misc, class name = DISK, disk size = -544395932
 <4>[    0.185733] The 6 disk name = recovery, class name = DISK, disk size = -544395868
 <4>[    0.185743] The 7 disk name = cache, class name = DISK, disk size = -544395804
 <4>[    0.185752] The 8 disk name = databk, class name = DISK, disk size = -544395740
 <4>[    0.185762] The 9 disk name = UDISK, class name = DISK, disk size = -544395676
 Note some oddities. The #8 partition is called "databk", suggesting "data backup". This partition is called "emmc" when booted into CWM recovery. Also note #9 is called UDISK - this is the "internal" SD card, called "sdcard" elsewhere.

 Summary

 Here's a quick summary of the partitions.

 Block name	Name/purpose	Filesystem type
 ----------	------------	---------------
 nanda		bootloader	vfat
 nandb		environment	raw
 nandc		boot		raw
 nandd		system		ext4
 nande		data		ext4
 nandf		misc		raw
 nandg		recovery	raw
 nandh		cache		ext4
 nandi		emmc		ext4
 nandj		sdcard		vfat
 Back to index
diff --git a/Simple Remount RW b/Simple Remount RW
 mount -o remount,rw /system
diff --git a/Terminal Prompts b/Terminal Prompts
 export PS1='\h \w$(__git_ps1 "(%s)") \$ '
 => mycomputer ~/apps/chess/tmp(master) $ _

 export PS1='\[\e[33m\]\h\[\e[0m\]:\W\[\e[33m\]$(__git_ps1 "(%s)")\[\e[0m\] \u\$ '
 => mycomputer:tmp(master) tom$ _

 # Henning's awesome TRON prompt 2.0.2 with current Git branch and success state of the last command (the syntax coloring here does not do it justice):
 export PS1='`if [ $? = 0 ]; then echo "\[\033[01;32m\]✔"; else echo "\[\033[01;31m\]✘"; fi` \[\033[01;30m\]\h\[\033[01;34m\] \w\[\033[35m\]$(__git_ps1 " %s") \[\033[01;30m\]>\[\033[00m\] '
 => ✔ mycomputer ~/projects/platforms master > _

 # Arne's epic timestamped prompt with return status indicator and status-colored (green if fresh, or red if unstaged, or yellow if staged) git branch:
 export PS1='\[\e[01;30m\]\t`if [ $? = 0 ]; then echo "\[\e[32m\] ✔ "; else echo "\[\e[31m\] ✘ "; fi`\[\e[00;37m\]\u\[\e[01;37m\]:`[[ $(git status 2> /dev/null | head -n2 | tail -n1) != "# Changes to be committed:" ]] && echo "\[\e[31m\]" || echo "\[\e[33m\]"``[[ $(git status 2> /dev/null | tail -n1) != "nothing to commit (working directory clean)" ]] || echo "\[\e[32m\]"`$(__git_ps1 "(%s)\[\e[00m\]")\[\e[01;34m\]\w\[\e[00m\]\$ '
 => 03:13:37 ✔ arne:(master)~/projects/geordi$ _

 # Arne's danger prompt for root use. No git information and alarming red and yellow (which you can't see here):
 export PS1='\[\e[01;30m\]\t \[\e[31m\]\u\[\e[37m\]:\[\e[33m\]\w\[\e[31m\]\$\[\033[00m\] '
 => 03:13:37 root:/tmp/foo# _

 # Kim's mix of those above with small changes. TRON promt with timestamp, return status indicator, hostname, git informations and working directory (but all non-bold).
 export PS1='\[\033[01;30m\]\t `if [ $? = 0 ]; then echo "\[\033[01;32m\]ツ"; else echo "\[\033[01;31m\]✗"; fi` \[\033[00;32m\]\h\[\033[00;37m\]:\[\033[31m\]$(__git_ps1 "(%s)\[\033[01m\]")\[\033[00;34m\]\w\[\033[00m\] >'
 => 03:13:37 ツ mycomputer:(master)~/code/foo >

 # Kim's root prompt (the same as above without git and the hostname is red)
 export PS1='\[\033[01;30m\]\t `if [ $? = 0 ]; then echo "\[\033[01;32m\]ツ"; else echo "\[\033[01;31m\]✗"; fi` \[\033[00;31m\]\h\[\033[00;37m\]:\[\033[00;34m\]\w\[\033[00m\] >'
 => 03:13:37 ツ mycomputer:~/code/foo >

 # Martin's root prompt
 export PS1='`if [ $? = 0 ]; then echo "\[\033[01;32m\]✔"; else echo "\[\033[01;31m\]✘"; fi` \[\033[01;30m\]\h\[\033[01;34m\] \w\[\033[35m\]$(__git_ps1 " %s") \[\033[01;31m\]\n>\[\033[00m\] '
	ADB Sideload

	What is ADB sideload?

	ADB sideload is a new feature that was added to AOSP recovery in Jelly Bean. As of version 2.3, TWRP now supports ADB sideload mode. ADB sideload is a different ADB mode that you can use to push and install a zip using one command from your computer. Most likely ADB sideload won't be very useful for your average recovery user, but ADB sideload can be a huge time-saver for a ROM developer.

	How do I use ADB sideload?

	Have a recovery installed on your device that supports ADB sideload like TWRP 2.3 or higher
	Have newer ADB binaries installed on your computer. If it's been a while since you installed ADB on your computer, you may need to get the latest ADB binaries in platform-tools from the Android SDK. You will need version 1.0.29 or higher. You can find your current version by typing "adb version" at the command line.
	Set the device into ADB sideload mode. In TWRP you do this by going to Advanced then ADB Sideload.
	From the command line, type adb sideload /path/to/rom.zip
	The file will be copied to your device to whatever the current storage location is that you have selected in the mount page. It will always be placed in the root of that storage location and named sideload.zip (e.g. /sdcard/sideload.zip) and it will automatically delete / overwrite any existing sideload.zip you may have on your device. As soon as the file is copied to your device, it will automatically be installed. When the install is finished you will be presented with a reboot system button so that you can reboot to test your zip.

	Note that sideload mode is a separate ADB mode. While in sideload mode, regular ADB commands will not work. Once the zip has been copied to the device and the install starts (or if you hit the cancel button) regular ADB mode will resume.
	env EDITOR=nano crontab -e

	00 * * * * /usr/bin/wget http://tech.hotspotsystem.com/up.php?mac=MACADDRESS\&nasid=YOUROPERATORID_YOURLOCATIONID\& uptime=`uptime\|sed s/" "/\%20/g\|sed s/:/\%3A/g\|sed s/,/\%2C/g` -O /tmp/up.html

	To run cron every minute edit crontab to look like this:
	/1 * * * /bin/echo testing123 >> /home/user/test.txt
	May 11 2011
	Gist is a really nice tool for sharing and storing snippets of code, notes, and any other text you want. It lets you create private or public Gists - basically, sets of text files.

	Sadly, it's not easy to switch a Gist from private to public (or vice versa). You can do this with a little Git-fu, since each Gist is its own Git repo. Here's how to do it.

	Copy the Private Clone URL from the Gist's page and clone the Gist to a temporary directory:

	~ $ git clone [email protected]:PRIVATEGIST.git gist-private-temp
	~ $ cd git-private-temp
	From the Gist Web interface, create a new public Gist. You will need to add some dummy text to a file in the Gist since you can't create a totally empty Gist. This file will be deleted in the next step, though.

	Copy the Private Clone URL from this new repo. Add the public Gist as a remote in your cloned copy of the private Gist, and push to it. (You'll need to do a forced push since the public Gist has the dummy file in it.)

	~/gist-private-temp/ $ git remote add public [email protected]:PUBLICGIST.git
	~/gist-private-temp/ $ git push -f public
	Finally, to get the new Gist content to appear on your Gist home page, go to the Gist's page, edit it, and resave it (without making any changes).

	I was thinking about making a script to do this, but my understanding is that the necessary Gist API methods are only available in the Github API v3, which is not yet stable; and I couldn't find any Github API libraries that support it yet.
	Mount a filesystem read-write

	Very often when you want to write files to a particular partition on ADP1, you will get a "Permission Denied" if the partition is mounted read-only.
	To get around this, you need to mount the partition read-write. Typically this is done with /system partition

	$ adb shell
	$ su
	$ mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system

	(Replace /dev/block/mtdblock3 & /system with appropriate device path and mount point, as obtained from cat /proc/mounts)
	busybox mount -o rw,remount /


	but /sbin is usually in ram so any changes will not be available after a reboot

	better to add to /system/bin
	or /data/local/bin ( with applicable PATH env )

	and in all honesty , if you have to ask.. you don't need it
	$ cat /proc/self/mountinfo better then using the standard cat /proc/mounts

	But if someone could post adb shell "mounts" and "cat /proc/partitions" it would help me see if the problem is worse than I thought regarding partitioning.
	So, I've somehow managed to screw up the partitions on my Incredible. It can't mount DATA or CACHE. I saw on this post that it is possible to re-create them, but the user over there mentions using parted. How do I get parted onto my phone? I tried just running it through the shell but it says the command is not found.

	Any help would be greatly appreciated.

	UPDATE: Fixed it. Thanks goes to -Steveo- and ciwrl over at the Cyanogen forums for helping me figure this out last night.

	Here's the solution.

	The problem was that I managed to screw up the partitions on my internal storage card, so basically nothing would work properly. I could still get into recovery, though. That's key.

	Here's what you'll need:

	Working recovery, basic knowledge of adb & the shell
	Parted (download here)
	stock PB31IMG.zip



	Note also that I had run unrevoked forever (so my phone was S-OFF) ... I'm not sure if that's required or not.

	So, grab parted from the link above. Now you need to extract the individual binaries from the .zip (the 6 files in the sdparted folder within the zip), ideally to your android-sdk\tools directory. Now push all 6 files (adb push [file] /sbin/). Next, we need to make them useable, so go into the shell (adb shell). Change to your /sbin/ directory, and run: chmod 0755 <file> on each of the 6 files.

	Now, we need to fix the partitions. This is assuming that the partitions are there, just the wrong format (which is what happened to me .. I accidentally made them FAT32 instead of ext). So, run the following: parted /dev/block/mmcblk0 mkfs ext2. It will ask if you want to continue, hit yes. When it asks for the partition number, enter 1. Next, when it asks for the format, enter ext2. Let it do its thing. Now, once it's done, run parted again. This time, enter partition 2 (everything else is the same).

	Once all that's done, your recovery program should be able to mount both the /data and /cache partitions. If that's true, you're pretty much done! One thing I found was that I couldn't directly install a new OS (I tried both Cyanogen and Ultimate). In both cases, it would look for stuff in the davik-cache that it couldn't find, so something wasn't installing correctly I think. So, if that happens, flash back to the stock PB31IMG.zip (put it in the root of your /sdcard/ and let hboot install it), and then root your phone anew. That's what I ended up doing.

	Again, huge credit for this goes to -Steveo- and ciwrl for helping me figure out which partitions were the right ones (and for supplying parted, which I hadn't been able to find anywhere). If something doesn't end up working, just drop me a pm and we'll see what we can do.
	Last edited by raskolnik; 10-08-2010 at 06:24 AM. Reason: solved!
	Partitions - summary of what partitions exist

	Storage structure

	How is storage on the tablet arranged?

	First, storage is split into internal and external. Internal storage consists of a single NAND chip, which in this case is around 4GB capacity total. External storage is on the micro SD card. The internal storage is split into many different partitions, just like a hard drive. These partitions contain things like system, boot, bootloader, recovery etc.

	We need to know what is contained in each partition in order to back up and restore them safely. There is some information on partition structure at http://linux-sunxi.org/Android/partitions but I wanted to have a poke around to see what my device is like.

	Difference between sdcard and extsd

	There caused me some confusion. A region of the internal NAND is called the internal SD card and mounted as "sdcard". The actual physical external SD card is called extsd. HOWEVER, when booted into the CWM recovery, it appears to refer to the external SD card as "sdcard"!

	Viewing output from shell commands

	The best way of viewing the output from a shell command is to pipe it to a text file, pull the text file to the computer over ADB, then view the text file. For example:

	adb shell
	adb shell "cat /proc/devices > /sdcard/output.txt"
	adb pull /sdcard/output.txt
	This runs the cat /proc/devices command to list system devices and pipes the output to output.txt which can then be viewed later.

	Let's see what we can find out. The following is performed on Mum's tablet (the good, original one) with the tablet fully booted up into Android. I'm looking at various files which contain information on devices and partitions.

	/proc/devices

	The output consists of character devices, which we're not interested in, and block devices. Here is the block devices listing:

	Block devices:
	1 ramdisk
	259 blkext
	7 loop
	8 sd
	11 sr
	65 sd
	66 sd
	67 sd
	68 sd
	69 sd
	70 sd
	71 sd
	93 nand
	128 sd
	129 sd
	130 sd
	131 sd
	132 sd
	133 sd
	134 sd
	135 sd
	179 mmc
	254 device-mapper
	The numbers are the major device numbers, which are a way of identifying physical storage devices. The two we are interested in are 93 nand and 179 mmc. These correspond to the internal NAND and external SD card (multimedia card), respectively.

	/proc/partitions

	This lists all current storage partitions. Output:

	major minor #blocks name

	93 0 16384 nanda
	93 8 16384 nandb
	93 16 32768 nandc
	93 24 524288 nandd
	93 32 1048576 nande
	93 40 16384 nandf
	93 48 32768 nandg
	93 56 262144 nandh
	93 64 131072 nandi
	93 72 1809408 nandj
	179 0 7761920 mmcblk0
	179 1 7757824 mmcblk0p1
	Note the major device numbers 93 and 179, corresponding to the internal NAND and external SD card. There are a total of 10 partitions on the internal nand, called nanda to nandj, and two on the external SD card. These partitions are all available under /dev/block/ (for example, /dev/block/nanda).

	The sizes of each partition are listed in blocks of 1024 bytes each. For example, nanda is 16384*1024=16777216 bytes=16MB in size. If we add up the sizes of each partition in the NAND (major number 93), we get a total of 3890176 blocks, or 3.98GB - i.e. the 4GB internal storage.

	/etc/vold.fstab

	Doesn't contain much. Relevant line:

	dev_mount sdcard /mnt/sdcard auto /devices/virtual/block/nandj
	Suggests that nandj corresponds to sdcard (the internal SD card). Size-wise, this is about 1.8GB.

	/proc/mounts

	Output (relevant lines only):

	/dev/block/nandd /system ext4 rw,nodev,noatime,user_xattr,barrier=0,data=ordered 0 0
	/dev/block/nande /data ext4 rw,nosuid,nodev,noatime,user_xattr,barrier=0,journal_checksum,data=ordered,noauto_da_alloc 0 0
	/dev/block/nandh /cache ext4 rw,nosuid,nodev,noatime,user_xattr,barrier=0,journal_checksum,data=ordered,noauto_da_alloc 0 0
	/dev/block/vold/179:1 /mnt/extsd vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
	/dev/block/vold/93:72 /mnt/sdcard vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
	We can see that nandd is /system, nande is /data and nandh is /cache. The external SD card (identified by major:minor numbers 179:1) is mounted to /mnt/extsd, and the internal SD card (93:72) to /mnt/sdcard. The major:minor numbers confirm that the internal SD card is nandj (compare with with /proc/partitions output).

	busybox df

	The df command lists the space usage of current partitions. The busybox version of the command gives a more detailed output:

	Filesystem 1K-blocks Used Available Use% Mounted on
	tmpfs 180968 44 180924 0% /dev
	tmpfs 180968 0 180968 0% /mnt/asec
	tmpfs 180968 0 180968 0% /mnt/obb
	/dev/block/nandd 516040 269540 246500 52% /system
	/dev/block/nande 1032088 88152 943936 9% /data
	/dev/block/nandh 258016 4236 253780 2% /cache
	/dev/block/vold/179:1
	7753728 64 7753664 0% /mnt/extsd
	/dev/block/vold/93:72
	1904156 7852 1896304 0% /mnt/sdcard
	/dev/block/vold/93:72
	1904156 7852 1896304 0% /mnt/secure/asec
	dmesg

	Another command which gives some very useful information is dmesg (see http://en.wikipedia.org/wiki/Dmesg and http://www.linfo.org/dmesg.html. This lists all messages produced by the kernel during (and sometimes after) startup. Buried in the messages are some on the disk structure. To see these, run this from an adb shell prompt and pull the resulting text file back to the computer for viewing:

	dmesg \| busybox grep "disk name" > /sdcard/dmesg.txt
	The output from dmesg is piped to grep, which displays only those lines containing the text "disk name", and the output from grep is dumped into the dmesg.txt text file. Here's the result:

	<4>[ 0.185665] The 0 disk name = bootloader, class name = DISK, disk size = -544396252
	<4>[ 0.185684] The 1 disk name = env, class name = DISK, disk size = -544396188
	<4>[ 0.185694] The 2 disk name = boot, class name = DISK, disk size = -544396124
	<4>[ 0.185704] The 3 disk name = system, class name = DISK, disk size = -544396060
	<4>[ 0.185713] The 4 disk name = data, class name = DISK, disk size = -544395996
	<4>[ 0.185723] The 5 disk name = misc, class name = DISK, disk size = -544395932
	<4>[ 0.185733] The 6 disk name = recovery, class name = DISK, disk size = -544395868
	<4>[ 0.185743] The 7 disk name = cache, class name = DISK, disk size = -544395804
	<4>[ 0.185752] The 8 disk name = databk, class name = DISK, disk size = -544395740
	<4>[ 0.185762] The 9 disk name = UDISK, class name = DISK, disk size = -544395676
	Note some oddities. The #8 partition is called "databk", suggesting "data backup". This partition is called "emmc" when booted into CWM recovery. Also note #9 is called UDISK - this is the "internal" SD card, called "sdcard" elsewhere.

	Summary

	Here's a quick summary of the partitions.

	Block name Name/purpose Filesystem type
	---------- ------------ ---------------
	nanda bootloader vfat
	nandb environment raw
	nandc boot raw
	nandd system ext4
	nande data ext4
	nandf misc raw
	nandg recovery raw
	nandh cache ext4
	nandi emmc ext4
	nandj sdcard vfat
	Back to index
	export PS1='\h \w$(__git_ps1 "(%s)") \$ '
	=> mycomputer ~/apps/chess/tmp(master) $ _

	export PS1='\[\e[33m\]\h\[\e[0m\]:\W\[\e[33m\]$(__git_ps1 "(%s)")\[\e[0m\] \u\$ '
	=> mycomputer:tmp(master) tom$ _

	# Henning's awesome TRON prompt 2.0.2 with current Git branch and success state of the last command (the syntax coloring here does not do it justice):
	export PS1='`if [ $? = 0 ]; then echo "\[\033[01;32m\]✔"; else echo "\[\033[01;31m\]✘"; fi` \[\033[01;30m\]\h\[\033[01;34m\] \w\[\033[35m\]$(__git_ps1 " %s") \[\033[01;30m\]>\[\033[00m\] '
	=> ✔ mycomputer ~/projects/platforms master > _

	# Arne's epic timestamped prompt with return status indicator and status-colored (green if fresh, or red if unstaged, or yellow if staged) git branch:
	export PS1='\[\e[01;30m\]\t`if [ $? = 0 ]; then echo "\[\e[32m\] ✔ "; else echo "\[\e[31m\] ✘ "; fi`\[\e[00;37m\]\u\[\e[01;37m\]:`[[ $(git status 2> /dev/null \| head -n2 \| tail -n1) != "# Changes to be committed:" ]] && echo "\[\e[31m\]" \|\| echo "\[\e[33m\]"``[[ $(git status 2> /dev/null \| tail -n1) != "nothing to commit (working directory clean)" ]] \|\| echo "\[\e[32m\]"`$(__git_ps1 "(%s)\[\e[00m\]")\[\e[01;34m\]\w\[\e[00m\]\$ '
	=> 03:13:37 ✔ arne:(master)~/projects/geordi$ _

	# Arne's danger prompt for root use. No git information and alarming red and yellow (which you can't see here):
	export PS1='\[\e[01;30m\]\t \[\e[31m\]\u\[\e[37m\]:\[\e[33m\]\w\[\e[31m\]\$\[\033[00m\] '
	=> 03:13:37 root:/tmp/foo# _

	# Kim's mix of those above with small changes. TRON promt with timestamp, return status indicator, hostname, git informations and working directory (but all non-bold).
	export PS1='\[\033[01;30m\]\t `if [ $? = 0 ]; then echo "\[\033[01;32m\]ツ"; else echo "\[\033[01;31m\]✗"; fi` \[\033[00;32m\]\h\[\033[00;37m\]:\[\033[31m\]$(__git_ps1 "(%s)\[\033[01m\]")\[\033[00;34m\]\w\[\033[00m\] >'
	=> 03:13:37 ツ mycomputer:(master)~/code/foo >

	# Kim's root prompt (the same as above without git and the hostname is red)
	export PS1='\[\033[01;30m\]\t `if [ $? = 0 ]; then echo "\[\033[01;32m\]ツ"; else echo "\[\033[01;31m\]✗"; fi` \[\033[00;31m\]\h\[\033[00;37m\]:\[\033[00;34m\]\w\[\033[00m\] >'
	=> 03:13:37 ツ mycomputer:~/code/foo >

	# Martin's root prompt
	export PS1='`if [ $? = 0 ]; then echo "\[\033[01;32m\]✔"; else echo "\[\033[01;31m\]✘"; fi` \[\033[01;30m\]\h\[\033[01;34m\] \w\[\033[35m\]$(__git_ps1 " %s") \[\033[01;31m\]\n>\[\033[00m\] '