Vegan ginger - loaded the standard with pershoot kernel but it has no cifs support. Replaced with clemsyn and cifs was great but after rebooting my screen hung and eventually I had to revert to my original without cuts. I think there is a way to instruct the pershoot kernel to load cifs support even thought it isn't compiled into the kernel. I'm looking for some step by step instructions to learn how to do that. Anyone know how?
How about reading the instructions posted by pershoots on the very same page from which you downloaded the kernel ?!?
To use one of the kernel modules:
Pull the one you want from lib-2632.39.tar.gz (winrar can open this),
adb remount
adb push MODULE.ko /system/lib/modules/2.6.32.39-cyanogenmod/
adb shell chmod 644 /system/lib/modules/2.6.32.39-cyanogenmod/MODULE.ko
adb shell insmod /system/lib/modules/2.6.32.39-cyanogenmod/MODULE.ko
Click to expand...
Click to collapse
- if you don't use adb then just use "terminal emulator" (from the market or preloaded with the some ROMs).
- replace "MODULE" with "cifs"
- use the lib file appropriate to your ROM and bootloader.
Best of luck,
Yeah - that was helpful !
"How about reading the instructions posted by pershoots on THE VERY SAME PAGE FROM WHICH YOU DOWNLOADED THE KERNEL?!?"
Having a bad day were we???
The kernel came with the rom so I never downloaded a kernel and had no idea where the page was - your link was helpful in that it took me to that page (not on xda forum) so I was able to download the library anyway. Sadly, I am not using cyanogen so the paths listed in the instructions don't apply I don't think. I'm also not using adb yet although I'm working up to it. I can use terminal emulator so that shouldn't be a problem assuming I find where to put the module. Possibly it can go anywhere in the system/lib/modules directory as long as I can point to it? I guess we'll have to try it and see.
The real question that you have raised is "use the lib file appropriate to your ROM and bootloader." How do you determine what is "appropriate"?
So perhaps someone would be willing to share a tad more knowledge and perhaps we will have a thread that other g-tab owners can use to learn from.
Pushing modules in the kernel is the same no matter the rom and vegan ginger is built from cm source anyway
thebadfrog said:
Pushing modules in the kernel is the same no matter the rom and vegan ginger is built from cm source anyway
Click to expand...
Click to collapse
So I downloaded lib-2632.39.tar.gz and unpacked it, searched around and found the cifs.ko file. I'm guessing that I can put that anywhere logical in /system/library and point to it. My app (CIFS Manager) has an option to load via insmod and asks for a path to it. I'm assuming that insmod is available and my app will call it to load the module? I'd also like to know how I would know without someone telling me that the module was in lib-2632.39.tar.gz? Is there some rationale that would tell me how this library and the kernel are related or are these libraries just generic in some way? Thanks for the helping hand.
http://forum.xda-developers.com/showthread.php?t=903505
enigma0456 said:
I would know without someone telling me that the module was in lib-2632.39.tar.gz?
Click to expand...
Click to collapse
The kernel developers who provide the kernels and the extra optional modules provide information on their blogs when they post the availability of the kernel. For example, pershoot's blog has this info, as well as install instructions.
or you ask here.
enigma0456 said:
The kernel came with the rom so I never downloaded a kernel and had no idea where the page was.
Click to expand...
Click to collapse
Sorry I mistakenly assumed since you mentioned pershoot that you have been to his thread (the most active in the development section).
enigma0456 said:
Possibly it can go anywhere in the system/lib/modules directory as long as I can point to it?
Click to expand...
Click to collapse
Yes you certainly can.
enigma0456 said:
How do you determine what is "appropriate"?
Click to expand...
Click to collapse
If you have a gingerbread based ROM download the the lib file with "gb" in its file name.
If you have a the new bootloader on the your gtab use the ones with "newbl" in the file name.
enigma0456 said:
So I downloaded lib-2632.39.tar.gz and unpacked it, searched around and found the cifs.ko file.
Click to expand...
Click to collapse
Thats the wrong file (this is the one for Froyo ROMs).
enigma0456 said:
I'm assuming that insmod is available and my app will call it to load the module?
Click to expand...
Click to collapse
True
enigma0456 said:
I'd also like to know how I would know without someone telling me that the module was in lib-2632.39.tar.gz?
Click to expand...
Click to collapse
You wouldn't.
enigma0456 said:
Is there some rationale that would tell me how this library and the kernel are related or are these libraries just generic in some way?
Click to expand...
Click to collapse
There isn't any, just the developers choice.
^^^^ Good job lol
Thanks - that was really helpful. I like direct answers to questions. So I went and got the right library (looked for gb in name as directed). Moved the module onto my tab into a download directory via usb. Went to /System/Lib via terminal and there was no modules directory. I tried to make one and got an error that the file system is mounted read only. Arghhh I remember fighting with this when I was trying to install another keyboard. I never was able to resolve it. Theoretically "remount" should work but I searched and tried all different examples and I was never able to get it to work for me. I tested my cifs manager and it errors out - providing a base that cifs doesn't work without the module. I'm going to try pointing it at my download folder for now to see if the module would work. That is pretty messy so I would still like to put it in the proper place - if you feel up to it would you instruct me on how to overcome the deadly "mounted read only" file system problem?
________________________________
Update - put the cifs.ko file in /sdcard/download. Went into cifs manager and told it to load via insmod. Made path to cifs.ko = /sdcard/download (also tried /sdcard/download/cifs.ko) In all cases I get the message "... failed no such device". If I turn off the insmod feature I get the same message which leads me to believe that the cifs.ko isn't loading. As a test, I am using the exact same path to share, mount point, etc. on my other tab running Clemsyn/Calkulin that has cifs built into the kernel and it connects almost instantly. It is likely therefor that my problem revolves around this kernel loading cifs. Not sure what I'm doing wrong but suggestions are welcome.
enigma0456 said:
I'm guessing that I can put that anywhere logical in /system/library and point to it.
Click to expand...
Click to collapse
It's better if you put it in the standard place. What's the standard place? The paths in the kernel zip file and the module tar file should give you a clue:
Code:
$ tar -tzvf /mnt/sdcard/kernel/lib-2632.39_gb.tar.gz
drwxr-xr-x root/root 0 2011-04-30 20:14:37 lib/
drwxr-xr-x root/root 0 2011-04-30 20:14:37 lib/modules/
drwxr-xr-x root/root 0 2011-04-30 20:14:37 lib/modules/2.6.32.39-cyanogenmod/
-rw-r--r-- root/root 73 2011-04-30 20:14:37 lib/modules/2.6.32.39-cyanogenmod/modules.ieee1394map
-rw-r--r-- root/root 10709 2011-04-30 20:14:37 lib/modules/2.6.32.39-cyanogenmod/modules.symbols.bin
-rw-r--r-- root/root 271 2011-04-30 20:14:37 lib/modules/2.6.32.39-cyanogenmod/modules.alias
drwxr-xr-x root/root 0 2011-04-30 20:14:37 lib/modules/2.6.32.39-cyanogenmod/kernel/
drwxr-xr-x root/root 0 2011-04-30 20:14:37 lib/modules/2.6.32.39-cyanogenmod/kernel/net/
drwxr-xr-x root/root 0 2011-04-30 20:14:37 lib/modules/2.6.32.39-cyanogenmod/kernel/net/sunrpc/
drwxr-xr-x root/root 0 2011-04-30 20:14:37 lib/modules/2.6.32.39-cyanogenmod/kernel/net/sunrpc/auth_gss/
-rw-r--r-- root/root 408035 2011-04-30 20:14:37 lib/modules/2.6.32.39-cyanogenmod/kernel/net/sunrpc/auth_gss/rpcsec_gss_krb5.ko
-rw-r--r-- root/root 532157 2011-04-30 20:14:37 lib/modules/2.6.32.39-cyanogenmod/kernel/net/sunrpc/auth_gss/auth_rpcgss.ko
-rw-r--r-- root/root 3424305 2011-04-30 20:14:37 lib/modules/2.6.32.39-cyanogenmod/kernel/net/sunrpc/sunrpc.ko
Looks like the kernel modules need to be in a lib/modules/KERNEL-VERSION/ directory. That looks very Linux-ish. Can we just untar it to / as we do in Linux? Better check:
Code:
$ ls -l / | /system/xbin/fgrep lib
$
Yikes! No /lib directory at all on Android. Where the heck do the kernel modules go? Let's look at the kernel zip file to see if there is a clue--the unzip on the gTablet doesn't understand this zip file format, so check on a Linux system:
Code:
$ unzip -l boot-cm_2632.39_gb-oc-uv-xtra-vfp_fp-043011.zip
Archive: boot-cm_2632.39_gb-oc-uv-xtra-vfp_fp-043011.zip
Length Date Time Name
--------- ---------- ----- ----
1123 2008-02-28 21:33 META-INF/MANIFEST.MF
1176 2008-02-28 21:33 META-INF/CERT.SF
1714 2008-02-28 21:33 META-INF/CERT.RSA
252000 2008-02-28 19:33 META-INF/com/google/android/update-binary
1015 2098-06-15 19:23 META-INF/com/google/android/updater-script
88544 2098-01-27 05:41 kernel/dump_image
76132 2098-01-27 05:54 kernel/mkbootimg
303 2098-03-22 09:35 kernel/mkbootimg.sh
70992 2098-01-27 05:53 kernel/unpackbootimg
56 2098-01-27 06:09 kernel/unpackbootimg.sh
2219848 2098-06-22 03:05 kernel/zImage
12234 2098-03-04 12:32 system/lib/hw/wlan/LICENSE.TXT
258778 2011-04-30 16:14 system/lib/hw/wlan/bcm4329.ko
249144 2011-04-11 01:13 system/lib/hw/wlan/fw_bcm4329.bin
249467 2011-04-11 01:13 system/lib/hw/wlan/fw_bcm4329_apsta.bin
0 2011-01-07 02:11 system/lib/modules/2.6.32.39-cyanogenmod/placeholder
--------- -------
3482526 16 files
Hmm, there is a placeholder file in system/lib/modules/KERNEL-VERSION/, so /system's where the modules are supposed to go.
Code:
$ su
# /system/xbin/mount -w -o remount /system
# cd /system
# /system/xbin/tar -xzvf /mnt/sdcard/kernel/lib-2632.39_gb.tar.gz
# /system/xbin/mount -r -o remount /system
My app (CIFS Manager) has an option to load via insmod and asks for a path to it. I'm assuming that insmod is available and my app will call it to load the module?
Click to expand...
Click to collapse
Asks a path to what? Insmod or the kernel module?
I'd also like to know how I would know without someone telling me that the module was in lib-2632.39.tar.gz?
Click to expand...
Click to collapse
Kernel functionality, like filesystems, are either built into the kernel or added using kernel modules. (You can also have filesystems implemented in userspace, but, we'll skip that complexity for now). So, the guy who gave you the kernel would either have compiled the filesystem in or must supply the module file for it. First, check if the filesystem is built-in:
Code:
$ cat /proc/filesystems
nodev sysfs
nodev rootfs
nodev bdev
nodev proc
nodev tmpfs
nodev debugfs
nodev sockfs
nodev usbfs
nodev pipefs
nodev anon_inodefs
nodev inotifyfs
nodev configfs
nodev devpts
ext3
ext2
ext4
nodev ramfs
vfat
msdos
yaffs
yaffs2
No CIFS, so it's not compiled in; we'll have to load the module:
Code:
$ su
# insmod /system/lib/modules/2.6.32.39-cyanogenmod/kernel/fs/cifs/cifs.ko
# cat /proc/filesystems
nodev sysfs
nodev rootfs
nodev bdev
nodev proc
nodev tmpfs
nodev debugfs
nodev sockfs
nodev usbfs
nodev pipefs
nodev anon_inodefs
nodev inotifyfs
nodev configfs
nodev devpts
ext3
ext2
ext4
nodev ramfs
vfat
msdos
yaffs
yaffs2
nodev cifs
Yup, CIFS is there now. But, this sort of thing gets tedious. You can use a shell script to make things easier. Here's what I use to mount my external USB HDD:
Code:
#!/system/bin/sh
PATH=/system/bin:/system/xbin
lsmod | fgrep -q nls_utf8 || insmod /system/lib/modules/`uname -r`/kernel/fs/nls/nls_utf8.ko
lsmod | fgrep -q ntfs || insmod /system/lib/modules/`uname -r`/kernel/fs/ntfs/ntfs.ko
exec mount -r -t ntfs -o fmask=0111,dmask=0022,nls=utf8 /dev/block/sda1 /mnt/usbdisk
Just save the file somewhere and make it executable and run the script as superuser to mount the USB HDD.
Is there some rationale that would tell me how this library and the kernel are related or are these libraries just generic in some way?
Click to expand...
Click to collapse
Since these are kernel modules, they are by definition related, no?
Note that you need a Terminal Emulator and the Superuser app (both from Market) and busybox (also from Market) for the above commands to work. Also, do not type in the prompts (the '$' and '#' characters) at the beginning of the commands. They are there as a reference to show you when you're in superuser mode and when you're a normal user.
enigma0456 said:
I tried to make one and got an error that the file system is mounted read only.
Click to expand...
Click to collapse
remount is specific to "adb", the equivalent in terminal emulator is:
Code:
su root
mount -o remount,rw /system
cp /sdcard/download/cifs.ko /system/lib/modules/cifs.ko
chmod 644 /system/lib/modules/cifs.ko
mount -o remount,ro /system
Then just use "Mount Manager" to load the copied CIFS module, might want to reboot if mount manager failed to do the insmod.
I have been using the above procedure with all pershoot's kernels without a problem.
This should solve your problem,
Best of luck,
I coludn't make it work either. It was in the right folder, suposedly "loaded" but it wasn't working.
I am on the Caulkin/Clemsyn ver 5 (the 1.5GHz) now - exactly because of this inability to load that module. I don't know why pershoot doesn't make it part of the kernel, maybe he doesn't have a PC in the house
Sure, the whole typing thingie in linux/android looks easy if that is what you do 24/7. But for less accustomed with that, all this is likely a turn-off.
SoNic67 said:
I coludn't make it work either. It was in the right folder, suposedly "loaded" but it wasn't working.
I am on the Caulkin/Clemsyn ver 5 (the 1.5GHz) now - exactly because of this inability to load that module. I don't know why pershoot doesn't make it part of the kernel, maybe he doesn't have a PC in the house
Sure, the whole typing thingie in linux/android looks easy if that is what you do 24/7. But for less accustomed with that, all this is likely a turn-off.
Click to expand...
Click to collapse
GScript lite can automate the "whole typing thingie" - just put the insmod command there.
The nice thing about it being a module for the functions you rarely use is, for the 99.999% of the time that you don't need the functionality, it's not taking up memory since its not loaded.
I was just shutting down to get some zzzzs but I fired my PC back up to have a go at this. I worked through part of it - did get the remount working and was able to copy things to the directory and then remount ro. It didn't work yet but I was tired and I may have made a typo. I REALLY appreciate the detailed explanation and examples. This is a page I will refer back to over and over until it becomes second nature. Thanks. Questions:
1. I follow how you arrived at the location (although I don't have a kernel zip file) - is "placeholder" a standard or was that just experience and intuition that informed you?
2. The whole section about un-tarring lib-2632.39_gb.tar.gz - Linux is not my primary language so how did you know that it would un-tar to the proper kernel module directory? Did I miss something?
3. I have to go back and retrace my steps but I tried using both cifs manager and mount manager and they both fail claiming "there is no such device" I tried the manual steps for loading insmod and the cifs.ko as the example described and I get "failed (Exec format error)
Please dispense more wisdom as needed.
enigma0456 said:
Questions:
1. I follow how you arrived at the location (although I don't have a kernel zip file) - is "placeholder" a standard or was that just experience and intuition that informed you?
Click to expand...
Click to collapse
Experience and intuition.
The `placeholder' file is not a standard. On Linux, kernel modules are placed in /lib/modules/KERNEL-VERSION/, and the standard utility (or, program) which we use to load modules, modprobe, looks there for kernel modules. In fact, it's normally unnecessary to manually load modules like we have done. Usually on Linux, because of the standardized module locations, the appropriate modules are automatically loaded when needed.
Things are irritatingly (and unnecessarily) different on Android. There is no modprobe supplied with the system and the busybox modprobe still attempts to use the /lib/modules/... path as on Linux. Which is why you have to resort to insmod and the long-winded path to the kernel module.
I am new to Android myself, and the steps I outlined above are what I used to determine where things should go on the gTablet.
2. The whole section about un-tarring lib-2632.39_gb.tar.gz - Linux is not my primary language so how did you know that it would un-tar to the proper kernel module directory? Did I miss something?
Click to expand...
Click to collapse
You didn't notice the 'cd /system' command before the tar command extracting the kernel modules.
You move to the directory where things should be placed before untar'ing; and when you untar, tar will re-create the directory structure you see in the tar file in the directory you're currently in. Some versions of tar have a `-C' flag which you can use to change the current directory; sort-of like the 'Extract to directory' option you have in GUIs. If you had one of those tar commands you'd do this:
Code:
# /system/xbin/tar -C /system -xzvf /mnt/sdcard/kernel/lib-2632.39_gb.tar.gz
instead of this:
Code:
# cd /system
# /system/xbin/tar -xzvf /mnt/sdcard/kernel/lib-2632.39_gb.tar.gz
3. I have to go back and retrace my steps but I tried using both cifs manager and mount manager and they both fail claiming "there is no such device" I tried the manual steps for loading insmod and the cifs.ko as the example described and I get "failed (Exec format error)
Please dispense more wisdom as needed.
Click to expand...
Click to collapse
The error messages are helpful clues.
The "Exec format error" probably means that you've downloaded the wrong version of the kernel and/or modules. Pershoot supplies 4 versions: for Froyo-ROMs, for Gingerbread-ROMs, for tablets with the new Bootloader and Froyo-ROMs, and tablets with the new Bootloader and Gingerbread-ROMs. Use the correct version for your hardware and ROM.
The "no such device" error message is also a clue. The output of 'cat /proc/filesystems', above, after the cifs module was loaded has a line like:
Code:
nodev cifs
which means that the cifs filesystem is not associated with an actual device file. The "no such device" means that you're (or the program you use is) incorrectly supplying a /dev/... parameter to the mount command, or have screwed up or incorrect options somewhere.
Here's how I mounted a Win 7 share on the gTablet just now. In a Terminal Emulator window:
Code:
$ su
# insmod /system/lib/modules/2.6.32.39-cyanogenmod/kernel/fs/cifs/cifs.ko
# mkdir /mnt/cifs
# mount -t cifs //SERVER-IP-ADDRESS/SHARE-NAME /mnt/cifs -o domain=DOMAIN,username=USERNAME,password=PASSWORD
This method is slightly insecure, though. It's better to create a file with
Code:
domain=DOMAIN
username=USERNAME
password=PASSWORD
and then pass the `credentials=filename' option instead of the `domain=...' above:
Code:
mount -t cifs //SERVER-IP-ADDRESS/SHARE-NAME /mnt/cifs -o credentials=/SOME/PATH/cifs-cred.txt
I know typing all this is a chore, but my goal is to help you troubleshoot things on your own in the future. Linux, and by extension, Android, is good in this regard. It's transparent and very inspectable--if something goes wrong, you can look around, and usually fix things up.
Cheers!
OK - well I tried the manual insmod as in your example and I get the "failed (Exec format error) so I'm going to assume that I still have the wrong module. I'm trying to avoid getting into the changing my kernel project right now so I'll go back and check again on Pershoots page to try and find the version of the kernel that is currently running in my g-tab and the appropriate library that goes with it. The problem must lie there. I was sure I had the right library to go with my 2.6.32.36-cynaogenmod [email protected] #1 but then again, the labeling on his site doesn't reflect a name like that. The best I can find is boot-cm_2632.36_gb-xtra-vfp_fp-032711.zip and the associated lib-2632.36_gb.tar.gz (kernel modules). Is this really the kernel in my g-pad? Don't know how to tell but sems to be the only gingerbread one with that numbering series.
If you use some kernel version X.Y.Z, you have to use the modules that were compiled with that kernel. It's not just the version numbers that have to match--the compilation options might matter too.
I.e., Make sure, you are running the kernel first, then install the modules. Just pick the latest GB (you mentioned you were running VEGAn-gingerbread) kernel from pershoot's page.
1. Download this kernel zip file: boot-cm_2632.39_gb-oc-uv-xtra-vfp_fp-043011.zip
2. Download the associated kernel module file: lib-2632.39_gb.tar.gz
3. Boot into ClockworkMod recovery to install the kernel. At the main menu, choose, "install zip from sdcard". Then select, "choose zip from sdcard", navigate to where you put the kernel zip file, then choose the zip file and apply it.
4. Reboot back into the normal system.
5. Now, follow the steps outlined above to untar the modules in /system. Do *not* use `chmod -R 644' to change permissions recursively. This command *removes* the execute permission from directories which *must* be present. The module tar file should, generally, have the correct permissions already.
6. Try the manual method first: insmod /SOME/PATH/cifs.ko must work, then try the mount command.
7. Unmount using `umount /MOUNT/POINT'.
You can troubleshoot the CIFS manager later.
Coda
This investigation lead me to the kernel naming investigation and the discovery that the module library must be compiled with the kernel that you are using. Obvious now but ... Anyway, in the process of learning about kernels I stumbled upon cyanogenmod so I loaded that onto my tab. I liked the way it works so I took another run at the cifs - and it did not work. I went back and followed these steps and made sure that I found the lib module that matched the kernel that came with my release of cyanogen. I extracted cifs.ko and copied it to the /system/lib/modules directory (I had to make the modules directory) and then I used cifsmanager to try and mount the share and it worked. Next I deleted the modules directory with the module in it and tried to mount the share and it failed. I put it all back and it worked again. So - the instructions preceding this post are sound and, if followed carefully, will work. The key seems to be making sure the lib module is the one that goes with your kernel. Thanks again to all those that contributed to my education!
swan song
enigma0456 said:
I went back and followed these steps and made sure that I found the lib module that matched the kernel that came with my release of cyanogen...
The key seems to be making sure the lib module is the one that goes with your kernel.
Click to expand...
Click to collapse
That may only have worked because CyanogenMod uses pershoot's kernel as its default kernel. Had it used Clemsyn's kernel instead, you may very well have ended up back at square one.
The golden rule is: Get the kernel and the kernel modules from the same guy, because he can (and probably does) build both at the same time. And because of this you can be sure that:
a) The modules were compiled with the correct kernel sources, header files and configuration options.
b) The same compiler was used to compile both the kernel and the modules.
c) The same compiler flags, like optimizations, were used for the compilations. In rare cases, I've seen mismatches here causing problems.
In most cases however, esp. on an architecture like the x86 which is very forgiving, slightly mismatched kernels and modules won't cause problems, but, this is not the sort of thing you should be futzing around with--unless you're a wizard.
I have 4 different versions of GCC (2 each for x86 and x86-64--stable and latest), the Intel C compiler v11, and 3 different compilers for the ARM (Android NDK, the prebuilt one from the Aboriginal Linux project and the latest GCC cross-compiled for the ARM). I use different version for different things and stick to each consistently.
OK, so kernels and modules have to be compiled together, but, what about userspace? Do normal programs have to be recompiled if you change the kernel?
No, not (generally) required. The Linux kernel developers have gone to great lengths to make sure that the kernel interface to userspace stay the same--in fact, it would only be a mild exaggeration to say that the kernel guys would rather give away their first-borns than break the userspace API.
This is the reason why you can run Clemsyn kernels on TnT-Lite, or pershoot kernels on VEGAn-Gingerbread, or whatever other combo you prefer.
Hi folks (this should be in the development forums, but I can't post there yet...)
I booted my Sony Tablet S into recovery mode, then managed to get the SD Card to mount. (Select option 2 and it will mount it up for you ). Using "adb pull" to retrieve /proc/mounts I get the following gem:
Code:
rootfs / rootfs rw 0 0
tmpfs /dev tmpfs rw,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
/dev/block/mmcblk0p4 /cache ext4 rw,nosuid,nodev,relatime,barrier=1,data=ordered 0 0
/dev/block/mmcblk1p1 /sdcard vfat rw,nodev,noatime,nodiratime,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,comp_uni,avoid_dlink,errors=remount-ro 0 0
From what I can see, this means if we can convince the system to run executables placed on the SD Card - we should be able to run a suid binary - and attain root (then be able to mount /system rw and add a su binary)
Does that help anyone?
bcooksley said:
Hi folks (this should be in the development forums, but I can't post there yet...)
I booted my Sony Tablet S into recovery mode, then managed to get the SD Card to mount. (Select option 2 and it will mount it up for you ). Using "adb pull" to retrieve /proc/mounts I get the following gem:
Code:
rootfs / rootfs rw 0 0
tmpfs /dev tmpfs rw,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
/dev/block/mmcblk0p4 /cache ext4 rw,nosuid,nodev,relatime,barrier=1,data=ordered 0 0
/dev/block/mmcblk1p1 /sdcard vfat rw,nodev,noatime,nodiratime,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,comp_uni,avoid_dlink,errors=remount-ro 0 0
From what I can see, this means if we can convince the system to run executables placed on the SD Card - we should be able to run a suid binary - and attain root (then be able to mount /system rw and add a su binary)
Does that help anyone?
Click to expand...
Click to collapse
Thank you. I hope it helps to mount sd for app2sd, psxperia, direct media playing soon
Sent from my R800i
How does the system decide if a program can run as root? The location it runs from?
Is there a cron function in the tablets, or ability to add something to the init.d steps?
An application which is both setuid and owned by root (known as setsuid) can be executed by any user and is granted root privileges immediately. That is how "su" (and other similar apps) work.
Unfortunately, i've discovered that the file system arguments it supplies are hardcoded - so whilst it can detect that a SD card is formatted with ext4 - the mount fails as ext4 doesn't support the FAT specific arguments.
So while we will be able to use this to get executables on the system - we can't get setsuid executables on the system, limiting us to executables being run as the "shell" user.
Yes. Ill help. I sent you a pm.
Ok, so whilst the SD Card method has unfortunately not panned out - I have found something potentially interesting none the less.
This lies in the update system used by Sony. I have determined that the updates appear to be encrypted using a Triple-DES key, which is embedded in, or retrieved by /system/lib/libautomagic_library.so.
This file has traces of apparently being written by HTC (the strings HTC_RIL, CDMA and PHONE all appear in it). It also has a reference to the location /data/data/com.sony.automagic.client.app/file/ (which doesn't exist on my device)
This library is used by the updater application itself - through a Java framework "automagic_downloader". Unfortunately, due to the use of the compiled C code for decryption and update verification (which includes SHA1/MD5 sum checks, likely against the previously downloaded info.xml, which it also handles) it is not possible to tell if the decrypted file is the one placed in /cache however.
The key "ro.sony.build.incremental" written in /system/build.prop is the version number used by Sony to determine if the system needs updating or not, as far as I can tell (with the C library being used, it is difficult to tell)
I have also noted, that when in recovery mode, the following two statements are present in /default.props
ro.build.description=nbx03_033-user 3.2.1 THMASU0035 0035.002 test-keys
ro.build.fingerprint=Sony/nbx03_002/nbx03:3.2.1/THMASU0035/0035.002:user/test-keys
I am not sure at this point if this just means that different keys will be used - or if the keys referenced are the ones available publicly in Android's repositories.
Please note that the above, whilst interesting, does not provide a direct path to rooting the device at this time. Note also that I was not able to complete the paths that the updater application takes codewise, so some of the code I examined may not be used - and thus the above may not apply.
However, if correct this may allow for the OTA images to be decrypted at some point, if someone can decompile those libraries (or otherwise extract the keys using a hex editor).
bcooksley said:
Ok, so whilst the SD Card method has unfortunately not panned out - I have found something potentially interesting none the less.
This lies in the update system used by Sony. I have determined that the updates appear to be encrypted using a Triple-DES key, which is embedded in, or retrieved by /system/lib/libautomagic_library.so.
This file has traces of apparently being written by HTC (the strings HTC_RIL, CDMA and PHONE all appear in it). It also has a reference to the location /data/data/com.sony.automagic.client.app/file/ (which doesn't exist on my device)
This library is used by the updater application itself - through a Java framework "automagic_downloader". Unfortunately, due to the use of the compiled C code for decryption and update verification (which includes SHA1/MD5 sum checks, likely against the previously downloaded info.xml, which it also handles) it is not possible to tell if the decrypted file is the one placed in /cache however.
The key "ro.sony.build.incremental" written in /system/build.prop is the version number used by Sony to determine if the system needs updating or not, as far as I can tell (with the C library being used, it is difficult to tell)
I have also noted, that when in recovery mode, the following two statements are present in /default.props
ro.build.description=nbx03_033-user 3.2.1 THMASU0035 0035.002 test-keys
ro.build.fingerprint=Sony/nbx03_002/nbx03:3.2.1/THMASU0035/0035.002:user/test-keys
I am not sure at this point if this just means that different keys will be used - or if the keys referenced are the ones available publicly in Android's repositories.
Please note that the above, whilst interesting, does not provide a direct path to rooting the device at this time. Note also that I was not able to complete the paths that the updater application takes codewise, so some of the code I examined may not be used - and thus the above may not apply.
However, if correct this may allow for the OTA images to be decrypted at some point, if someone can decompile those libraries (or otherwise extract the keys using a hex editor).
Click to expand...
Click to collapse
Thanks, and please evryone lets keep trying until someone figures this out. Any effort is progress iMO
Hi there, first time I write here and I probably have a lot to learn
However, a few days ago I accidently dropped by Galaxu SIII from my balcony. As a result both the screen and the touch is broken, the rest seems to work. So, of course I can connect the phone to my computer and gain access to those folders that are always monuted. However I wan't to get access to all files, like I did on the phone after I rooted it. It looks like USB debugging is off even though I was sure it was on, ADB refuses to see the phone anyway. I have tried many ideas, including remote connection to the phone, but all soloutions require to either enable USB debugging or open an app and that is exactly what I cannot do! So what can I do besides getting a new screen, which I don't want since I've already brought a new phone. Mostly I want to save my contacts and I cannot to that with Samsung KIES since I have CM11 on the phone. I really can't find any solution and I really hope somebody out there can help me!
//Oscar
SuperLarre said:
Hi there, first time I write here and I probably have a lot to learn
However, a few days ago I accidently dropped by Galaxu SIII from my balcony. As a result both the screen and the touch is broken, the rest seems to work. So, of course I can connect the phone to my computer and gain access to those folders that are always monuted. However I wan't to get access to all files, like I did on the phone after I rooted it. It looks like USB debugging is off even though I was sure it was on, ADB refuses to see the phone anyway. I have tried many ideas, including remote connection to the phone, but all soloutions require to either enable USB debugging or open an app and that is exactly what I cannot do! So what can I do besides getting a new screen, which I don't want since I've already brought a new phone. Mostly I want to save my contacts and I cannot to that with Samsung KIES since I have CM11 on the phone. I really can't find any solution and I really hope somebody out there can help me!
//Oscar
Click to expand...
Click to collapse
I suppose your files are not on the SD-Card? If they are just remove the card, but I'm pretty sure you wouldn't ask this question if it was that easy!!
broonage said:
I suppose your files are not on the SD-Card? If they are just remove the card, but I'm pretty sure you wouldn't ask this question if it was that easy!!
Click to expand...
Click to collapse
You're right, it isn't that easy!
SuperLarre said:
You're right, it isn't that easy!
Click to expand...
Click to collapse
You could try nandroid backup from recovery, maybe using an otg for watching what your're doing on a separate screen.
When all data is nandroided, you can try going trough the backup (the data section specially).
If the backup has several parts (ie, a b c d… ) you can "merge" them into a single file that could be opened with 7zip or winrar. Just open a DOS command prompt and:
type data.ext4.tar.a data.ext4.tar.b >> data.ext4.tar
Thats the example for 2 parts a and b.Then, after unpacking the tar, you could look into the data to get stuff. For example…
Sms & mms:
data/data/com.android.providers.telephony/databases
Contacts:
data/data/com.android.providers.contacts/databases
And a lot of other stuff. Note that you need something to read-edit ".db" files, like an sqlite editor.
Alternatively, if you're using a similar phone, with same manufacturer, a close android version (for example not gb 2.3 vs kk 4.4, but yes jb 4.1 vs jb 4.3), etc, then you could copy such addresses and paste them inside your new phone (crossing fingers and any other crossable bodypart) and you might get all that stuff back.
Good luck.
Put a blank SD (formatted as FAT32 or exFat) on the phone. It must be sized as the phone's internal memory size (16 or 32GB)
Set the phone in download mode. Flash Phil'z recovery with Odin.
Start the phone in recovery mode. Connect usb to computer and after 10-15 seconds ADB will be enabled.
/data is mounted by default (internal SD is stored inside /data).
Now mount the external SD:
enter adb shell and put:
Code:
mount /dev/block/mmcblk1p1 /external_sd
If any error appear, stop.
If nothing appeared, check that it was sucessfully mounted. Ensure that mmcblk0p12 and mmcblk1p1 are mounted as this!
Code:
mount
rootfs on / type rootfs (rw)
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)
/dev/block/mmcblk0p8 on /cache type ext4 (rw,nodev,noatime,nodiratime,barrier=1,data=ordered)
/dev/block/mmcblk0p12 on /data type ext4 (rw,nodev,noatime,nodiratime,barrier=1,data=ordered)
/dev/block/mmcblk1p1 on /external_sd type exfat (rw,relatime,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=utf8,namecase=0,errors=remount-ro)
Now copy all the internal storage to the external SD:
Code:
mkdir /external_sd/intData; cd /data; tar cf - * | ( cd /external_sd/intData; tar xf -)
Take a breath and come 15 minutes later to see if it finished. It may take more if the device was nearly full.
After it comes back to shell (you see the # symbol again) it means it's over.
Now let's flush the filesystems and unmount the partitions :
Code:
cd /; sync; umount /external_sd; umount /data
Remove the battery and the sd card.
Put the SD on your computer...done!
- The internal SD is stored on /data/media.
- The app data is on /data/data.
- The apps are on /data/app
- Your contacts are stored on /data/data/databases/com.android.providers.contacts/contacts2.db.
Putting that DB file on the same place of other Android phone and rebooting after will restore your contacts. Or you can convert them to VCF:
http://askubuntu.com/questions/445997/how-to-convert-androids-contacts2-db-to-vcf
Good luck!
dabyd64 said:
Put a blank SD (formatted as FAT32 or exFat) on the phone. It must be sized as the phone's internal memory size (16 or 32GB)
Set the phone in download mode. Flash Phil'z recovery with Odin.
Start the phone in recovery mode. Connect usb to computer and after 10-15 seconds ADB will be enabled.
/data is mounted by default (internal SD is stored inside /data).
Now mount the external SD:
enter adb shell and put:
Code:
mount /dev/block/mmcblk1p1 /external_sd
If any error appear, stop.
If nothing appeared, check that it was sucessfully mounted. Ensure that mmcblk0p12 and mmcblk1p1 are mounted as this!
Code:
mount
rootfs on / type rootfs (rw)
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)
/dev/block/mmcblk0p8 on /cache type ext4 (rw,nodev,noatime,nodiratime,barrier=1,data=ordered)
/dev/block/mmcblk0p12 on /data type ext4 (rw,nodev,noatime,nodiratime,barrier=1,data=ordered)
/dev/block/mmcblk1p1 on /external_sd type exfat (rw,relatime,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=utf8,namecase=0,errors=remount-ro)
Now copy all the internal storage to the external SD:
Code:
mkdir /external_sd/intData; cd /data; tar cf - * | ( cd /external_sd/intData; tar xf -)
Take a breath and come 15 minutes later to see if it finished. It may take more if the device was nearly full.
After it comes back to shell (you see the # symbol again) it means it's over.
Now let's flush the filesystems and unmount the partitions :
Code:
cd /; sync; umount /external_sd; umount /data
Remove the battery and the sd card.
Put the SD on your computer...done!
- The internal SD is stored on /data/media.
- The app data is on /data/data.
- The apps are on /data/app
- Your contacts are stored on /data/data/databases/com.android.providers.contacts/contacts2.db.
Putting that DB file on the same place of other Android phone and rebooting after will restore your contacts. Or you can convert them to VCF:
http://askubuntu.com/questions/445997/how-to-convert-androids-contacts2-db-to-vcf
Good luck!
Click to expand...
Click to collapse
Amazing answer, however during the first steps, could he be blocked? Due to not seeing the screen? Maybe I'm over complicating things.
Using a usb key for a live USB of remix os in the same time as a data external drive isn't possible actually due to windows not being able to see further than one partition on the stick (ok, except if we use remix os partition as the data one ... without accidentally messing it up, but looks like it has an automatic size and the place it uses limit us).
I remember I had a similar problem with one of my first Linux live too. Not sure how I dealt with it but I were able to end having both after some search and understanding : liveOS partition, and a data partition visible on Windows (no problem like this with a Linux).
I'll try to reproduce with a linux if I have the time but here is what I'm looking for :
Ooops, since I can't post links nor upload images, I put the image link as my twitter in my profile
So, won't the data partition be ok to use on windows if like on 2nd example, the live os isn't installed in the same place as in the 1rst one ? I already tried to prepare 2 partitions before using the installation tool and choose the one destined for remixOS (and only visible) to install on it but the tool always end wiping ALL the key, and then partitioning appears to be the same.
Can pass through this problem be done by the tool ? (being able to install NEXT to a data partition to keep it visible by windows, or hide remixOS ones)
I ideally need this key for both usages, and if it's possible I think I'm not alone.
Does this can be added ?
@Esdeve
The reason you don't see the partitions in Windows is because they are in EXT4 filesystem, but I guess u know that already .
There are few software solutions for mounting these, but it will only mount the whole Remix system partiton, not the "partition inside the partition".
So basically it'll mount the partition with data.img (remix data partition), inird, ramdisk.... But not the data.img itself.
I don't think it's possible too easily and quickly make this automatic. Even on Linux u'd have to set up data.img to be automatically mounted when pendrive is detected.
Using the official .iso to USB installer won't allow you do what you need, but you can boot Linux on ur PC and with gParted extend/shrink existing USB partitions and maybe make a new one for other purposes.
Sent from mobile
Yup. Know that. I think you didn't understood what I'm looking to do ... but I may express poorly in english when speaking about computing subjects. Or I may not understand myself what you are answering too ^^'
Here we re-go : I'm looking to have both a data partition and the two partitions of RemixOS which are a Fat32 and an Ext one. I don't need having an access to the Ext, and I don't want to use the Fat32 one as a data partition because it's the OS partition, it's unsafe to use it for this, I may mess with it accidentally.
I don't need to modify the sizes of any partitions (from a Linux or not) since installation leaves room to be used. But since the fat32 already exists, I basically can't create/keep a 2nd fat/fat32/NTFS one next to it, this is no use, windows won't see it, the fat32 from remixOS is first, so Windows only sees this one and not my own, and I can't change that with the way the installation is made. Moving the two RemixOS partitions is of course totally excluded and will render the os unable to boot so I won't try it except maybe if able to do #3.
Solutions ?
1 - Being able to do what I just proposed in 1rst post : have the devs make the installer able to install in place of a designated partition (and not on all the key), in the right part of what is displayed in he graphic from my partition software, leaving the possibility to create afterward a fat/fat32/ntfs partition to the left, and seen by windows instead of the remixOS's fat32 without destroying the boot ... Uh, if that does the trick, I didn't experiment this sort of things a lot but I'm sure I succeeded with a live persistent linux once.
2 - RemixOS installer may only use EXT partitions and no fat32 ? Can't it ? Leaving windows readable formats free to use for something else.
3 - I'm planing to move the partitions like needed (there I know I'll be able to access my personal data partition I created), and then try some Grub thing on my key to keep the live system bootable, but I'm not sure to remember how to, nor if this will work, nor even if grub can launch RemixOS.
Well. I'd add to all this that I'm not specially searching for help, I know actually except for the complex solution #3, that it's impossible to manage what I need. It's more like an asking/proposing of feature/possibility. And I'm pretty sure I won't be the only one to think it's waste to use my 3.0 stick rendering it unable to serve in the same time for portable data storage when it always have loooots of place.
I read in the ask/propose feature part of the devs site to come post her ... So I did. But there is no "evolution" section and only a device classifying here. So here I wrote. Sorry if misunderstood.
The problem with what you wrote is that you overcomplicate it. Keep it simple and short - that's best.
Did understood correctly that you want to use the USB as Remix Live Stick and as a typical storage device?
Did you read my whole post?
Remix when installed on USB should use all it's space - makes 3 partitions:
1. Boot
2. System
3. Data for external storage purposes.
The 3rd is what you see in Windows.
All you need to do now is just to adjust sizes of other partitions (it's possible without corrupting existing files), but hard to do under Windows. Then u need to expand this 3rd partition.
Sent from mobile
Sorry ^^' I know I use too much words, but it appears I can't make simple when speaking about technical matters, and in a language I'm not used to resume tech things.
Of course, I read your posts. I"m on a 32gb stick. I can see 3 partitions :
1 : REMIX_OS (apparently data, since it's the only one I can access from windows). Fat32. 7.64Gb sized.
2 : REMIXOSSYS. Fat32 too. But not accessible from windows (I understand this like it's because it's 2nd principal partition, so windumbOS doesn't see it). 5Gb sized. Part of the system. including the boot isn't it ?
3 : Third partition. System. Format unknown from Windows or either with Linux (using gParted). Named "unknown". And takes full remnants of the stick capacity (16Gb). Does it needs theses 16Gb from the start ? Apparently not obligatory since looking at the space used from the live OS, seems doesn't uses it a lot compared to the available place.
This last one is the main problem for me. I don't see how to treat this "other" partition, and at start, then reading your 1/2/3 list, I believed that was this one used as "data". I understand well there are ext partitions within since the os is an unix, but I don't see the whole as an EXT partition, whenever I'm on Windows or Linux, so with my knowledge and capacities, I can't access nor reduce it.
Will try command line or to find a similar problem with solution, but I think this won't change lot here. About the two Fat32, I'm not really confident about what you said and the possibility of moving the whole, and especially theses two. Systems and boots don't like this, they don't find each others well afterward ^^ don't they ? Resizing the two first without moving ? Ok. But that will just make me room for two new small useless partitions between the three others, and I strongly believe windows won't see em but only the "REMIX_OS" one.
If possible, I'm going to try another way to obtain live remixOS usb too. Can't unetbootin or such do the job ?
If the choice of having data at the beginning isn't technical, can't the devs make the installation create the data partition at the end instead, plus add an option advising a minimal space for the "unknown" partition and letting users chose what size it will be ?
Esdeve said:
Sorry ^^' I know I use too much words, but it appears I can't make simple when speaking about technical matters, and in a language I'm not used to resume tech things.
Of course, I read your posts. I"m on a 32gb stick. I can see 3 partitions :
1 : REMIX_OS (apparently data, since it's the only one I can access from windows). Fat32. 7.64Gb sized.
2 : REMIXOSSYS. Fat32 too. But not accessible from windows (I understand this like it's because it's 2nd principal partition, so windumbOS doesn't see it). 5Gb sized. Part of the system. including the boot isn't it ?
3 : Third partition. System. Format unknown from Windows or either with Linux (using gParted). Named "unknown". And takes full remnants of the stick capacity (16Gb). Does it needs theses 16Gb from the start ? Apparently not obligatory since looking at the space used from the live OS, seems doesn't uses it a lot compared to the available place.
This last one is the main problem for me. I don't see how to treat this "other" partition, and at start, then reading your 1/2/3 list, I believed that was this one used as "data". I understand well there are ext partitions within since the os is an unix, but I don't see the whole as an EXT partition, whenever I'm on Windows or Linux, so with my knowledge and capacities, I can't access nor reduce it.
Will try command line or to find a similar problem with solution, but I think this won't change lot here. About the two Fat32, I'm not really confident about what you said and the possibility of moving the whole, and especially theses two. Systems and boots don't like this, they don't find each others well afterward ^^ don't they ? Resizing the two first without moving ? Ok. But that will just make me room for two new small useless partitions between the three others, and I strongly believe windows won't see em but only the "REMIX_OS" one.
If possible, I'm going to try another way to obtain live remixOS usb too. Can't unetbootin or such do the job ?
If the choice isn't technical, can't the devs make the installation create the data partition at the end instead of the beginning, plus add an option advising a minimal space for the "unknown" partition and letting users chose what size it will be ?
Click to expand...
Click to collapse
The unknown should be ext4 userdata mounted as /data and RemixOSSys should only contain system
Can you post a screenshot of the contents of Remix_OS and within RemixOS check mount and df to check what's mounted where.
About the two command lines from within remixOS. I don't know how to copy it or save it to a file. Looks like shortcuts/commands I'm used to aren't suited here (tried to use "script" and "-l > /path/to/file.txt". Either end up with a file protected in writing, or path not existing, maybe even command not existing answers). So how do I do that ? Or maybe where will I be enabled to create a .txt from the terminal ?
Esdeve said:
About the two command lines from within remixOS. I don't know how to copy it or save it to a file. Looks like shortcuts/commands I'm used to aren't suited here (tried to use "script" and "-l > /path/to/file.txt". Either end up with a file protected in writing, or path not existing, maybe even command not existing answers). So how do I do that ? Or maybe where will I be enabled to create a .txt from the terminal ?
Click to expand...
Click to collapse
You should be able to redirect to sdcard:
mount > /sdcard/mount.txt
df >> /sdcard/mount.txt
Hmm..
If you don't wish Windows to have access to your usb stick...
Use "diskmanager" and remove the drive letter
Cheers
@mitchell4you : That's not what I propose.
@HypoTurtle, and to recapitulate for anyone about screenshots :
Since I can't post links for the moment, I put the screens links in my profile in place of contact infos. I'll modify my posts later when I'll own the rights.
Twitter is for the first post of the thread.
G+ is the Remix_OS partition screen you asked for.
Say if other partition screenshot is needed.
Next are the command lines ...
Mount :
tmpfs on / type tmpfs (ro,relatime)
/dev/loop1 on /system type ext4 (ro,relatime,data=ordered)
/dev/block/sdb3 on /data type ext4 (rw,noatime,nodiratime,data=ordered)
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)
/sys/kernel/debug on /sys/kernel/debug type debugfs (rw,relatime,mode=755)
none on /acct type cgroup (rw,relatime,cpuacct)
none on /sys/fs/cgroup type tmpfs (rw,relatime,mode=750,gid=1000)
tmpfs on /mnt type tmpfs (rw,relatime,mode=755,gid=1000)
none on /dev/cpuctl type cgroup (rw,relatime,cpu)
pstore on /sys/fs/pstore type pstore (rw,relatime)
none on /cache type tmpfs (rw,nosuid,nodev,noatime)
tmpfs on /storage type tmpfs (rw,relatime,mode=755,gid=1000)
tracefs on /sys/kernel/debug/tracing type tracefs (rw,relatime)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
/dev/fuse on /mnt/runtime/default/emulated type fuse (rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other)
/dev/fuse on /storage/emulated type fuse (rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other)
/dev/fuse on /mnt/runtime/read/emulated type fuse (rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other)
/dev/fuse on /mnt/runtime/write/emulated type fuse (rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other)
/dev/block/vold/public:8_1 on /mnt/media_rw/E45C9A015C99CF24 type fuseblk (rw,dirsync,nosuid,nodev,noexec,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)
/dev/fuse on /mnt/runtime/default/E45C9A015C99CF24 type fuse (rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other)
/dev/fuse on /storage/E45C9A015C99CF24 type fuse (rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other)
/dev/fuse on /mnt/runtime/read/E45C9A015C99CF24 type fuse (rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other)
/dev/fuse on /mnt/runtime/write/E45C9A015C99CF24 type fuse (rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other)
/dev/block/vold/public:8_2 on /mnt/media_rw/01D0A77D0C4455E0 type fuseblk (rw,dirsync,nosuid,nodev,noexec,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)
/dev/fuse on /mnt/runtime/default/01D0A77D0C4455E0 type fuse (rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other)
/dev/fuse on /storage/01D0A77D0C4455E0 type fuse (rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other)
/dev/fuse on /mnt/runtime/read/01D0A77D0C4455E0 type fuse (rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other)
/dev/fuse on /mnt/runtime/write/01D0A77D0C4455E0 type fuse (rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other)
/dev/block/vold/public:8_3 on /mnt/media_rw/720ddd36-a9a5-4e8d-a80f-bf25799d1fc7 type ext4 (rw,dirsync,nosuid,nodev,noatime,data=ordered)
/dev/fuse on /mnt/runtime/default/720ddd36-a9a5-4e8d-a80f-bf25799d1fc7 type fuse (rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other)
/dev/fuse on /storage/720ddd36-a9a5-4e8d-a80f-bf25799d1fc7 type fuse (rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other)
/dev/fuse on /mnt/runtime/read/720ddd36-a9a5-4e8d-a80f-bf25799d1fc7 type fuse (rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other)
/dev/fuse on /mnt/runtime/write/720ddd36-a9a5-4e8d-a80f-bf25799d1fc7 type fuse (rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other)
/dev/block/vold/public:8_5 on /mnt/media_rw/7326C07B75B67850 type fuseblk (rw,dirsync,nosuid,nodev,noexec,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)
/dev/fuse on /mnt/runtime/default/7326C07B75B67850 type fuse (rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other)
/dev/fuse on /storage/7326C07B75B67850 type fuse (rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other)
/dev/fuse on /mnt/runtime/read/7326C07B75B67850 type fuse (rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other)
/dev/fuse on /mnt/runtime/write/7326C07B75B67850 type fuse (rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other)
/dev/block/vold/public:8_7 on /mnt/media_rw/288A9EF38A9EBCAE type fuseblk (rw,dirsync,nosuid,nodev,noexec,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)
/dev/fuse on /mnt/runtime/default/288A9EF38A9EBCAE type fuse (rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other)
/dev/fuse on /storage/288A9EF38A9EBCAE type fuse (rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other)
/dev/fuse on /mnt/runtime/read/288A9EF38A9EBCAE type fuse (rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other)
/dev/fuse on /mnt/runtime/write/288A9EF38A9EBCAE type fuse (rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other)
/dev/block/vold/public:8_8 on /mnt/media_rw/01D0A77D072BDC90 type fuseblk (rw,dirsync,nosuid,nodev,noexec,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)
/dev/fuse on /mnt/runtime/default/01D0A77D072BDC90 type fuse (rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other)
/dev/fuse on /storage/01D0A77D072BDC90 type fuse (rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other)
/dev/fuse on /mnt/runtime/read/01D0A77D072BDC90 type fuse (rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other)
/dev/fuse on /mnt/runtime/write/01D0A77D072BDC90 type fuse (rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other)
/dev/block/vold/public:8_17 on /mnt/media_rw/3834-74A4 type vfat (rw,dirsync,nosuid,nodev,noexec,relatime,uid=1023,gid=1023,fmask=0007,dmask=0007,allow_utime=0020,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro)
/dev/fuse on /mnt/runtime/default/3834-74A4 type fuse (rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other)
/dev/fuse on /storage/3834-74A4 type fuse (rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other)
/dev/fuse on /mnt/runtime/read/3834-74A4 type fuse (rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other)
/dev/fuse on /mnt/runtime/write/3834-74A4 type fuse (rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other)
/dev/block/vold/public:8_18 on /mnt/media_rw/C004-4EFA type vfat (rw,nosuid,nodev,noexec,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
/dev/fuse on /mnt/runtime/default/C004-4EFA type fuse (rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other)
/dev/fuse on /storage/C004-4EFA type fuse (rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other)
/dev/fuse on /mnt/runtime/read/C004-4EFA type fuse (rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other)
/dev/fuse on /mnt/runtime/write/C004-4EFA type fuse (rw,nosuid,nodev,noexec,noatime,user_id=1023,group_id=1023,default_permissions,allow_other)
And df :
Filesystem-----------------------------1K-blocks-----Used-------Available-----Use%----Mounted on
tmpfs--------------------------------4012216--------3304-------4008912-------1%--------/
/dev/loop1--------------------------2539312-------1962424----576888-------78%------/system
/dev/block/sdb3------------------16382888-----1212340-----15170548------8%-------/data
tmpfs--------------------------------4012216--------76-----------4012140-------1%--------/dev
none---------------------------------4012216--------12------------4012204------1%--------/sys/fs/cgroup
tmpfs--------------------------------4012216--------0-------------4012216------0%-------/mnt
none---------------------------------4012216--------0-------------4012216------0%-------/cache
/dev/fuse---------------------------16382888------1212340-----15170548----8%-------/mnt/runtime/default/emulated
/dev/fuse---------------------------16382888------1212340-----15170548----8%-------/mnt/runtime/read/emulated
/dev/fuse---------------------------16382888------1212340-----15170548----8%-------/mnt/runtime/write/emulated
/dev/block/vold/public:8_1----102396---------28804-------73592--------29%-----/mnt/media_rw/E45C9A015C99CF24
/dev/fuse---------------------------102396---------28804-------73592--------29%-----/mnt/runtime/default/E45C9A015C99CF24
/dev/fuse---------------------------102396---------28804-------73592--------29%-----/mnt/runtime/read/E45C9A015C99CF24
/dev/fuse---------------------------102396---------28804-------73592--------29%-----/mnt/runtime/write/E45C9A015C99CF24
/dev/block/vold/public:8_2----297780836----115267204--182513632---39%----/mnt/media_rw/01D0A77D0C4455E0
/dev/fuse----------------------------297780836---115267204---182513632---39%---/mnt/runtime/default/01D0A77D0C4455E0
/dev/fuse----------------------------297780836---115267204---182513632---39%---/mnt/runtime/read/01D0A77D0C4455E0
/dev/fuse----------------------------297780836---115267204---182513632---39%---/mnt/runtime/write/01D0A77D0C4455E0
/dev/block/vold/public:8_3-----92798268----4900736-----87897532---6%----/mnt/media_rw/720ddd36-a9a5-4e8d-a80f-bf25799d1fc7
/dev/fuse-----------------------------92798268----4900736-----87897532---6%----/mnt/runtime/default/720ddd36-a9a5-4e8d-a80f-bf25799d1fc7
/dev/fuse-----------------------------927982686---4900736----87897532---6%----/mnt/runtime/read/720ddd36-a9a5-4e8d-a80f-bf25799d1fc7
/dev/fuse-----------------------------92798268-----4900736----87897532---6%----/mnt/runtime/write/720ddd36-a9a5-4e8d-a80f-bf25799d1fc7
/dev/block/vold/public:8_5-----12584956------256216------12328740----3%---/mnt/media_rw/7326C07B75B67850
/dev/fuse-----------------------------12584956-----256216-------12328740----3%--/mnt/runtime/default/7326C07B75B67850
/dev/fuse-----------------------------12584956-----256216-------12328740----3%--/mnt/runtime/read/7326C07B75B67850
/dev/fuse-----------------------------12584956-----256216-------12328740----3%--/mnt/runtime/write/7326C07B75B67850
/dev/block/vold/public:8_7------94412796-----61516412-----32896384--66%-/mnt/media_rw/288A9EF38A9EBCAE
/dev/fuse-----------------------------94412796-----61516412-----32896384---66%-/mnt/runtime/default/288A9EF38A9EBCAE
/dev/fuse-----------------------------94412796-----61516412-----32896384---66%-/mnt/runtime/read/288A9EF38A9EBCAE
/dev/fuse-----------------------------94412796-----61516412-----32896384---66%-/mnt/runtime/write/288A9EF38A9EBCAE
/dev/block/vold/public:8_8------220676840---183026824--37650016---83%--/mnt/media_rw/01D0A77D072BDC90
/dev/fuse-----------------------------220676840---183026824---37650016---83%--/mnt/runtime/default/01D0A77D072BDC90
/dev/fuse-----------------------------220676840---183026824---37650016---83%--/mnt/runtime/read/01D0A77D072BDC90
/dev/fuse-----------------------------220676840---183026824---37650016---83%--/mnt/runtime/write/01D0A77D072BDC90
/dev/block/vold/public:8_17-----7993744------68-------------7993676----1%----/mnt/media_rw/3834-74A4
/dev/fuse-----------------------------7993744------68-------------7993676-----1%---/mnt/runtime/default/3834-74A4
/dev/fuse-----------------------------7993744------68-------------7993676-----1%---/mnt/runtime/read/3834-74A4
/dev/fuse-----------------------------7993744------68-------------7993676-----1%---/mnt/runtime/write/3834-74A4
/dev/block/vold/public:8_18----5230592-------1178680------4051912-----23%--/mnt/media_rw/C004-4EFA
/dev/fuse-----------------------------5230592-------1178680------4051912-----23%--/mnt/runtime/default/C004-4EFA
/dev/fuse-----------------------------5230592-------1178680------4051912-----23%--/mnt/runtime/read/C004-4EFA
/dev/fuse-----------------------------5230592-------1178680---4051912--------23%--/mnt/runtime/write/C004-4EFA