On my Samsung Note 10.1, I would like to be able to mount a different userdata partition. My goal is to achieve this at boot by modifying the init.rc script, since this seems to be setting up all file systems and mounting the partitions userdata, system, and so on. For example, there is a line mkdir /data 0771 system system, which sounds to me as if it sets up the mount point for the userdata partition. The userdata partition corresponds to block device /dev/block/mmcblk0p12.
Now, what I want is instead of mounting mmcblk0p12, I want to mount an image of mmcblk0p12, which I have placed on a µSD-Card inserted in the device. The µSD-Card is accessible via block device /dev/block/vold/179:17. This means that I would first need to mount the µSD-Card and then the image on the µSD-Card.
But this is where I fail. I can't figure out how to mount the µSD-Card in the init.rc, not to mention how to mount the image afterwards. I've added the line mount -t ext4 /dev/block/vold/179\:17 /mnt/extSdCard multiple times, but all it gives me is a boot loop.
So, does anyone know how to do this?
EDIT1: apparently the partitions get mounted in fstab.sdmk4x12, so I added the line /dev/block/vold/179\:17 /mnt/extSdCard ext 4 noatime,nosuid,nodev,discard,noauto_da_alloc,journal_async_commit,erros=panic wait,check. This unfortunately did not work, but kernel log gave me Cannot mount filesystem on /dev/block/vold/179\:17 at /mnt/extSdCard.
EDIT2: stupid of me not to use /dev/block/mmcblk1p1, which is the partition of the µSD-Card. This way I was now able to mount the µSD-Card by modifying the fstab.sdmk4x12 file.
EDIT3: after I was able to mount the µSD-Card, the problem of how to mount the image remains. I've modified the line where it mounts the userdata partition. The line is the same as the one from EDIT1+2, but uses the image /storage/extSdCard/userdata.img to mount it to /data. But I guess it apparently fails to mount the image. The device boots up, but displays some error, stating the userdata partition is damaged. It also gives me the option to reset it, but of course this only affects the userdata partition, and as soon as I reboot, it is trying to mount my image again, fails and shows me this error again.
I have found a workaround. Instead of trying to mount the image, I just copied all files from /data onto the partition on the µSD-Card, and mounted the partition as /data in the fstab.sdmk4x12 (i.e., mounting /dev/block/mmcblk1p1 as /data). All apps etc. will now be stored on the partition on the µSD-Card.
Related
I've partitioned my 32GB, class 10, SD card in the following way: 30GB FAT32, 2GB ext for the applications (to use with Link2SD Pro).
However, as soon as I reboot the system after transferring any app, second partition can't be mounted and I have no idea why is it happening.
I've tried ext2/3/4 with the exactly same results.
System mounts second partition without a problem until I put something on it, and then it won't do it again.
I've formatted the card using Partition Wizard, Recovery (TWRP 2.7.1.0), manually (adb shell) and nothing seems to make a difference.
The partition is still there (fdisk sees it) I just can't mount it.
If I run e2fsck on the ext partition (with -y) it just goes into infinite loop inode error
I did a surface test of the card but there are no errors present.
OS is FusionX (JB 4.1), phone Huawei Ascend G330.
Any help is appreciated!
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)
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!
Im working on "mount ntfs sdcard"
That is problem:
- If i mount sdcard to another folder than /mtn/sdcard then my sdcard working find
- If i mount it to /mnt/sdcard then android not except it : " The SDcard is not currently mounted"
In adb shell i type mount command and see that my SDcard is mounted to /mnt/sdcard
But infact SDcard folder cannot accessable.
I think android doesnt except mount ntfs sdcard on /mnt/sdcard because it programed to mount vfat sdcard on /mnt/sdcard.
Now the question: where i can find mounting code or mounting procedure of android when we insert SDcard? i want to modify it to accept ntfs sdcard.
P/S: im on GB 2.3.6
This is a very specific question, I doubt you will get an answer here. You might want to try to locate it yourself from the source code which could be found here:
https://sites.google.com/a/android.com/opensource/download
I did some googling and found this:
http://cateee.net/lkddb/web-lkddb/NTFS_FS.html, you might need to modify it.
On Android, the mounting of the sdcard is managed by the vold daemon.
If you want a stable system, you likely need to either get vold to manage your custom mount, remove vold from the system and do it's entire job yourself, or somehow get it and your custom solution to stay out of each other's way.
Lots of custom ROMs have used vold in different ways - to partition an sdcard and add a unix-style filesystem for storing apps, to put an entire alternate android installation on an sdcard or tablet internal storage area, etc. You might get some ideas by looking at those, reading their development discussion history, etc.
I want to have access to an ext4 partition, without using Data2SD yet, on the SD card of my HTC Vision running the Virtuous Unity 1.3.0 ROM. I modded my /system/etc/vold.fstab file from this:
dev_mount sdcard /mnt/sdcard auto /devices/platform/goldfish_mmc.0
/devices/platform/msm_sdcc.4/mmc_host/mmc2
To this:
#dev_mount sdcard /mnt/sdcard auto /devices/platform/goldfish_mmc.0
/devices/platform/msm_sdcc.4/mmc_host/mmc2
dev_mount sdcard /mnt/sdcard 1 /devices/platform/goldfish_mmc.0 /devices/platform/msm_sdcc.4/mmc_host/mmc2
dev_mount e4vol /mnt/sdcard2 2 /devices/platform/goldfish_mmc.0
/devices/platform/msm_sdcc.4/mmc_host/mmc2
So I can get my second partition, with label e4vol, mount and usable on my Android device. Two issues, and I think one obviously has to do with the other.
I have tried remounting the root read-write and creating the mount point /mnt/sdcard2, but it is gone on reboot. Seems like Android might have in the past created such mounts with mount.conf. Now it does not exist on Gingerbread ROMS. Thoughts?
Is this all I would have to do to get my second partition mounted in Android, or do I also need to create /sdcard2 like /sdcard? I presume both are created as symlinks by vold as specified in this conf file, but I have not had time to check yet.
I would ask forums, but this seems like a developer question and this is the most recent release of the OS. It seems to change a lot from version to version of the OS. Thanks in advance for your patience and help.
UPDATE: So, moved the test mount to sdcard, and it did not work, even with a persistent mount point. So, not sure where I am going wrong.
Maybe you'll have to have a look into /init.rc.
There are some "mkdir /mnt/..."-statements. You only have to add your "mkdir /mnt/sdcard2" and "ln -s /mnt/sdcard2 /sdcard2" to this file.
But be careful when editing this file!!!
I looked at the vold source up to including Icecream-Sandwich: it’s final mount() system call is hardcoded to the “vfat” file system type. – Even if you get it to try the mount, it would fail.
I myself actually want to mount my ext4 SD card to /sdcard, because I regularly suffer from SD card FAT file system corruptions (and I’m not the only one having those with Android).
The alternative is: modify the init/boot process to just mount the partition where you want, bypassing vold.
On the emulator, I can unmount the SD card from the Settings.
I can then mount it on my OS, then unmount it normally.
I haven't been able to figure out how to re-mount it then on the emulator (without rebooting it).
hints:
the adb command remount is unrelated: it's about /system
the emulator command is unrelated: it's only about starting the emulator
mounting the SD card in two places of course messing everything up (I tried)
more:
mount outputs the following:
/dev/block//vold/179:0 /sdcard vfat rw,dirsync,nosuid,nodev,noexec,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
trying to mount again from the shell after unmounting it, using the same options as above, gives a segfault
no idea why the double slash in block//vold, I guess it's just a typo
The developers guide suggests that this isn't possible:
SD Card Emulation
You can create a disk image and then
load it to the emulator at startup, to
simulate the presence of a user's SD
card in the device. To do this, you
can use the android tool to create a
new SD card image with a new AVD, or
you can use the mksdcard utility
included in the SDK.
The sections below describe how to
create an SD card disk image, how to
copy files to it, and how to load it
in the emulator at startup.
Note that you can only load disk image
at emulator startup. Similarly, you
can not remove a simulated SD card
from a running emulator. However, you
can browse, send files to, and
copy/remove files from a simulated SD
card either with adb or the emulator.
The emulator supports emulated SDHC
cards, so you can create an SD card
image of any size up to 128 gigabytes.
While Android will unmount the SD card, the emulator process keeps the backing file open.
$ ls -go /proc/`pidof emulator`/fd | grep sdcard.img
lrwx------ 1 64 2010-05-13 01:50 10 -> /home/x/.android/avd/WithSD.avd/sdcard.img
Someone more familiar with QEMU may be able to provide further insight but, if I were you, I would just try to use NFS to solve this problem.
I tried going to Settings and unmounting the SD card and this worked fine. Give it a try; remounting it is quite simple.
Doesn't seem like this can be done via adb/cli though.