G'day folks.
I've edited this post to remove the seemingly unnecessary clutter and to make my question simpler.
Can it please be explained to me exactly how I format my external sdcard as ext2 in such a fashion that the phone recognizes it and mounts it? I've tried using Ubuntu to format it using:
Code:
mkfs.ext2 /dev/sdb
and also the inbuilt package manager, which seems to work fine under Linux and Windows, but the phone barfs with
SD card blank or unsupported file system.
Click to expand...
Click to collapse
I've also tried the busybox method:
Code:
busybox mkfs.ext2 /dev/block/mmcblk01
and get the following error
mke2fs: lseek: Value too large for defined data type
Click to expand...
Click to collapse
I'm running JPK and rooted with the latest Busybox. I have little idea about what I'm doing but am able to follow instructions, and have used Linux on occasions before.
Any help is much appreciated. Cheers !
EXT2 should work fine - you just need to either mount it yourself manually (to /mnt/sdcard/) or you can edit the vold.conf file, and set the filesystem type there. I haven't tried it, but it should work fine.
I'm unsure as to what device it's labelled under; any pointers? Taking a look at it now...
EDIT: Here's the contents of the vold.conf file:
Code:
## vold configuration file for the emulator/SDK
volume_sdcard {
## This is the direct uevent device path to the SD slot on the device
media_path /devices/platform/s3c-sdhci.0/mmc_host/mmc0
media_type mmc
mount_point /sdcard
## ums_path /sys/devices/platform/s3c-usbgadget/gadget/lun0/file
ums_path /devices/platform/s3c-usbgadget/gadget/lun0
}
Why isn't the mount done automagically when the card is inserted or when the phone boots, like it does with FAT?
jezza333, this thread belongs in the Q&A section, not in development. Take a moment and read the "STOP, READ THIS BEFORE POSTING" thread at the top of both of these sections, it has clear guidelines for proper thread placement.
Whoops, apologies. I wasn't paying attention when I created the thread :/
exFAT might work better if you want to keep it easy to use with windoze base PCs
Yeah, but I don't know of any means to get the phone to read exFAT, apart from recompiling the kernel and including the exFAT driver. I'm happy enough with EXT2, but I need the phone to be able to mount/read it.
Bump, updated first post.
According to the modaco forum, simple
Code:
busybox mkfs.ext2
works. Personally I am waiting for my SGS-2, I'll try it immediately when it arrives.
tamas970 said:
According to the modaco forum, simple
Code:
busybox mkfs.ext2
works. Personally I am waiting for my SGS-2, I'll try it immediately when it arrives.
Click to expand...
Click to collapse
Hey-did you get the sdcard to work with ext2?I tried everything with formatting and such but couldn't get the Samsung galaxy s to recognize it correctly..could you create a step by step tutorial for me please? Thanks in advance!
Holy Thread Rebirthing
sup yall,
busybox mkfs.ext2 /dev/blcok/mmcblk1p1 (nook color) (iknow its wrong thread but only one i could found)
mkfs.ext2: lseek: Value too large for defined data type
what do
During my time hacking on android I've discovered some nice easter eggs deep in the android platform. One such easter egg is the mounting of ext4 images directly in the init.rc script. This is a feature I have never seen used by any oems and only by one custom rom [ EDIT: and by letama in his Sony Xperia Boot Manager ]! looking at the git logs this functionality has been present since September 2010 [ commit 49b8124a1759cb8b27e0c21a1a5a54b8a81bdb19 ]. What this effectively gives us is the ability to overlay a pseudo partition layout over the top over the existing layout, thus avoiding any "Danger" of accidental bricking the device by reformatting the SDCard. This is very similar to the way archos mount the stock file system and a variation/extension on the existing methods we use for the SDE Roms.
Although the explanation assumes the use of the SD models it should be fairly straightforward to apply the the HDD models.
THE METHOD:
PART 1 - Prepare a recovery ext4 image file
1. Build CWM6 from the CM10 source.
2. Modify The Recovery's init.rc file to look something similar to this
Code:
on early-init
start ueventd
on init
export PATH /sbin
export ANDROID_ROOT /system
export ANDROID_DATA /data
export EXTERNAL_STORAGE /sdcard
symlink /system/etc /etc
mkdir /boot
mkdir /sdcard
mkdir /system
mkdir /data
mkdir /cache
mount /tmp /tmp tmpfs
mkdir /partitions 0771 system system
mount ext4 /dev/block/mmcblk0p4 /partitions
# Mount /system rw first to give the filesystem a chance to save a checkpoint
mount ext4 [email protected]/partitions/CAC /cache nosuid nodev
mount ext4 [email protected]/partitions/DATA /data nosuid nodev
mount ext4 [email protected]/partitions/SYS /system
mount ext4 [email protected]/partitions/SDCARD /sdcard nosuid nodev
mount ext4 [email protected]/partitions/BOOT /boot
on boot
ifup lo
hostname localhost
domainname localdomain
class_start default
service ueventd /sbin/ueventd
critical
service recovery /sbin/recovery
service adbd /sbin/adbd recovery
disabled
# Always start adbd on userdebug and eng builds
# In recovery, always run adbd as root.
on property:ro.debuggable=1
write /sys/class/android_usb/android0/enable 0
write /sys/class/android_usb/android0/idVendor 18D1
write /sys/class/android_usb/android0/idProduct D001
write /sys/class/android_usb/android0/functions adb
#write /sys/class/android_usb/android0/enable 1
write /sys/class/android_usb/android0/iManufacturer $ro.product.manufacturer
write /sys/class/android_usb/android0/iProduct $ro.product.model
write /sys/class/android_usb/android0/iSerial A101S_REC
#start adbd
setprop service.adb.root 1
# Restart adbd so it can run as root
on property:service.adb.root=1
write /sys/class/android_usb/android0/enable 0
restart adbd
write /sys/class/android_usb/android0/enable 1
3. Modify the etc/recovery.fstab to look like this
Code:
# mount point fstype device
/cache ext4 /dev/block/loop1
/data ext4 /dev/block/loop2
/system ext4 /dev/block/loop3
/sdcard ext4 /dev/block/loop4
4. Creating an empty ext4 image file name REC and mount it on your pc. [ 5MB should do it ]
5. Copy the contents of the built recovery/root directory to the root of your mounted image.
6. chmod init.rc , default.prop and ueventd.rc to 644 ( rw-r-r- )
7. umount the ext4 image and push it to the root of you data partition
That's stage 1 complete. Part 2 Will Follow Shortly.....
Part 2 - Make a dual boot initramfs.cpio.lzo
1. Change the name of the /data directory to /bootdata by modifying the etc/mountpoints file in the initramfs.cpio.lzo. This stops CWM getting confused when trying to un/mount the data partition
Code:
mount_name mount_dev mount_point mount_fs mount_opts volume_name error_code custom_opt
rawfs /dev/mmcblk0p1 /mnt/rawfs rawfs none 150
system /dev/mmcblk0p2 /mnt/system ext4 rw,noatime,noexec system 152
bootdata /dev/mmcblk0p4 /bootdata ext4 rw,noatime,noexec bootdata 154 crypt_compat
storage /dev/mmcblk1p1 /mnt/storage ext4 rw,noatime #storage_name# 155
storage_A80S /bootdata/media /mnt/storage bind bootdata none 155
storage_A101S /bootdata/media /mnt/storage bind bootdata none 155
storage_A101XS /bootdata/media /mnt/storage bind bootdata none 155
storage_LUDO /bootdata/media /mnt/storage bind bootdata none 155
storage_A80H /dev/hdd1 /mnt/storage ext4 rw,noatime #storage_name# 155
storage_A101H /dev/hdd1 /mnt/storage ext4 rw,noatime #storage_name# 155
usbhost_ehci /dev/storage_ehci1 /mnt/usbhost_ehci vfat rw,noatime,utf8,shortname=mixed none 156
usbhost_otg /dev/storage_otg1 /mnt/usbhost_otg vfat rw,noatime,utf8,shortname=mixed none 156
rfsext4 /dev/loop0 /new-root ext4 rw,noatime none 157
rfsext3 /dev/loop0 /new-root ext3 rw,noatime none 157
rootfs /dev/loop0 /new-root squashfs ro,cts_compat none 157
ramdisk /tmp/ramdisk /ramdisk vfat loop,rw,utf8,shortname=mixed #ramdisk_name# 158 ramdisk,ramdisk_size=256
2. Using sirduke989 dmenu initramfs you can modify the init script in the initramfs to mount /bootdata instead of /data and also add /bootdata/REC and /bootdata/BOOT to the list
of known locations , I see this a temporary measure as there are a number of other ways to enable dual ( Triple?!? ) booting
3. Flash the modified initramfs and your choice of kernel using either the recovery menu or kd_flasher, I used the 3.0.21 kernel extracted from the 4.0.24 aos file.
You should now be able to boot into CWM Recovery!
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Clearly I'm a developer not a photographer!!
Part 3 - Create rest of the "partition" images.
You should have a /partitions directory in you device root, This is what is normally mounted as your /data ( /dev/block/mmcblk0p4) and contains normal android user data e.g installed app settings databases etc. This is where I've created the reset of my Partitions which are just more ext4 images files. I did this using "dd if=/dev/zero ...." and "mke2fs -text4 ...." on the device through adb whilst booted into CWM. This saved time in pushing large empty ext4 files from my pc.
I called my image CAC ( cache ) DATA ( data ) SYS ( system ) SDCARD ( sdcard ) BOOT ( boot ) you can obviously call them what you like and place them anywhere as long as you match up the image names with those in init.rc and make sure the loop numbers are correct in the etc/recovery.fstab everything should be fine.
You can play around with the files sizes, I have an 8gb my current file sizes at the moment are
BOOT = 25MB
CAC = 500MB
DATA = 3GB
SYS = 500MB
SDCARD = 2GB
The sdcard mount point is probably worth pointing at an external sd if you have one available. I have a 32GB Class 10 that I'll probably set up.
After you've setup your psuedo partitions you should then be able to reboot into recovery, if you've done things correctly you mount output should contain the following
Code:
/dev/block/mmcblk0p4 on /partitions type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)
/dev/block/loop1 on /cache type ext4 (rw,nosuid,nodev,relatime,user_xattr,barrier=1,data=ordered)
/dev/block/loop2 on /data type ext4 (rw,nosuid,nodev,relatime,user_xattr,barrier=1,data=ordered)
/dev/block/loop3 on /system type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)
/dev/block/loop4 on /sdcard type ext4 (rw,nosuid,nodev,relatime,user_xattr,barrier=1,data=ordered)
/dev/block/loop5 on /boot type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)
Everything seems to function correctly, I have successful done a backup and restore of my system partition. I have also applied CWM-SuperSU.zip through install zip from sdcard. Mounting and Remounting works although I'm not sure if Mount USB Storage works yet, I didn't on linux and I've not tested on windows and finally wiping and formating was also successful.
Part 4 - Notes on setting up rom images.
Now you may of already realized normal archos images don't come as separate the /boot and /system images so work is require to split them up.
Also if you want to split the /system from the reset of a archos image your boot partition will need to be about 50MB as archos have they /bin /lib /usr directories which contains binary files that use /lib/libuClibc-*.so as it's libc which brings there root filesystem in at around 38MB.
There is a very strong case for ditching these binaries especially when using AOSP/CM based roms. My intial tests show this is possible.
Just like the recovery init.rc Similar changes have to be made to the roms init.rc
Moving Forward:
of course, there's a lot to do but I wanted to at least get this initial information out there for people to consider. I'm currently booting a Linaro 4.1.1 rom using the split partitions. I have also been working on better booting methods which is why I haven't given any details re the initramfs init script but It's fairly straight forward to adjust and adapt. I'll write up more details soon!
More Research!
As I mentioned, I've been further looking into different booting methods and I think I'm approaching what could be a workable solution that will make the Gen9 more like standard android devices
Here's some more of my findings
1. It turns out that we can dump the existing initramfs.cpio.lzo and we can use a standard android ramdisk layout as the android init will load instead of the init script that is currently being used, this also removes the need for switch root and other nonsense that archos have in there. There was one gotcha when had me stumped for about ten minutes, I needed to add "write /sys/class/leds/lcd-backlight/brightness 75" to the init.rc to turn the screen on.
2. It's possible to stop android either using adb shell stop or stopping each service zygote etc, and start CWM while android is booted. It's probably also feasible the manage booting between recovery and android using the persist properties system which should make switching between the 2 fairly easy to control without much tweaking to any binaries. Looking at other devices, namely samsung, they seem to do something similar with recovery being in the same boot.img as the standard files, they simply load a recovery.rc instead of the main init.rc, this might mean that we have to patch CWM to load the correct init.rc I've not looked at the code properly yet but It's not going to be an issue anyway as all the code is fully available, You've gotta love open source.
3. By mounting /dev/block/mmcblk0p1 to /mnt/rawfs we are still able to use abcbox, reboot_into writes to the params file in the partition to control boot switching, so we can maintain booting into sde while leaving the stock android partition in place. I was unable to get any immediate joy from kd_flasher, that maybe because we currently have the ramdisk we want to overwrite mounted as the rootfs. Again I can't imagine it being too difficult to jig this, It can probably be worked out by looking at the current recovery ramdisk scripts should kd_flasher style functionality be required at any point.
4. Most of the binaries that rely on uClibc can be recompiled against bionic without any issue, usb_modeswitch for example. If there are any closed source ones, then the dynamic linker ld-uclibc or whatever is called, ultimately symlinks back to uClibc and we can just grab the one file and place it in the /lib directory. I tested /usr/bin/lsdvd in this way and It seemed to work fine.
I've got all this going on while still leaving a stock android fully intact, which is a great fallback Just in case.... Keeping these modifications at a safe level is one of the primary goals to enable much wider use
I'll put together some examples within the next couple of days to demostrate what I'm talking about here.
I've got a Linaro 4.1.1 ( JRO03R ) which has working powervr drivers with a 3.0.21 kernel, although that's about all that's working on it at the minute.
It's more a proof of concept than anything else, The kernel would need recompiling to add tracefs functionality which is required by jellybean but using the same magic should leave the powervr drivers functioning still, If anyone's interested I can stick that up, I've foolishly deleted ( misplaced/can't remember ) the device files I used to build this.... Too many android source trees and not using git properly leads to school boy errors.
I'm currently working on an omapzoom 4.1.2 tree using the blaze_tablet device as a base, I think this may yield the best results for the archos.
I suppose one other thing to do is the fix up a stock rom to use these methods and give it CWM, that should be pretty simple to do. Although ICS is ooold and I'm really not a fan of some of archos' methods e.g booting 4 different devices off one firmware. Although to their credit they do demostrate just what possible with deviating android from it's normal standard structures.
Hopefully this has whetted your appetites, I'm pretty excited about what's possible here as I feel it brings these archos devices in line with most others.
Me Again!
Just a cheeky little update, I been trying the figure out the best approach to handle switching between android and recovery mode. In effect I kind of wanted to create a Stage 4 bootloader! because you can never have too many bootloaders LOL I certainly wanted to do a "proper" job on it and try to avoid changes to the android platform code.
While to doing research into this I found this patch to the linux kernel which the android team submitted for review, Reading the mailing list thread I don't think it's been accepted yet! It's true what they say about the Kernel Mailing List, You need to bring your A game and be sure of what your doing..
Anyways the patch add a boot-control-block driver to kernel which check for a boot flag, which is exactly what I need to make booting into alternative configuration nice and simple. I suppose it wouldn't be too difficult to chuck in support for the fastboot protocol on one of those configurations. So a CWM Shouldn't be too far off now!!!
As a little treat I've attached a recovery based ram disk if anyone what's to play, just flash it with you favourite kernel on to your sde partition. Then You can boot into recovery and set your self up a pseudo partition image layout through adb. You won't be able to be into android, obviously until you put your old initramfs back.......
This is totally unsupported.
Click to expand...
Click to collapse
I'm just chucking up for those who want to get a feel for to do so. If your uncomfortable playing around in this area then stand well back, It's not prime time yet!!!!
However Feel free to ask questions of a technical bent but If you can't get it to boot then tough luck I'm afraid for now! :laugh:
You shouldn't be able to do any damage with this be I wouldn't go selecting wipe/format etc until you've got some partition images sorted.
I've add abcbox to sbin and symlink reboot_into. It does not seem to fully reboot but It will set the boot flag which you then follow with a call to reboot, That will reboot back into CWM (sde).
Onward
EDIT: Here's the Init.rc and etc/recovery.fstab that It attempts to use.
Code:
on early-init
start ueventd
on init
export PATH /sbin
export ANDROID_ROOT /system
export ANDROID_DATA /data
export EXTERNAL_STORAGE /sdcard
symlink /system/etc /etc
mkdir /boot
mkdir /sdcard
mkdir /system
mkdir /data
mkdir /cache
mkdir /mnt
mkdir /mnt/rawfs
mount /tmp /tmp tmpfs
mkdir /partitions 0771 system system
mount ext4 /dev/block/mmcblk0p4 /partitions
mount rawfs /dev/block/mmcblk0p1 /mnt/rawfs
# Mount /system rw first to give the filesystem a chance to save a checkpoint
mount ext4 [email protected]/partitions/CAC /cache nosuid nodev
mount ext4 [email protected]/partitions/DATA /data nosuid nodev
mount ext4 [email protected]/partitions/SYS /system
mount ext4 [email protected]/partitions/SDCARD /sdcard nosuid nodev
mount ext4 [email protected]/partitions/BOOT /boot
on boot
ifup lo
hostname localhost
domainname localdomain
class_start default
service ueventd /sbin/ueventd
critical
service recovery /sbin/recovery
service adbd /sbin/adbd recovery
disabled
# Always start adbd on userdebug and eng builds
# In recovery, always run adbd as root.
on property:ro.debuggable=1
write /sys/class/android_usb/android0/enable 0
write /sys/class/android_usb/android0/idVendor 18D1
write /sys/class/android_usb/android0/idProduct D001
write /sys/class/android_usb/android0/functions adb
#write /sys/class/android_usb/android0/enable 1
write /sys/class/android_usb/android0/iManufacturer $ro.product.manufacturer
write /sys/class/android_usb/android0/iProduct $ro.product.model
write /sys/class/android_usb/android0/iSerial A101S_REC
write /sys/class/leds/lcd-backlight/brightness 75
#start adbd
setprop service.adb.root 1
# Restart adbd so it can run as root
on property:service.adb.root=1
write /sys/class/android_usb/android0/enable 0
restart adbd
write /sys/class/android_usb/android0/enable 1
Recovery.fstab
Code:
# mount point fstype device
/cache ext4 /dev/block/loop0
/data ext4 /dev/block/loop1
/system ext4 /dev/block/loop2
/sdcard ext4 /dev/block/loop3
Any words about hdd versions?
DragosP2010 said:
Any words about hdd versions?
Click to expand...
Click to collapse
I all depends how you want the structure it, What it would change is the mount point of the paritions directory. After that. everything is loop mounted and sitting on top of the existing structure.
Code:
mount ext4 /dev/block/mmcblk0p4 /partitions
Great stuff!!!!
Hey trevd,
that's fantastic... i will definitely try this CWM in a few days with my custom kernel and bootloader (mountpoint will need some tweaks as well ).
I'm very busy these days, so i gess i'll leave some longer statements to the recent developments in a few days.
Just in short... it's very pleasant to see all these open developments popping up and i really, really appreciate this kind of hacking!
Keep on your great work... you rock!!
Cheers,
scholbert
Hi Trevd,
Nice job!
I've been using the same kind of trick on my Xperia S boot manager project, recovery on loops and mount [email protected] in inits. You may want to take a look at what I did there (see my sig), it may have some use for your project.
Basically, what I do is storing multiple kernels+cpios on the regular kernel partition. I use one (trimmed down to maximize space) to handle the boot logic and cwm, and I have enough space to handle two "regular" kernels. I handle kernel switch just before they load with a small assembly loader. It works very nicely on Xperia, and it's very nice to be able to dual boot with isolated cwms. I can't remember maximum size on a g9 kernel rawfs file, but I think you could have at least enough space to have two kernels to isolate recovery.
Hey letama,
nice to read you :highfive:
letama said:
I've been using the same kind of trick on my Xperia S boot manager project, recovery on loops and mount [email protected] in inits. You may want to take a look at what I did there (see my sig), it may have some use for your project.
Click to expand...
Click to collapse
Cool stuff again...
letama said:
Basically, what I do is storing multiple kernels+cpios on the regular kernel partition. I use one (trimmed down to maximize space) to handle the boot logic and cwm, and I have enough space to handle two "regular" kernels. I handle kernel switch just before they load with a small assembly loader. It works very nicely on Xperia, and it's very nice to be able to dual boot with isolated cwms. I can't remember maximum size on a g9 kernel rawfs file, but I think you could have at least enough space to have two kernels to isolate recovery.
Click to expand...
Click to collapse
AFAIK, we got around ~30MBytes in the raws partition on our tablets so would be possible to put some more kernel+cpios here easily.
Anyway, made some experiments with my latest u-boot port for the tablet this weekend.
I was able to bring up my A80S completely from MicroSD and boot into CWM by using uImage and uInitramfs (based on trevd's CWM image).
There's also some lowlevel multiboot implemented now by using the volume keys... but i know that i use a very special setup, so this is more a proof of concept and not a suitable environment for the average user
Cheers,
scholbert
Thanks Letama + Scholbert
I'll look at all this stuff this week....As a aside, I've played around with mmcblk0p3 and given myself an mmcblk0p5 / 6 of 4MB each. I found parted to be pretty useful (read:safe) for this..... I'm dubious about playing around with the rawfs too much at this point, mainly because I don't understand it fully, yet!.
Have you guy seen this https://github.com/swetland/omap4boot ( I think it's along the line of what Scholbert been working with/on )
Like I've mentioned to ultimate goal is a solution that is "safe" for the average user and also leaves the rest of the tablet in-tact, it maybe a lofty goal but worth a shot. :good:
Thanks for the input guys!
scholbert said:
AFAIK, we got around ~30MBytes in the raws partition on our tablets so would be possible to put some more kernel+cpios here easily.
Click to expand...
Click to collapse
30 for init kernel ? That's plenty indeed! Cool!
Anyway, made some experiments with my latest u-boot port for the tablet this weekend.
I was able to bring up my A80S completely from MicroSD and boot into CWM by using uImage and uInitramfs (based on trevd's CWM image).
There's also some lowlevel multiboot implemented now by using the volume keys... but i know that i use a very special setup, so this is more a proof of concept and not a suitable environment for the average user
Click to expand...
Click to collapse
Nice job! Too bad that Archos doesn't do this on their board with a small internal switch. Would be cool for people like me with big fingers and poor soldering skills
trevd said:
I'll look at all this stuff this week....As a aside, I've played around with mmcblk0p3 and given myself an mmcblk0p5 / 6 of 4MB each. I found parted to be pretty useful (read:safe) for this..... I'm dubious about playing around with the rawfs too much at this point, mainly because I don't understand it fully, yet!.
Click to expand...
Click to collapse
Hummm... You're going to end with a full re-partitioning scheme with system and data if you continue this way . Just be careful when you recreate partitions to let the empty space at the beginning of the disk untouched, instant brick ahead if you go there...
Just in case, here is what I did with my repartition script (do you have it ?): delete p3, delete p4, re-create p3 (careful with start point, leave the hole! it should start just after p2) as extended partition, big enough to hold the new partitions, recreate p4 (same thing about the hole, it should start after p3) with what remains and then you can create p5,p6,p7 with the size you want inside p3.
Last advice: rawfs, don't touch it .
Anyway, the good thing with what I did on Xperia S is that you don't mess with rawfs and re-partition, it's just like flashing a very big SDE kernel from recovery with unmodfified sde firmware, that's all. If I find some time, I'll take a look to see if we can do the same thing here.
letama said:
Just in case, here is what I did with my repartition script (do you have it ?): delete p3, delete p4, re-create p3 (careful with start point, leave the hole! it should start just after p2) as extended partition, big enough to hold the new partitions, recreate p4 (same thing about the hole, it should start after p3) with what remains and then you can create p5,p6,p7 with the size you want inside p3.
Click to expand...
Click to collapse
Hi
Yes I have read your previous threads on the subject which provided alot of the inspiration for the work currently at hand, It is also why I am being ultra careful around the partitions
I think maybe I'm just being too clever trying too pull everything back a step into the intramfs when we can just do the old switch root method method.... It's a little messy on the inside but it will get the job done!
Well, I don't like much the switch root too, it's not a very "Android way" of doing things and make some apps not very happy with it, but yes, it will get the job done, one root for recovery, one root for firmware. And Archos stock would be difficult without switch root, they did put far too much stuff outside of system.
letama said:
Well, I don't like much the switch root too, it's not a very "Android way" of doing things and make some apps not very happy with it, but yes, it will get the job done, one root for recovery, one root for firmware. And Archos stock would be difficult without switch root, they did put far too much stuff outside of system.
Click to expand...
Click to collapse
I'm very much for the "Android Way" I believe the archos stock roms can be re-jigged as the stuff outside of the system is not required by the system, this is all stuff that is a result of the BuildRoot build system and has a dependency on uClibc.
I'm going to try and get something usable this week, can I store additional files in the rawfs partition without running into trouble?
trevd said:
I'm very much for the "Android Way" I believe the archos stock roms can be re-jigged as the stuff outside of the system is not required by the system, this is all stuff that is a result of the BuildRoot build system and has a dependency on uClibc.
Click to expand...
Click to collapse
Well, it's required. It's used inside Android, it handles audio, wifi, codecs, smb...
I'm going to try and get something usable this week, can I store additional files in the rawfs partition without running into trouble?
Click to expand...
Click to collapse
In rawfs or initramfs ? I wouldn't add any file in rawfs, it would be difficult to do and I don't know how would behave the bootloader if it sees new files there. Initramfs you're free to do whatever you want until you reach maximum size of kernel+initramfs.
trevd said:
Have you guy seen this https://github.com/swetland/omap4boot ( I think it's along the line of what Scholbert been working with/on )
Click to expand...
Click to collapse
Well kind of... while i try to stick with the MicroSD our fellow vincencb follows the omap4boot path.
He already made a port of barebox bootloader to work with this tool and pushed it to the repos.
This way you may put anything you like on the tablet's RAM by using MicroUSB for communication and file transfer.
My way is more to get a full featured u-boot and put it into a state, where it might replace stock loader.
Last step is to put it in internal eMMC... so this is also research and development for now.
trevd said:
Like I've mentioned to ultimate goal is a solution that is "safe" for the average user and also leaves the rest of the tablet in-tact, it maybe a lofty goal but worth a shot. :good:
Click to expand...
Click to collapse
Yepp that sounds like a reasonable approach.
letama said:
30 for init kernel ? That's plenty indeed! Cool!
Click to expand...
Click to collapse
To be even more precisely, there are 32512*1K blocks for the rawfs partition.
On my device there's ~12MB left...
letama said:
Nice job! Too bad that Archos doesn't do this on their board with a small internal switch. Would be cool for people like me with big fingers and poor soldering skills
Click to expand...
Click to collapse
Yeah, a real switch would be nice indeed... there's some unused testpoints giving us additional GPIO
Need to solder though...
trevd said:
I'm very much for the "Android Way" I believe the archos stock roms can be re-jigged as the stuff outside of the system is not required by the system, this is all stuff that is a result of the BuildRoot build system and has a dependency on uClibc.
Click to expand...
Click to collapse
Some stuff outside of system is quite useful and gives us something like a minimal linux ecosystem.
Very useful at console level... some tools seem to be used by the Android system as well.
trevd said:
I'm going to try and get something usable this week, can I store additional files in the rawfs partition without running into trouble?
Click to expand...
Click to collapse
Mmmh, letama maybe right with being very careful with this part of internal storage. If it get's corrupt you'll risk a brick (could be restored though by using external boot mechanism).
Anyway the best would be to mount it RW and use the kernel driver to access it... the unknown part is still the bootcode.
There's some kind of allocation table at the beginning of rawfs partition. It is yet unknown how bootcode behaves with an additional entry
Anyway, this is a real nice project and i would really appreciate to see it pushing forward.
Take your time trevd, and again thanks a lot for contribution!!
Have a nice day,
scholbert
Not to put this down in any way, but wouldn't TWRP be better for the G9? It has a full touch tablet UI, which is better than CWM's
Sent from my Galaxy Nexus using Tapatalk 2
Quinny899 said:
Not to put this down in any way, but wouldn't TWRP be better for the G9? It has a full touch tablet UI, which is better than CWM's
Sent from my Galaxy Nexus using Tapatalk 2
Click to expand...
Click to collapse
Hi Quinny
There's nothing to stop us using whatever recovery we like.... they all work the same way ( I think ) , i.e the code is compiled into a recovery binary. Unfortunately my touch screen stopped working long ago so I wouldn't really benefit
scholbert said:
To be even more precisely, there are 32512*1K blocks for the rawfs partition.
On my device there's ~12MB left...
Click to expand...
Click to collapse
Ah, yes, but there is space reserved for each file there, what I have to figure is how much is reserved for custom file (sde kernel). I don't want to have to shift the files located after custom to make room for sde kernel , it would defeat the "no-fuss/no-risk" of the method.
Anyway the best would be to mount it RW and use the kernel driver to access it... the unknown part is still the bootcode.
There's some kind of allocation table at the beginning of rawfs partition. It is yet unknown how bootcode behaves with an additional entry
Click to expand...
Click to collapse
Definitely. Re-partitioning is much safer if space is needed.
trevd said:
.... they all work the same way ( I think ) , i.e the code is compiled into a recovery binary.
Click to expand...
Click to collapse
This is a good keyword: The recovery binary itself!
Most tools inside the recovery are simply linked to busybox, which itself is a link to recovery executable.
In other words, we have some code responsable for the menu and framebuffer stuff and we have busybox.
The strings command gave me version 1.2.0. Now my question...
How to configure this part of code?
I'd like to enhance the busybox part.
Could you please provide a little to howto for a compiler run?
Will i need all that Android stuff installed...
I you have any clue, please point me in the right direction.
Lazy,
scholbert
scholbert said:
How to configure this part of code?
I'd like to enhance the busybox part.
Could you please provide a little to howto for a compiler run?
Will i need all that Android stuff installed...
Click to expand...
Click to collapse
Yes, you need full android repo. Android Build system is messy and tightly coupled, busybox is compiled with bionic (android libc), recovery is built on top of it with few android libraries links. Isolating all this "mess" would be difficult. Except disk space required, there is no big deal in getting full android repo.
I'd suggest to take a look at this, you should do the "Prepare the Build Environment" section.
I don't know how trevd built his recovery, but what I did is create a gen9 device to get proper configuration for recovery (frame buffer config, ...). You can get mine if you want, it's a little outdated (latest cwm doesn't need a specific gfx anymore, the custom one I used has been moved to upstream for instance), but it should give you a base.
To do that, you have to create an "archos" directory in cm9/device directory, then from inside it do:
Code:
git clone git://gitorious.org/archos-ics/device-g9.git gen9
Then, you need to setup the build env once. From cm9 root, you have to do that:
Code:
. build/envsetup.sh
(it setups android build environment)
then
Code:
lunch
then choose full_gen9-eng.
(it selects device target for build)
You should have something like that:
Code:
============================================
PLATFORM_VERSION_CODENAME=REL
PLATFORM_VERSION=4.0.4
TARGET_PRODUCT=full_gen9
TARGET_BUILD_VARIANT=eng
TARGET_BUILD_TYPE=release
TARGET_BUILD_APPS=
TARGET_ARCH=arm
TARGET_ARCH_VARIANT=armv7-a-neon
HOST_ARCH=x86
HOST_OS=linux
HOST_BUILD_TYPE=release
BUILD_ID=IMM76L
============================================
from this point, you can compile:
make -j4 recoveryimage (change j4 with the number of parallel build you want depending on your cpu).
whole recovery fs should be in out/target/product/gen9/recovery/root, with recovery command in sbin
Last, how do you want to extend it? If you want to add custom commands, take a look at cwm bootable/recovery/extendedcommands.c, it may be easier to add stuff there than in busybox.
[Q] encryption, ext2/4, and "filesystem too large to mount safely" error fix?
Hello again,
With my Droid 3 (thanks to Minimoto) again working great, I've turned my attention back to encrypting some of my data on the external SD card. I had used "LUKS Manager" some time ago so that seemed the logical place to start.
Okay, the short *short* version is: What does the error message (from dmesg output) "EXT4-fs (dm-4): filesystem too large to mount safely on this system" mean and how do I fix it or work around it?
The details:
I have a 32 GB SD card with a normal ~20 GB FAT partition that Android sees and uses just fine. On my laptop I created an ext4 file system on the second partition (the remaining ~12 GB of space). Android does not see or use this, but from a terminal I *can* mount it without problems. I chose to mount /dev/block/mmcblk0p2 (external SD partition 2) at /mnt/sdcard-ext-p2. Just FYI, but I wrote a short script and put it at /etc/init.d/03mount_sdpart2 to mount this second partition at the correct mount point and it works fine. Even after a reboot the script runs without problems and now I always have my new ext4 file system present.
The reason for creating the ext4 file system is because FAT does not support files larger than 4 GB and therefore my encrypted volume cannot be larger than 4 GB *if* I create that volume on a FAT file system. With the new ext4 file system, now using the LUKS Manager app, I created a new volume at the above mount point with a size of approximately 11.25 GB. This worked fine, too. The last step, however, actually mounting this encrypted volume, keeps failing. It was supposed to be mounted at /mnt/sdcard/LUKS. Unfortunately, LUKS Manager did not produce much in the way of information about why it had failed.
A quick note about file sizes: If I use an app like "ES File Explorer" and go to /mnt/sdcard-ext-p2 where the large volume file exists, ES says the volume file has a size of -805306366 bytes, obviously wrong. Fortunately, if I use the terminal and look at the file size with "ls -l" it has the correct size. Furthermore, after I opened the volume below using lm.cryptsetup I can use its "status" command and after converting the values from sectors (each sector is 512 bytes) it also displays the correct size of the encrypted volume.
So, back to the terminal where I decided to do the steps manually and see where it failed. For the most part, I used different device and directory names than what LUKS Manager would have used, mostly to be sure I wouldn't accidentally conflict with another process/app. The 'lm.cryptsetup' binary is provided by LUKS Manager and placed in /system/bin. I have the version of busybox that, I assume, ships with Minimoto which is busybox v1.20.0. This is where the 'losetup' I am using comes from.
Concerning loopback devices: LUKS Manager defaults to using/creating high numbered loopback devices, 300 for the first volume created. On Android the loop devices are created in /dev/block, but some tools don't seem to look there. In particular, lm.cryptsetup complains about not being able to find a free loopback device and 'losetup -f' (which displays the next free/available loopback device) always refers to devices in /dev regardless of where they really are. Making symlinks such as "ln -s /dev/block/loop0 /dev/loop0" for each of the currently present loop devs (0 through 7, and 300) fixes both of these problems. That said, whatever manner LUKS Manager uses to execute the underlying tools works properly with the loop devs being located in /dev/block. This can be verified by using "lm.cryptsetup status <crypt_dev>" and the status output shows that it is correctly attached to, for example, /dev/block/loop300. Making these symlinks is more of a convenience/fix for when one is working directly on the command line.
Where, before, 'losetup -f' indicated that /dev/loop0 was free (even though it did not exist), after making the symlinks the same command indicates that /dev/loop4 is the next free loop. On my phone, at that moment in time, that was the correct answer. loop4 also makes sense because I have four apps that I have "moved to SD" and for each app that you do this one loopback device is used (so loop0 - loop3 were used by apps "moved" from main internal storage). Creating these symlinks also made lm.cryptsetup stop complaining/erroring about not being able to find a free loop dev. Finally, running "losetup" without arguments is supposed to list the used loop devs and what is using them. Before making the symlinks is produced no output, and now, after the symlinks, it displays:
Code:
/dev/loop0: 0 /mnt/secure/asec/blah_appA.asec
/dev/loop1: 0 /mnt/secure/asec/blah_appB.asec
/dev/loop2: 0 /mnt/secure/asec/blah_appC.asec
/dev/loop3: 0 /mnt/secure/asec/blah_appD.asec
/dev/loop5: 0 /ss/safestrap/rom-slot2/cache.img
/dev/loop6: 0 /ss/safestrap/rom-slot2/userdata.img
/dev/loop7: 0 /ss/safestrap/rom-slot2/system.img
As you can see, loop4 is missing/available. Also, rom-slot2 is correct as it is where I opted to install Minimoto, rom-slot1 currently containing CM 10.1.
With the loop device issues taken care of, the steps I performed are as follows:
Code:
$ su
# lm.cryptsetup luksOpen /mnt/sdcard-ext-p2/MyCrypto.vol MyCrypto
<type in passphrase>
# ls /dev/mapper
MyCrypto control
# mkdir /mnt/sdcard/luks-tst
# mount /dev/mapper/MyCrypto /mnt/sdcard/luks-tst
mount: mounting /dev/mapper/MyCrypto of /mnt/sdcard/luks-tst failed: File too large
# dmesg | tail -2
[20665.748504] EXT4-fs (dm-4): filesystem too large to mount safely on this system
[20665.750732] EXT4-fs (dm-4): filesystem too large to mount safely on this system
You can see from the above block my commands and the output, especially errors, that followed. Clearly, the file is "too large"... but how? The whole point of this extra partition and ext4 file system stuff was specifically to get around the FAT 4GB file size limitation. Unfortunately, while these errors tell me that something is too large, what *part* is too large? Is the 11.25 GB volume *container* too large, or the ext2/4 file system that exists inside the volume? And if either is too large, what is the maximum size I can make them? I did try adding "-t ext2" and "-t ext4" to the mount command, but neither one changed the outcome nor did they change the messages that were output.
The 'mount' binary (like most others) is provided by busybox, so it could possibly be part of the problem. However, the last two errors above come from the kernel log (via dmesg) which means that at least part of the issue is the kernel, maybe the file system modules. I also checked the logcat output, just in case, but it did not contain anything related or useful. Minimoto 1.7 is using kernel version 2.6.35.7 and perhaps it has some maximum size issues I am unaware of. With the exception of my Droid 3, I haven't used a 2.6.x Linux kernel in a very long time.
I've searched around here as well as the fairly small LUKS Manager message board and the Net at large, but I haven't been able to find the answers I'm looking for. Any ideas as to what I might have done wrong, or something I haven't done but should? I'm not sure how to proceed. Just to be perfectly safe, I did try rebooting but it made no difference.
--John Gruenenfelder
Re: [Q] encryption, ext2/4, and "filesystem too large to mount safely" error fix?
Could it be that your mount point is within the FAT fs, what about creating a new mount point at say /mnt/LUKS
Sent from my XT860 using xda premium
Re: [Q] encryption, ext2/4, and "filesystem too large to mount safely" error fix?
I tried using /mnt/LUKS (instead of the previous /mnt/sdcard/LUKS) as the mount point, but nothing changed. The "filesystem is too large..." messages still appeared.
I don't know why there are two such messages separated by about 2/1000th of a second in the dmesg output even though I issued just one command. It was the same way in my first post.
If I recall, the original reason for putting the mount point under /mnt/sdcard was so that most apps could see/use the new area without having any extra knowledge.
--Sent from my DROID3 using xda app-developers app
I think a huge number of users will be helped greatly if there will be a guide to swap internal sd card to a larger external.
In 4.2 versions and before, the process was fairly easy in Note, with the use of root explorer and just changing some values in vold.fstab file.
In 4.3 what will be the process and which values you should change?
Sent from my Transformer TF101 using XDA Premium 4 mobile app
That would also be of interest for me. In fact, there ar still no instructions, how to do that (external to internal SD).
there are use the search for crying out loud
Sent from my GT-N7000 using Tapatalk 2
Android 4.3 Swap External With Internal
Since baz is an obvious douche. Here's how you do it (and yes it's posted *somewhere* on the xda threads)
Pull your build.prop from your phone and add the following lines to the bottom: (adb pull /system/build.prop)
Edit the build.prop with Notepad++
If it contains the line remove ro.vold.switchablepair=/emmc,/storage/sdcard0 (or any variant - remove it)
Paste the following at the bottom of the build.prop.
# Switch External With Internal
persist.sys.vold.switchexternal=1
# Storage configuration
ro.vold.switchablepair=/storage/sdcard0,/storage/sdcard1
Save the file, (at command prompt type)
adb root
adb shell mount -o rw,remount /system
adb push build.prop /system
adb reboot
These instructions are obviously not completely in depth and don't hold your hand all the way. You'll need to somewhat know what you're doing.
As always make sure to make a nandroid backup in the rare case that something goes wrong.
help
viiron said:
Since baz is an obvious douche. Here's how you do it (and yes it's posted *somewhere* on the xda threads)
Pull your build.prop from your phone and add the following lines to the bottom: (adb pull /system/build.prop)
Edit the build.prop with Notepad++
If it contains the line remove ro.vold.switchablepair=/emmc,/storage/sdcard0 (or any variant - remove it)
Paste the following at the bottom of the build.prop.
# Switch External With Internal
persist.sys.vold.switchexternal=1
# Storage configuration
ro.vold.switchablepair=/storage/sdcard0,/storage/sdcard1
Save the file, (at command prompt type)
adb root
adb shell mount -o rw,remount /system
adb push build.prop /system
adb reboot
These instructions are obviously not completely in depth and don't hold your hand all the way. You'll need to somewhat know what you're doing.
As always make sure to make a nandroid backup in the rare case that something goes wrong.
Click to expand...
Click to collapse
Can someone explain this a little better I download the app and changed the settings but how do I change the build number
bigevil124 said:
Can someone explain this a little better I download the app and changed the settings but how do I change the build number
Click to expand...
Click to collapse
I dont know which app You're taking about, but You can do it without using adb. Just copy build.prop to Your pc (make a backup copy), edit necessary lines and paste it paste back (and set good permissions).
Sent from d605
Sorry im really a newbie when coming to 4.3 I downloaded the root external 2 sd app and I thought thats where I change these settings. Im not sure down to edit the permissions or build numbers or linesÉ when running 4.1 I flashed a zip and it changed my storage so this is all new to me. Sorry for the hassel but your help is much appreciated
Hi all!
That's the trick i'm looking for! I have an Archos 45 Helium 4G with Android 4.3. I've just tried to edit my build.prop. I have rebooted the phone and..... nothing....
That method is OK with all android 4.3 devices or just for the Samsung Galaxy Note GT-N7000?
Also i've got that on my build.prop
Code:
# system prop for storage test
ro.external.sd.path=/storage/sdcard1
Maybe i have to change that one... but i don't know...
or maybe the solution is in the fstab.qcom but i'm afraid to touch that one.... and there are other fstab files, so i don't know which one is used....
Code:
# Android fstab file.
# The filesystem that contains the filesystem checker binary (typically /system) cannot
# specify MF_CHECK, and must come before any filesystems that do specify MF_CHECK
#TODO: Add 'check' as fs_mgr_flags with data partition.
# Currently we dont have e2fsck compiled. So fs check would failed.
#<src> <mnt_point> <type> <mnt_flags and options> <fs_mgr_flags>
/dev/block/platform/msm_sdcc.1/by-name/system /system ext4 ro,barrier=1 wait
/dev/block/platform/msm_sdcc.1/by-name/userdata /data ext4 nosuid,nodev,barrier=1,noauto_da_alloc wait,check,encryptable=footer
/devices/msm_sdcc.1/mmc_host /storage/sdcard0 vfat nosuid,nodev wait,voldmanaged=internal_sdcard:25
/devices/msm_sdcc.2/mmc_host /storage/sdcard1 vfat nosuid,nodev wait,voldmanaged=external_sdcard:auto
#/dev/block/mmcblk0p11 /system ext4 ro,barrier=1 wait
#/dev/block/mmcblk0p12 /data ext4 nosuid,nodev,barrier=1,noauto_da_alloc wait,check,encryptable=footer
or the last thing i know is "the ADB method" > techgage.com/article/moving_your_non-movable_android_apps_to_an_sd_card/
but it seems a not working all the time... I'm also a bit afraid to completely mess up that new phone i don't really know in depth for now.....
Some advices???
try this:
Before
# Change to 1 for swapping SD cards
persist.sys.vold.switchexternal=0
After
# Change to 1 for swapping SD cards
persist.sys.vold.switchexternal=1
if it dont work you have to edit the void fstab:
http://forum.xda-developers.com/showthread.php?t=2229848
btw: forum search is the box on the upper right
hey there helpful guys,
i rooted my phone (got rec.clockwork), flashed my old aceS8530 with StockLite v8 (incl. kernel), and wanted to swap the mem.
i had a bad browser tool, so i could just overwrite the old vold.fstab with the new (bad) one - so the old (good) is gone to nowhere...
think if i replace the correct code, it'll work again.
now i got a better explorer (root browser) with which i can write.
tried nearly everything: repair the code by myself, wipe dalvik/cache/data - nothing ever happened.
problem: cause of no SDrecognising, kies nor PCconnection doesnt work, i cant put anything on SD, cant get any data from mail - except the message.
i'd like you to give me the original vold-fstab for my ace:
model: GT-S5830
android: 2.3.6
baseband: S5830XWKT8
kernel: 2.6.35.7-perf-CL562111
build: StockLite v8
i hope you can help me, so i did not absolutely destroyed my good old ace of spades:fingers-crossed:
You could try flashing stock via Odin
Sent from my GT-S5830 using xda app-developers app
is it not possible to just replace the obviously wrong codelines of vold.fstab with the origin?
thanks for the odin way - gonna get everything ready for this, but i like my current stocklite and everything but this sd-prob...
got the correct odin version for my gts8530 (v4.42), put the original firmware from sammobile into odins "one package"place (odin checked and said "ok"), connected the phone in download-mode and startet. got the "an unnamed file was not found"error...
original vold.fstab for gts5830
Could anyone please give me the original vold.fstab - file for my samsung galaxy ace gts5830?
Would be propper help:victory:
Maybe you can find the vold.fstab into the rom package you download from sammobile. Did you try?
:laugh:yeah
I got my file!
Thanks a lot for this idea melting snowman:good:
It was quite a lot of work to get it - but it's propper done - absolutely great:victory:
Now, that I have my original, I can try to swap the memory without that imense risk
rubic0rn said:
:laugh:yeah
I got my file!
Thanks a lot for this idea melting snowman:good:
It was quite a lot of work to get it - but it's propper done - absolutely great:victory:
Now, that I have my original, I can try to swap the memory without that imense risk
Click to expand...
Click to collapse
I'm super glad you finally restore your phone
rubic0rn said:
:laugh:yeah
I got my file!
Thanks a lot for this idea melting snowman:good:
It was quite a lot of work to get it - but it's propper done - absolutely great:victory:
Now, that I have my original, I can try to swap the memory without that imense risk
Click to expand...
Click to collapse
hi man,
can i have that file what u entered please...
Thanks in Advance...
Sathish
vold.fstab - origin
hey, turned my samsung 'nto LG :victory:
crumbled through my old files again and think i found it again (following text from the original vold.fstab):
# Copyright (c) 2010, Code Aurora Forum. All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are
# met:
# * Redistributions of source code must retain the above copyright
# notice, this list of conditions and the following disclaimer.
# * Redistributions in binary form must reproduce the above
# copyright notice, this list of conditions and the following
# disclaimer in the documentation and/or other materials provided
# with the distribution.
# * Neither the name of Code Aurora Forum, Inc. nor the names of its
# contributors may be used to endorse or promote products derived
# from this software without specific prior written permission.
#
# THIS SOFTWARE IS PROVIDED "AS IS" AND ANY EXPRESS OR IMPLIED
# WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
# MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT
# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS
# BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
# BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
# WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
# OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN
# IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
dev_mount sdcard /mnt/sdcard auto /devices/platform/msm_sdcc.1/mmc_host
the last line is the only thing to care 'bout
happy success :fingers-crossed: