Mount an SD card manually from adb shell in androi

Question

I have an android 4.1 phone (Lenovo 820). After some changes aimed at partitioning the internal SD ram (which changed , the phone will no longer mount the external SD card. I am good-ish at Linux, but I have never seen the Android shell before today.

I would love to know the steps to:

• Get the list of available devices representing SD cards
• Manually mount the SD card -- the mount command won't work as it says can't read /etc/fstab -- how do you mount things?
• Get the SDcard to mount at boot time

My /etc/system/vold.fstab has:

dev_mount sdcard /storage/sdcard0 emmc@fat /devices/platform/goldfish_mmc.0 /devices/platform/mtk-msdc.0/mmc_host
dev_mount sdcard2 /storage/sdcard1 auto /devices/platform/goldfish_mmc.1 /devices/platform/mtk-msdc.1/mmc_host

Mount is now:

rootfs on / type rootfs (ro,relatime)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,mode=755)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
none on /acct type cgroup (rw,relatime,cpuacct)
tmpfs on /mnt/secure type tmpfs (rw,relatime,mode=700)
tmpfs on /mnt/asec type tmpfs (rw,relatime,mode=755,gid=1000)
tmpfs on /mnt/obb type tmpfs (rw,relatime,mode=755,gid=1000)
none on /dev/cpuctl type cgroup (rw,relatime,cpu)
/emmc@android on /system type ext4 (ro,relatime,nobarrier,noauto_da_alloc,commit=1)
/emmc@usrdata on /data type ext4 (rw,nosuid,nodev,noatime,nodiratime,discard,nobarrier,noauto_da_alloc)
/emmc@cache on /cache type ext4 (rw,nosuid,nodev,noatime,nodiratime,discard,nobarrier,noauto_da_alloc)
/emmc@protect_f on /protect_f type ext4 (rw,nosuid,nodev,noatime,nodelalloc,noauto_da_alloc,commit=1,data=ordered)
/emmc@protect_s on /protect_s type ext4 (rw,nosuid,nodev,noatime,nodelalloc,noauto_da_alloc,commit=1,data=ordered)

Answer 1

I can't believe no one has responded to you in 2 months? Wow...how slack!

Well anyway I spose I should fill you in on some info as well as ask some questions. 1). Have you got root access or did you pull the system vold from a release image/firmware? Like Linux SuperUser rights? 2). If you have root access/super user rights how did you obtain it? I mean what method did you use to gain root access? Was it via some scripts/binaries and a known exploit? Or was it flashed by the means of a rooted kernel? The reason I ask is that root access isn't just root access as most people are lead to believe; there are varying levels of root access. For instance you may have full root access as a user on the device, but come time when you want to manipulate your system remotely say from command line of your favorite Linux distro then you may find that root access isn't all it's cracked up to be. If you used an exploit and not a kernel then chances are that you only have system level root access, and ADB (android debug bridge) to your PC will be faced with various messages like "access denied", "unable to obtain superuser privileges" or "adb cannot run as root in production builds" or something similar to this. The reason this happens is because unlike some specialised developer kernels root via an exploit doesn't make the kernel insecure. I would recommend you do a bit of reading on what an insecure kernel is and if it is suitable for what you are hoping to achieve. The reason I say that is because on some devices having an insecure kernel is not ideal as it can trigger some unwanted system flags (some permanent and irreversible according to some manufacturers) and are used against developers to not honor warranty or as a means of extracting money for premium repair services to devices (regardless of if you the developer hoping to make some break through discoveries...caused the damage to the device or not? which sux). I think your device should be ok...? But I'm not 100% sure so do some research.

If you find that you cannot run an insecure kernel it is not the end of the world, it just requires a little bit more work to get what you want, which I will elaborate with examples in a moment.

Next thing you should probably consider is what you are hoping to do when you get where you want in/on the device? Have you thought that far? If so you may realise that the standard Android console/shell is rather dismal and ill equiped for tools to do all the great things you have been able to do with a blink of an eye on your Linux computer; that means you are going to need some support tools like "busybox" as well as possibly some others as well, like for instance if you are working on some databases you'd probably want sqlite3, you probably need the actual bash binary to extend your shell a bit. You would also want to look at not only just obtaining these binaries but possibly where they should be located on your system for ease of access otherwise you are going to get rather tired of typing huge long paths in the console to reach certain areas of your device like your sdcard. You will be familiar with symlinks having used Linux, well Android is no different only that a lot of the system of Android uses container like environment for applications. When dealing with this there can be some hurdles to overcome as the system has security checks in place to try stop intrusion by unwanted 3rd parties. That is what keeps most developers safe knowing that their (and your) personal data is protected, however when this is you and you want to go in to these areas of the device you need to have your tools setup correctly. Most Android tinkerers use a modified recovery image (or a custom one - not too dissimilar to the custom kernel concept) that allows them to modify the system while it is offline through the means of mostly a simple zip file with embedded instructional script, binary and a manifest (research signed and unsigned zips for Android custom recoverys - I won't go in to detail about that but it is important). You could essentially package up all of your tools into a single zip and "flash" install the components into the areas of the system you require and symlink the same files to various other locations as well.

Lets look at some examples now shall we - say you have root access cause you used an exploit on your device but have secured kernel still note: secured kernel = ro.debugable=0 within your system default.prop file (generated at boot time and not found or located within most firmware packages). If you want to allow adb to have root access you are going to need to change that file and in particular the line I mentioned above. There may also be other requirements so you should look into what your device needs e.g. The Galaxy Tab I am repairing at the moment is older so uses mass storage instead of media transfer protocol, so I need to tell adb to keep the connection open and solid (not time out and disconnect) when engaged with the device; this happens to be done through the default.prop file as well. The difficulty comes when you want to change this file; most people decompile the kernel and the ramdisk and edit it directly and recompile and then reflash it to the device mainly because adb obviously doesn't have root access at the moment. You can pull the file from the system like so:

adb pull default.prop default.prop

(Thats if you have adb on your PC distro environment path)

This will bring the straight you, only the problem is when you want to put it back after changing it can be rather difficult. Various solutions are about, I hear a lot of pushing it to SDcard /emmc/storage/sdcard0/default.prop or /tmp/default.prop and then requiring you as "SuperUser" on the device using something like terminal emulator, script manager or root explorer to put the file back in place and give it the correct permissions.

typing adb remount on a device with secure kernel will allow you to remount the whole system as read-write and you can do as you please. If insecure though you may end up doing something like

adb root
remount

or you might end up finding that your whole console has no superuser rights what so ever, so you would be required to adb shell into the device shell (where it or you has superuser rights) and then executing the commands you want to try.

adb shell
su
mount -o rw /system
remount /system

I have discovered recently that you can obtain the same level of access through a single line at the adb console and single return key like so:

adb shell su -c mount -o rw,remount /system

This passes the arguments in single string adb shell -> superuser access -> pass command -> mount as read-write -> remount command -> to the system partition.

You could if you like use the above command to gain superuser rights from the console and echo strings into the default.prop file without the need of decompiling the kernel.

In my case I just repeated the same commands a few times and overwrote the default.prop with the same content only adjusting specific variables to my liking like so: note the first line only uses 1 > so this effectively wipes or overwrites the default.prop file, hence the rest of the lines need to also follow. I use 2 > like >> because this appends to the following line of the file.

adb shell su -c echo ro.secure=1>default.prop
adb shell su -c echo ro.allow.mock.location=0>>default.prop
adb shell su -c echo ro.debuggable=1>>default.prop
adb shell su -c echo persist.sys.usb.config=mass_storage,adb>>default.prop
adb shell su -c echo persist.service.adb.enable=0>>default.prop

This is rather fast and effective for 4 or 5 lines of code, but this is not practical when you are rewriting a large file with many lines of test. You may want to look at things like grep with looping functions in a bash script to filter specific lines of the large text/script/config file, however for this example and probably for your system vold file this should be sufficient.

I think this should be enough to (excuse the pun) ARM you with enough info to be dangerous :) On that note, please make sure you have got a backup of your device, before you go messing with the system. They are very similar to linux but they are also very different too! Heed this warning, MAKE SURE YOU BACK UP YOUR EFS PARTITION STRAIGHT AWAY!! Efs contains the device IMEI number and this is something you really don't want corrupted or lost. I have seen first hand what can happen; you don't even need to call the EFS partition by accident to break it....you only need make an error calling an explicit path to the incorrect partition and it can obliterate your IMEI!