Help missing 13gb data - nexus 7 - Nexus 7 Q&A, Help & Troubleshooting

Okay so i was just doing a bit of file management. I removed a 1.4gb psp iso i had on my nexus 7 and then i checked how much space i had left using storage option in settings. I checked it and it said i had 25gb free when before i removed my file i had only 13gb free. Tried rebooting device and then used es file explorer to see all files. Opened es file explorer and then noticed everything was gone. Only stock items were folders were left eg Android, Download etc. All my msuic and some game data was gone. Opened up asphalt 7 to see if it would still work but it doesnt anymore. Tried opening real racing 3 And it asks me to redownload game data. My widgets are still in homescreen and work and some of the other apps i have still work as well eg plague inc, subway surfer and most of the other ones.
Any idea on how this happened and how i can recover my files? I have a bugsense file as well that was left on my device.

As to recovery of lost files your options are not good. (And if we're talking a non-rooted device, the odds are approximately equal to 0%) Recovery in ext4 filesystems is technically much more challenging than in simple filesystems such as FAT. And this pessimistic outlook presumes that the filesystem is healthy/clean. If the reason for the problem occurring in the first place was a corrupted filesystem, then the odds go from simply bad to pathetically poor.
Sorry, dude... got any Nandroid or TiBu backups stored on your PC?
If you had Putin's top-secret files on your N7 and the CIA got hold of it, the first thing a forensic analyst would do is try to take a raw (block) device dump off of the "cold" device. (If you are still running the N7 with the regular OS the /data partition is being continually written to, and this further reduces the chances of file recovery every second the device is booted).
In the case of an analyst with less resources, this might mean using a custom recovery boot to get the raw device copy; unfortunately, the /data partition is huge - nearly 30 GB - so you would have to mount a extN filesystem via OTG... and doing so thus precludes using adb, so you would need to use a recovery with a touch interface and command-line entry (e.g. TWRP)
# mkdir /mnt/myOTGdisk
# mount -t ext2 -o rw /dev/sda1 /mnt/myOTGdisk/
# dd bs=8196 if=/dev/block/platform/sdhci-tegra.3/by-name/UDA of=/mnt/myOTGdisk/userdata.img
Doing such a thing would allow you to examine that huge image file with forensic file recovery tools from a PC (probably running Linux) as in principle you captured the entire ext4 filesystem.
The thing is, efforts spent in file recovery should be proportional to the value of the files being recovered. I'm not sure if your saved gaming history rises to that occasion. For sure the dude at the CIA won't want to help you with that.
As to the source of your troubles, it's hard to say. With TWRP booted, you can run the "e2fsck" program to see if the /data ext4 filesystem is corrupted, e.g.
# mount | grep /data ( see which mmcblk0 partition is /data, on grouper it is mmcblk0p9 )
# umount /sdcard
# umount /data
# e2fsck -f -n /dev/block/platform/sdhci-tegra.3/by-name/UDA
(For the last command above, you might need to use the block device name /dev/block/mmcblk0p?? instead of the UDA symlink )
If the above command shows that you have a corrupted /data filesystem, I would re-initialize that filesystem ( "fastboot format userdata" ) - note this wipes all userdata including the psuedo-SD card.
Finally, I should point out that some type of hardware failure might have occurred somewhere in that huge 30 GB partition - if that is the case then there will be problems down the road again. If that is the case, the only way to detect this will be a write test which nearly fills that partition, followed by a filesystem sanity check as shown above.
Probably that would need to be done in the recovery rather than in the normal OS, as a nearly full /data filesystem will probably wedge the device.
Phew, I've said enough.
Good luck

I never tire of reading your posts, bftb0, ("...the odds are approximately equal to 0%")...genius.
But don't the CIA have access to Cray, 'Kasparov' DeepBlue beating SuperComputers that could make mincemeat out of the kind of thing your alluding to... in less time than it takes to flash a ROM... or have I been watching too many James Bond movies?
Vaguely rhetorical question - think I already know the answer...
Still... what a great post.
Rgrds,
Ged.
---------- Post added at 01:22 AM ---------- Previous post was at 12:50 AM ----------
Hi, leont1280...
You could try running this ...
Disk Usage - http://play.google.com/store/apps/details?id=com.google.android.diskusage&hl=en
It gives a graphical 'map' or overview of your storage, and you can visually see where everything is (or should be), great for tracking down missing stuff... but as bftb0 has mentioned, it doesn't look promising.
Rgrds,
Ged.

Use astro file manager u can check it out
Sent from my Nexus 7 using Tapatalk 2

Right bftb0 i did what you said in twrp and i recieved the following summary information.
/dev/block/mmcblk0p10: 28133/1835008 files (3.2% non-contiguous) , 1571673/733977
Any idea on what that means?
Also under the mount option in Twrp i can Unmount and mount the System, Data and its Cache. However i cant Mount the SD Card. Should that be a concern?

bftb0 said:
As to recovery of lost files your options are not good. (And if we're talking a non-rooted device, the odds are approximately equal to 0%) Recovery in ext4 filesystems is technically much more challenging than in simple filesystems such as FAT. And this pessimistic outlook presumes that the filesystem is healthy/clean. If the reason for the problem occurring in the first place was a corrupted filesystem, then the odds go from simply bad to pathetically poor.
Sorry, dude... got any Nandroid or TiBu backups stored on your PC?
If you had Putin's top-secret files on your N7 and the CIA got hold of it, the first thing a forensic analyst would do is try to take a raw (block) device dump off of the "cold" device. (If you are still running the N7 with the regular OS the /data partition is being continually written to, and this further reduces the chances of file recovery every second the device is booted).
In the case of an analyst with less resources, this might mean using a custom recovery boot to get the raw device copy; unfortunately, the /data partition is huge - nearly 30 GB - so you would have to mount a extN filesystem via OTG... and doing so thus precludes using adb, so you would need to use a recovery with a touch interface and command-line entry (e.g. TWRP)
# mkdir /mnt/myOTGdisk
# mount -t ext2 -o rw /dev/sda1 /mnt/myOTGdisk/
# dd bs=8196 if=/dev/block/platform/sdhci-tegra.3/by-name/UDA of=/mnt/myOTGdisk/userdata.img
Doing such a thing would allow you to examine that huge image file with forensic file recovery tools from a PC (probably running Linux) as in principle you captured the entire ext4 filesystem.
The thing is, efforts spent in file recovery should be proportional to the value of the files being recovered. I'm not sure if your saved gaming history rises to that occasion. For sure the dude at the CIA won't want to help you with that.
As to the source of your troubles, it's hard to say. With TWRP booted, you can run the "e2fsck" program to see if the /data ext4 filesystem is corrupted, e.g.
# mount | grep /data ( see which mmcblk0 partition is /data, on grouper it is mmcblk0p9 )
# umount /sdcard
# umount /data
# e2fsck -f -n /dev/block/platform/sdhci-tegra.3/by-name/UDA
(For the last command above, you might need to use the block device name /dev/block/mmcblk0p?? instead of the UDA symlink )
If the above command shows that you have a corrupted /data filesystem, I would re-initialize that filesystem ( "fastboot format userdata" ) - note this wipes all userdata including the psuedo-SD card.
Finally, I should point out that some type of hardware failure might have occurred somewhere in that huge 30 GB partition - if that is the case then there will be problems down the road again. If that is the case, the only way to detect this will be a write test which nearly fills that partition, followed by a filesystem sanity check as shown above.
Probably that would need to be done in the recovery rather than in the normal OS, as a nearly full /data filesystem will probably wedge the device.
Phew, I've said enough.
Good luck
Click to expand...
Click to collapse
Right bftb0 i did what you said in twrp and i recieved the following summary information.
/dev/block/mmcblk0p10: 28133/1835008 files (3.2% non-contiguous) , 1571673/733977
Any idea on what that means?
Also under the mount option in Twrp i can Unmount and mount the System, Data and its Cache. However i cant Mount the SD Card. Should that be a concern?

leont1280 said:
Right bftb0 i did what you said in twrp and i recieved the following summary information.
/dev/block/mmcblk0p10: 28133/1835008 files (3.2% non-contiguous) , 1571673/733977
Click to expand...
Click to collapse
Hmmm, mmcblk0p10 - you must have a tilapia (3G N7) device, yes?
If you had any filesystem errors, that e2fsck run would have produced copious reams of output. If a filesystem is clean, it produces only 5 or 6 lines of summary output.
leont1280 said:
Any idea on what that means?
Also under the mount option in Twrp i can Unmount and mount the System, Data and its Cache. However i cant Mount the SD Card. Should that be a concern?
Click to expand...
Click to collapse
I've seen the same business with TWRP and the /sdcard mount - I wouldn't worry about it. (It is not a "normal" mount in the sense of extN or FAT device partition mount - it behaves sort of like a strange symlink where the target directory and descendants all appear to have different file ownership and permissions than what exist in the true (underlying) filesystem. No doubt this is all performed in the kernel... I don't know whether a command-line invocation of "mount" can create this mount point, or whether a specific syscall/ ioctl is needed)
But back to your N7 - the lack of any errors in the filesystem check is good news, but also suggests that your files didn't disappear through a hardware failure. Are you sure you didn't fat-finger things when using the file manager? (I suppose it is possible that the file manager has a bug...)
I didn't look into what tools are available for extN forensic/recovery work. I can guess that the effort would be non-trivial, though.

bftb0 said:
Hmmm, mmcblk0p10 - you must have a tilapia (3G N7) device, yes?
If you had any filesystem errors, that e2fsck run would have produced copious reams of output. If a filesystem is clean, it produces only 5 or 6 lines of summary output.
I've seen the same business with TWRP and the /sdcard mount - I wouldn't worry about it. (It is not a "normal" mount in the sense of extN or FAT device partition mount - it behaves sort of like a strange symlink where the target directory and descendants all appear to have different file ownership and permissions than what exist in the true (underlying) filesystem. No doubt this is all performed in the kernel... I don't know whether a command-line invocation of "mount" can create this mount point, or whether a specific syscall/ ioctl is needed)
But back to your N7 - the lack of any errors in the filesystem check is good news, but also suggests that your files didn't disappear through a hardware failure. Are you sure you didn't fat-finger things when using the file manager? (I suppose it is possible that the file manager has a bug...)
I didn't look into what tools are available for extN forensic/recovery work. I can guess that the effort would be non-trivial, though.
Click to expand...
Click to collapse
Im pretty sure i didnt accidently delete it myself. When i was doing file management i was using my laptop with the N7 3g connected to it via MTP. Once i deleted the iso file the N7 started acting strange. I did notice a bit of lag that was usually out lf the ordinary and when i checked available space left it increased to 25gb rather than saying 13gb

aaah, having the same problem here, i was cleaning my n7 using my laptop, found a strange folder on my sd card, looked inside and it has a back up of some of my deleted files! interesting! i deleted the folder, then i started cheking other folders, like my ebooks, audio books and etc, but all my folders were empty!
so i disconnected my tablet, and after reconnecting, bam, all files gone.

Related

Booting Android from sd card on Dream/G1

Hi all,
Here are my findings about how to boot android from an SD card, useful for example to test development Android builds without messing your phone. This procedure was inspired by legacy GNU/Linux boot process and then should work on most hardware with a flashable recovery.
########################################
I can't stress enough the fact that this procedure is targeted to experienced user. A good knowledge of linux/android booting process is more than required. This procedure is not meant to be useful to most people given its limitations (no recovery mode, rebuild of boot.img required)
########################################
I won't propose a step by step tutorial as it's better to understand how to do it and adapt the procedure to each need.
Two modifications are required:
1. Declare to mount sd card partitions instead of internal flash volumes. This has to be done in the init.rc script.
For example:
mount yaffs2 [email protected] /system
mount yaffs2 [email protected] /system ro remount
with
mount ext2 /dev/block/mmcblk0p6 /system
2. For some reasons, in the boot process, sd card partitions generally show up later than the mount actions, so it is generally necessary to add a timer in init binary to give to to the kernel to detect sd card partitions before mounting them (adding a sleep(5) after the "A N D R O I D" text in init.c is enough).
Build your special boot.img embedding those two modifications and flash it on the recovery volume of your phone. Now, booting into recovery will launch the system on your sd.
Regards,
I would like to report success on booting the G1 from a system located on sd card (cyanogenmod 4.2.7.1). I will describe the procedure step by steps when every thing is okay.
There is just an issue that you might have encountered during cyanogenmod ROM cooking, all wireless connexions (wifi, BT, GSM) do not work. The same system on flash if okay. I made a diff on boot log messages and the only notable difference is this error :
E/MemoryHeapBase( 83): error opening /dev/pmem_gpu0: Permission denied
E/MemoryHeapBase( 83): error opening /dev/pmem_gpu1: Permission denied
E/MemoryHeapBase( 83): error opening /dev/hw3d: Permission denied
I tried to chmod 0555 /dev/pmem* with no success.... Any idea ?
Although I finally managed to have a usable system, this work is still experimental. Please fell free to test and report success, failures here so I can improve the thing.
Let's see how we can boot a copy of cyanogen ROM 4.2.7.1 located on sd card. The main purpose is to test future ROMs (eclair ?) without messing up your phone...
DISCLAIMER : This procedure is targeted to experienced user. I am not responsible if you loose your data, your phone or your Mom !
Prerequisites are :
- adb and fastboot operationnal on your host computer
- Boot image file boot.img :
http://www28.zippyshare.com/v/19654421/file.html
- files data.cpio.gz, system.cpio.gz (data.cpio.gz and system.cpio.gz are unmodified images of a fresh install of cyanogen ROM that fit the modified boot.img) from :
http://www15.zippyshare.com/v/57489279/file.html
http://www15.zippyshare.com/v/13077582/file.html
1.
Create 3 partitions on sd card. The first one (vfat) is to store your music, videos etc. The second and the third will hold /data and /system. Result shoul look like this :
# fdisk /dev/block/mmcblk0
Command (m for help): p
Disk /dev/block/mmcblk0: 1977 MB, 1977614336 bytes
64 heads, 63 sectors/track, 957 cylinders
Units = cylinders of 4032 * 512 = 2064384 bytes
Device Boot Start End Blocks Id System
/dev/block/mmcblk0p1 1 864 1741792+ c Win95 FAT32 (LBA)
/dev/block/mmcblk0p2 865 903 78624 83 Linux
/dev/block/mmcblk0p3 904 957 108864 83 Linux
Command (m for help):
2.
Copy data.cpio and system.cpio on the first partition of your sd card.
3.
Connect to your device with adb :
adb shell
4.
Mount mmcblk0p2 on temporary folder and extract user.cpio.gz archive :
mkdir /dev/tmp
mount /dev/block/mmcblk0p2 /dev/tmp
cd /dev/tmp
gunzip -c /sdcard/data.cpio.gz | cpio -i
cd /
umount /dev/tmp
5.
Mount mmcblk0p3 on temporary folder and extract system.cpio.gz archive :
mount /dev/block/mmcblk0p3 /dev/tmp
cd /dev/tmp
gunzip -c /sdcard/system.cpio.gz | cpio -i
cd /
umount /dev/tmp
6.
Reboot the phone in bootloader :
adb reboot bootloader
7.
Boot the phone with custom boot image :
unzip boot.img.zip
fastboot boot boot.img
Reports are welcome !
I haven't tried this, but great idea. Well done.
Maybe a nice additional idea would be a boot-menu style idea. Eg, detect OS on mem card and display a menu of "Internal" or "SD Card"?
I'm on it but as it will imply flashing people's phone, I need more testing and suggestions from experienced hackers. I only own my G1 for 5 days...
I acytually just started a thread about this in the Dream development subforum!
Some suggestions:
-Use a recovery image to boot the ROM on the sd card (look at modifying the CM recovery image) if this is possible. This way, you can boot from sd card when you want to, by booting into recovery image, without interfering with the flashed rom at all. No worries that flashin a new rom will require a reflash of your bootloader. Also, you can use the ROM installed in flash after a reboot without any hassle, which would be very useful when testing a ROM from the SD if it doesn't work very well and you need a working phone.
-Have the /data and /system-partition as folders on the 4th partition on the SD card, or as logical volumes on a primary one. Why?
Well, many people have their sd-cards set up with fat, extX, swap in that order. The partition layout you have described here simply isn't compatible with that, and will require a separate SD card just for this testing (which everyone might not have).
I must say, I think this is a GREAT idea! I so often want to test a few ROMS, but often they don't get the test-time they deserve because I need to swicth back to my working environment for job/uni the day after. This would be a great way to test a ROM thoroughly. And also it would be the best way to give a ROM a quick testdrive. switchroming back and forth is, for all its simplicity, hassle.
Using the recovery is the only way I found at the moment to boot from the sd card and was about to extend cm recovery with a dedicated menu Nevertheless, there will be a limitation with that: it will not be possible to use a different kernel for the system on sd as it will have to use the kernel of the recovery... Anyway, many custom roms around here use cm kernel (even those I saw with eclair) so it is not so problematic I think (tested Eugene373 AOSP20 yesterday). Anyway, it is possible to adapt the recovery with a test kernel...
I think I found a workaround for sd partitionning scheme pb, using bind mounts but I have not tested already. I will work on it this WE.
If I remember correctly you can use the command "reboot recovery" from the recovery shell to reboot again into recovery. It could mean that it is possible to choose what (kernel) to boot after the reboot. Even cyanogenmod has made quite a few changes to the kernel since the recovery image came out, and I think it would not be a very good solution to use the same kernel as the recovery image for all ROMs loaded via SD. (Especially the Hero ones won't work at all, I'm afraid.
It could also be possible maybe, to tweak the built-in bootloader into booting form either SD-card or from the internal flash? It already has the possibility to boot different things on different keypresses (home for recovery mode, and camera for fastboot). I have (again) no idea of its capabilities for reading anything off of the sd card, though.
I get your point naguz . I am not satisfied either with the solution of using the recovery kernel to boot the system on sd. I found that it adds quite much complexity to the init process: I tweaked the recovery executable to add an entry to boot from sd but I faced troubles in services startup and pre-init definitions. I think that the solution of using the recovery menu to choose to boot from sd have to be abandoned as it will require heavy additional changes to the init.rc scripts of the second system and will break its advanced features.
The ideal solution (as you suggested) would be to tweak the bootloader to boot natively from the sd card but unfortunately, we do not have the sources of the SPL (tell me if I am wrong) so it is definitely not possible.
The remaining solution is to use the recovery partition to flash the boot image of the second system. I works well, just press the home key and the second system boots ! The drawback is that you do not have recovery any more... Personnaly, I don't find that so problematic as I is still possible to boot a recovery image with fastboot when needed, so I think I will stick to this solution. I somebody have another solution, I am ok to investigate...
Aha, it makes sense that booting the sd directly from recovery mode would mess something up. I would think some of the same problems would be faced when booting the kernel from the recovery partiotion, doesn't it look like a different device to the kernel? Well, if it works, it works.
Regarding the source of the SPL, I have no idea, but I know hyakuro (a (former?) user here) has released a modified one. Trying to get in touch with him
As for the latest method: Is the recovery partiotion big enough to hold both the recovery image AND the kernel? If so, one could maybe have both. Maybe make a new "recovery image" that can either boot from sd or boot recovery image? Just throwing out ideas here.
Personally I don't see the big problem with not having a recovery image, as I would (in a dual-boot scenario) already have another, working install on the flash that I could use if the one booted from sd wasn't good enough. Re-flashing the recovery image could also be done from the working ROM in flash, for those without the SDK tools.
I think, however, that quite a few people will object to not having a recovery image.
Btw, was your latest working test done with one (4th) partition on the sd card for loading the ROM from SD? If so, new instructions please. I'd like to give it a try.
I think that it is technically impossible to boot directly from the sd, even with the sources of the SPL as drivers are required to drive the sd that can not be included in a SPL. It is the same issue on PC with PCMCIA network cards for instance. IPL+SPL has to be seen more or less like a simple BIOS...
The recovery partition size is not a matter her. The problem is the lack of control over what has to be booted as the only action we can make in the SPL is the HOME key to choose a regular boot or a recovery boot (the system on SD here). I think I have a good knowledge now of the boot process and I think we can not got further than that, despitely...
I am now trying to have /data and /system on the same partition, mount them on /mnt and bind mount each directory on /system and /data but with no succes . investigating....
Okay, bind mounting was a dumb idea of mine. The solution is to create an extended partition with 2 logical drives in it, so partitions are:
[1-3] FAT and/or EXTX and/or swap as needed (I have personnaly just one partition here)
4 extended
5 ext2 for /data
6 ext2 for /system
Now its time to bake a boot.img with the kernel of the system on the sd card + the ramdisk. I do not explain how to do that, google knows :
1.
In the ramdisk image, put my modified init program attached hereater
2.
In the init.rc script, change the lines that mount /data and /system :
mount yaffs2 [email protected] /system
mount yaffs2 [email protected] /system ro remount
with
mount ext2 /dev/block/mmcblk0p6 /system
and
mount yaffs2 [email protected] /data nosuid nodev
with
mount ext2 /dev/block/mmcblk0p5 /data
Flash boot.img on the recovery and reboot in recovery... That's all.
Jahrome,
Trying the idea on the HTC has a subtle difference. So I'm curious what change you put in the /init process.
Lets say the image one wants to use is the 'eclair' branch. This branch uses vold, so the block device, such as '/dev/block/mmcblk0p#', does not appear to be created until the vold service is started, which is after the init.rc mount operations. So the mount proposed does not work.
Curious what changes you made to the init process that might give me some ideas of what might be the simplest change. It seems that there is a relatively easy solution, that I don't yet see.
Ideas (or additional questions to clarrify) appreciated...
Hi Dale !
On which HTC are you trying the trick ?
First your trouble is not related to eclair as I successfully booted eclair on my G1 with this trick. You need to add a timeout in init so as it waits for the kernel to detect sd card partitions (need to recompile init, or use my recompiled init).
Vold has nothing to do at this point
Hope this helps
Init Delay for SDisk
Thanks for the reply. That's what I needed, it seems so ungraceful.
I thought vold was enabling something to make the kernel's discovery of the SD partitions. It is "by coincidence" that the log of the vold occured shortly before the adding of the block-device event. My apologies for not recognizing the coincidence of the log entries.
I had hoped the solution was a bit more "graceful", though I can't say what that would be or why a sleep is "ungraceful". I would like a "mount retry for n-seconds" option in the init.rc, that would be slick. Nonetheless I will add in a sleep-spin-check for a few seconds.
For the record, we are discussing the change to:
android-source: .../system/core/init/init.c
code-routine: main()
code-location: Somewhere after the "A N D R O I D" text
code-change: add in a sleep spin-check of some sort
I appreciate the comment that all we need is just a sleep. I think this completes the thread?!
Most interesting...
This is something akin to how I am using my company's Android solution for the Beagle Board...
In that environment, the entire kernel and rootfs are located on a SD/MMC card. The environment variables and boot script are stored in the NAND chip
through a "setenv" command. The U-boot monitor on the hardware defaults to run the boot script unless there is any user interaction. This image can then be converted into a typical distribution that can be flashed and ran without the SD card...
I have wondered about the implementation of this approach on my G1, but I have not had time to test it out. It is good to see that there are others that are interested in this as well...
I will be following this thread and will try to help in any way if I can... meaning if I can get some free time...
If you are interested in our Beagle Board solution, it is open source and can be found by a simple Google search using "Android rowboat"...
L8R...
very easy fix.
rename the /init to /init.android (or whatever you like)
create an init script. have it prompt on boot too boot from sd or internal. symlink the init.rc from /system. That way you only need one boot.img for multiple builds. We've been doing this a really long time on the android on vogue project. My development phone is simple, I hold down the menu button if I want to boot from the sdcard otherwise it boots from the internal.
Oh and don't worry about this.
jahrome said:
log messages and the only notable difference is this error :
E/MemoryHeapBase( 83): error opening /dev/pmem_gpu0: Permission denied
E/MemoryHeapBase( 83): error opening /dev/pmem_gpu1: Permission denied
E/MemoryHeapBase( 83): error opening /dev/hw3d: Permission denied
Click to expand...
Click to collapse
That's just that you don't have HW3D enabled in your kernel. It's important to note that if you're trying to use multiple builds that eclair with 3d and donut use different kernels.
Exactly the vogue and kaiser have been doing this for ages. If you want you can also boot ext2 and squashfs images. It's pretty simple stuff.
Anyone have a backup of the files in post #3? I've been trying this solution with files of my own creation (as in: my own cooked boot.img, and data/system files) but it doesn't seem to get past the G1 boot screen (as in: blank screen.) I've also tried the recovery boot solution however it gives me the same reaction. It leads me to believe the problem lies in my boot file.
ok anyone interested in creating a simple step by step manual? and can someone post the files again please?

(Q) A2SD: anyone interested in helping get a2sd to work.

I was just curious if anyone would be interested in making a step in the right direction dog such a new device. I have worked with a2sd on several other android phones(most of which already had froyo ported). I also have some experience in porting Roms to other devices. If anyone else that has already bought a flipside, and at least a pretty decent understanding on how the OS works and how to stuff like that. Also... it would be a huge plus if someone has experience in building Roms, as well as dumping them from our devices.
I'm planning on starting off with a clean and fast ROM for our phones... and hopefully with a2sd built in as well, or at least installable.
If you are interested then send me a PM and we can get to work... the sooner the better!
Looking at /proc/filesystems it seems that the stock kernel only has support for yaffs2 and vfat. The stock image doesn't include any .ko files so I'm assuming all of the needed functionality is compiled into the kernel with no support for external module loading.
Using Busybox 1.18 from the Market I can loop mount vfat images without any problem (I had partitioned my SD card under Linux but it seems that init and motobox are hard-coded to load mmcblk0p1 at /sdcard and then it kept unmounting /sdcard randomly when I had extra partitions after it... so loop-mounting is safer without breaking things).
The problem is of course permissions since vfat doesn't support ugo-style permissions. We can't loop mount yaffs2 images since the emulated block device is not NAND flash... and that's also the reason we can't just dd a yaffs2 filesystem into a partition on the SD card.
I'm going to experiment with init.rc a bit and see if I break anything by forcing it to mount /sdcard immediately after /system (because that's where it should be mounting /data). I don't want to run the risk of loop mounting a file from /sdcard onto /data only to have it forcibly unmounted when vold gets enumerated and remounts /sdcard.
It's really unfortunate that there's so little space on the internal memory of this device... /cache is ~140 Mb, /system is ~180 Mb, and /data is ~160 Mb, so even if we were to lean out /system and swap it around with the others, we only get 20 Mb more on /data... that's way too much work for such little gain.
OT - Why is there so much hatred against this device? It's more than fast enough to play Quake 3 and I'd trade all the screen real estate in the world for a hardware keyboard... oh, and the phone actually fits in my pocket (unlike my friend's Droid X which is so huge and unwieldy...). Anyway, I just think it's odd.
Update: It seems that the device checks that boot and recovery images are signed with a Motorola digital certificate at runtime... I can flash the partitions just fine, but it just boot-loops with "Error CC00 DBAD" and then eventually drops back to the bootloader. Unfortunately this means that I can't test any changes to mount points in init.rc at this time. Since I don't have any means to recover the device from a bad bootloader flash, this will have to be the end of the road for me at this time. Some other brave soul will have to experiment with replacing mbmloader or lbl to allow loading custom images signed with test certificates from the SDK.
EDIT: I should mention that I had to use sbf_flash to upload images since fastboot won't work until we have an unlocked bootloader on the device. I wish I had read up on and-developers.com before discovering all of this stuff the hard way. Oh well. Even the ramloader from the SBF image is signed with a Motorola digital certificate so I'm not sure that using sbf_flash (I haven't tried RDSlite, don't have Windows) is the way forward either. I don't think we can just dd the new images for the bootloader either since not all of the MTD partitions are exposed to the OS. This is going to be harder than I expected.
Init.rc executes /system/etc/install-recovery.sh as a privileged user. Lucky for us, this is at the end of the init script once everything is up and running and AT&T/Motorola have removed the file so we don't have to alter anything of value. I've tested it and adding install-recovery.sh will run commands as root. This is our way in.
Hopefully we can get apps stored on the SD card soon.
EDIT: The contents of this post are now deprecated and remain here for historical purposes only! Please see the posts below for the "proper" scripts.
So after playing with it some more, mounting a vfat filesystem on /data simply doesn't work because permissions and ownership can't be set. Even setting the most relaxed permissions possible I found bizarre side effects like apps won't install from the Market and wifi can't be toggled on/off. I found an ext2.ko compiled for the Milestone stock rom (I've attached it here for convenience, but I found it on android-hilfe.de) works just fine though, so now we can use a proper filesystem.
Right now I'm mounting a 512 MB ext2 filesystem onto /data and everything works great. The biggest problem I'm having though is that switching to USB Mass Storage mode forcibly unmounts my filesystem so that obviously causes problems, but I don't really see a way around this since UMS mode offers up the entire MMC device so there's no way to just pick one partition to expose...
I'm going to test more things to make sure nothing has broken before I post a full write up on this, but if you know what you're doing, it shouldn't be hard to figure it out on your own. I know most of the Apps2SD projects are using an application to manage data then setting up a separate partition on the SD card, but it usually relies on some custom recovery image and the goal for me is to do this against a stock rom. I'm also using a loop-mounted filesystem because it makes it easier to migrate to a new SD card without having to worry about partitions and what-not.
EDIT: Here's a quick-n-dirty version for those of you who would like to try it. This will show the proof of concept and let you see if it works for you without breaking anything major. All changes to /data will be undone on the next reboot. If you know what you're doing, then I would recommend making the changes permanent by mounting /data in install-recovery.sh. This is assuming you have rooted your phone (I used z4root) and have Busybox installed (I used 1.18 from the Market) and at least 512 MB free on your SD card.
Code:
adb push ext2.ko /sdcard
adb shell
su -
/system/bin/busybox mount -o rw,remount /system
/system/bin/busybox cp /sdcard/ext2.ko /system/lib/modules
/system/bin/busybox chown 0.0 /system/lib/modules/ext2.ko
/system/bin/busybox chmod 0644 /system/lib/modules/ext2.ko
/system/bin/busybox mount -o ro,remount /system
/system/bin/busybox insmod /system/lib/modules/ext2.ko
/system/bin/busybox dd if=/dev/zero of=/sdcard/userdata.ext2 bs=1M count=512
/system/bin/busybox losetup /dev/block/loop0 /sdcard/userdata.ext2
/system/bin/busybox mkfs.ext2 /dev/block/loop0
/system/bin/busybox mount -o rw,remount /
/system/bin/busybox mkdir /userdata
/system/bin/busybox mount /dev/block/loop0 /userdata
/system/bin/busybox chown 1000.1000 /userdata
/system/bin/busybox chmod 0771 /userdata
cd /data
/system/bin/busybox cp -r -f -H -p . /userdata
cd /
/system/bin/busybox umount /userdata
/system/bin/busybox rmdir /userdata
/system/bin/busybox mount -o ro,remount /
/system/bin/busybox umount -l /data
/system/bin/busybox mount /dev/block/loop0 /data -o rw,sync,nosuid,nodev,noatime,nodiratime
If you've done everything right, "lsmod" and "cat /proc/filesystems" will show "ext2", "mount" will show /dev/block/loop0 on /data, and "df" will show more space available on /data. You should also see the extra space in Settings -> SD card & phone storage -> Internal phone storage.
My install-recovery.sh currently looks like this:
Code:
#!/system/bin/sh
if [ -e /system/lib/modules/ext2.ko ] && [ "`/system/bin/busybox lsmod | /system/bin/busybox grep -c ext2`" -eq "0" ]
then
/system/bin/busybox insmod /system/lib/modules/ext2.ko
fi
# wait 30 seconds, /sdcard is being re-mounted by vold...
/system/bin/busybox sleep 30
if [ -s /sdcard/userdata.ext2 ] && [ "`/system/bin/busybox cat /proc/filesystems | /system/bin/busybox grep -c ext2`" -eq "1" ]
then
/system/bin/busybox losetup -d /dev/block/loop0
/system/bin/busybox losetup /dev/block/loop0 /sdcard/userdata.ext2
/system/bin/busybox umount -l /data
/system/bin/busybox mount /dev/block/loop0 /data -o rw,sync,nosuid,nodev,noatime,nodiratime
fi
You don't have to use this as-is, but it's at least a starting point.
UPDATE: Seems like we need a Busybox with a proper tune2fs utility as the one in the Market is pretty useless (only changes volume labels...). You'll want to run "tune2fs -c 0 -i 0 /dev/block/loop0" to disable mandatory fsck'ing, otherwise the kernel will reject the mount after a few times because it's dirty. Something funky is happening because any apps that I install once the image is mounted will not show up after reboot, but the files are there and they continue to take space. Maybe I'm breaking something with the lazy umount?
At the risk of sounding like I'm only talking to myself, I'll post another update...
I found that most of my troubles were stemming from waiting so long to remount /data, so I caved and put an ext2 partition on my SD card so that I don't have to wait 30 seconds before mounting over /data.
Oddly enough, mounting a native ext2 partition for /data from the SD card was actually MUCH slower than the loop mounted image. I should note that I'm not mounting the partition with the 'sync' option. I could get away with that on the loop device since it's just doing it in memory anyway and changes are only being written on the default commit interval for the host filesystem. Anyway, I'm using a 4 GB class 10 SD card, but it's still much slower than the internal flash. Just to confirm my results, I tried with a native ext2 partition on a 2 GB class 2 SD card... the phone took nearly 5 minutes finish booting to a responsive home screen!
But, at least I can mount /data right away when I'm using a physical partition... So I've done the best of both worlds by creating a ext2 partition on my SD card and then loop mounting an ext2 image onto /data. The result: I'm running my entire /data on a class 2 SD card and it's much faster than a native partition on a class 10! In fact, the difference in boot time compared to internal storage is only a few seconds! Now that I'm mounting /data right away I no longer have problems with missing apps or data after reboots. The only drawback is that you have to waste a bit of space to do it this way since the filesystem reserves 10% for itself, you need a 560 MB partition to hold a 512 MB image (in my case I'm actually running a 384 MB image since I don't really need that much space anyway). Personally, I don't mind since I'm running it off of a cheapo class 2 device and having everything in a single image file makes it super simple to migrate to a different SD card if I want to.
I'll keep running this setup for a couple days now to make sure that there's nothing else broken, but for right now I've got it setup just how I want it: no extra application to manage which apps are where and no random force closing from applications running off of SD card that weren't meant to be. Oh yeah, and I don't have to worry about dalvik-cache cannabilizing my internal storage either.
If anyone else is following along, I'd like to hear your experiences with this too. I'll post the final write-up once I'm certain that nothing else is broken.
I'm definitely following along appreciatively, but will have to wait for the step by step to give it a try.
Sent from my Liberty using Tapatalk
Well, here is the much-awaited write-up...
First, acknowledgements. This would not have been at all possible without the ext2 module provided by user Fnordi on android-hilfe.de. Unfortunately I can't read German so I have no idea if he actually compiled it for the Milestone or somebody else did, but I grabbed the file from his post about loading Debian Linux on the Milestone, so kudos to him and whomever else was involved. I also wouldn't have been able to write this up so neatly without the sdparted script by 51dusty. I had to make a few alterations because we're not running on CyanogenMod Recovery, but it's still mostly his work nonetheless. The parted and tune2fs binaries are from j_r0dd's Recovery image for the Motorola Backflip. Also, cheers to the folks on android-dls.com wiki, even though the information is mostly targeted at the G1 and ADP, it was still very good reading.
WARNING WARNING WARNING
I have not yet devised a way to migrate the SD card data back to internal storage! Once you've migrated /data to the SD card, anything new from that point forward will stay on the SD card. Additionally, I will not be providing support for anyone who deviates from the process outlined here. If you're clever enough to do it some other way, then you're clever enough to get out of trouble on your own. Do this at your own risk, I am not responsible for any harm or loss of data that may occur as a result of following this procedure. You have been warned!
WARNING WARNING WARNING
Requirements: Android SDK installed with working ADB, root access on your Motorola Flipside and Busybox 1.18 installed from the Market. There is plenty of information available on the forum on how to do these things so please don't post here asking how to root the phone. The assumption is that you know how to gain root access and that you're comfortable with ADB. If you're struggling with doing any of these things, then you should reconsider if you want to attempt this at all.
1. Backup your SD card and format it so that it's completely clean and has only a single, empty, FAT32 partition on it.
2. Grab the attached ZIP file and extract the files directly into the SD card (no sub-folders). Make sure these are the only files on there, everything else will be erased!
3. Set your phone's USB connection to "Charge Only".
4. Connect via ADB using "adb shell".
5. Now run the following:
Code:
su -
cp /sdcard/setup.sh /data/local
/data/local/setup.sh
6. The script will now setup a 512MB partition on your SD card with a 448MB image for /data. All of the other data on your SD card will be lost!
7. After the script is finished, restore any files that you backed up before to the FAT32 partition of your SD card.
8. Set your phone's USB connection to "Charge Only" and never change it again!
9. You should now have a lot more space for apps!
Please note that the phone will feel a little sluggish for a little bit after boot, but soon it will have everything buffered in memory and it will feel very smooth again.
Enjoy!
EDIT: I should mention, if you want to undo the changes, either shut down the phone and remove the SD card or delete /system/etc/install-recovery.sh. Either way, the phone will revert back to internal storage automatically on the next boot.
EDIT 2: I noticed that the Market install of Busybox doesn't link any existing commands, only new ones. I've been using the 1.18 binary from the Market but I had used my own script to link everything properly (mostly to replace "sh" since no tab completion was killing me!). I've now included the install script in the zip. So install the Busybox 1.18 from the Market, then run my install-busybox.sh, then reboot and follow the instructions above. Sorry for the mix-up!
Alright, just making sure. You're last Edit:, you said that we have to run your "install busy-box.sh". To run it, is it in the script in your post above, or is there some other way? I'm pretty new to runnin' all these scripts since I'm on a Captivate which is far easier than this (I'm doin' this for my girlfriends Flipside).
Just in general, what are the steps you run your install busy-box?
Thanks ahead of time.
thank!!!!!!!
can anybody help me do this because when i do it at the bottom it says failed
You leave it on "Charge Only" because otherwise it will unmount the /data image and cause it to crash.
This was stated previously in my posts. Please read carefully next time.
ErebusRaze said:
Just in general, what are the steps you run your install busy-box?
Click to expand...
Click to collapse
1. Install Android SDK on your computer.
2. Hook up via ADB and install z4root.
3. Run z4root on your phone. It will root the phone and reboot.
4. Install Busybox from the Market.
5. Copy the contents of the zip file to your SD card.
6. Log in as root via ADB ("adb shell" then "su -").
7. busybox mount -o rw,remount /system
8. cp /sdcard/install-busybox.sh /data/local
9. busybox sh /data/local/install-busybox.sh
10. reboot
11. Log in as root via ADB ("adb shell" then "su -").
12. ls -la /
If everything is done properly, the last step should result in an expanded directory listing in a color terminal. You can now proceed with the rest of the tutorial.
ok after i reboot i got look at my phone storage and it is still the same it didnt increase or anything
the method you've presented here sounds interesting, but i'd really hate to lose the memory card access function of my phone (i use it quite often...very often in fact). so i have a question or two:
would it be possible to get a bigger sdcard(say a 4GB or 8GB sdcard), and dd my current sdcard's partition to the new card, and then create another partition on the rest of the new card and have this method utilize that new partition in the manner described here? would the entire sdcard still get unmounted if i set the phone to memory card access?
<edit>: never mind...it seems this question would be answered by: "The script will now setup a 512MB partition on your SD card with a 448MB image for /data".....so apparently yes the sdcard would still be unmounted :/
igetsosickofregistering said:
the method you've presented here sounds interesting, but i'd really hate to lose the memory card access function of my phone (i use it quite often...very often in fact). so i have a question or two:
would it be possible to get a bigger sdcard(say a 4GB or 8GB sdcard), and dd my current sdcard's partition to the new card, and then create another partition on the rest of the new card and have this method utilize that new partition in the manner described here? would the entire sdcard still get unmounted if i set the phone to memory card access?
<edit>: never mind...it seems this question would be answered by: "The script will now setup a 512MB partition on your SD card with a 448MB image for /data".....so apparently yes the sdcard would still be unmounted :/
Click to expand...
Click to collapse
why would you even bother?...
search: link2sd
nuff said
I backed up my sdcard and copied the files over. I have busybox and it is rooted.
I accessed superuser and copied the files over per the write-up.
When I ran setup.sh, it gave me the following error:
----
busybox found.
Usage: mount [-r] [-w] [-o options] [-t type] device directory
grep: not found
:bad numbergrep: not found
:bad numbermodule insertion failed, aborting!
rm failed for /system/lib/modules/ext2.ko, Read-only file system
Usage: mount [-r] [-w] [-o options] [-t type] device directory
----
I understand that it is a read only error, but not sure how to edit the script (or if I even need to) to get it to work. It looks like the first line of the script remounts the system properties to -rw, but it still failed to write.

External card as ext2?

Can I have external card mounted as ext2? I have files names not supported by fat and sync'ed with dropbox
Yes, you can but afaik there is no easy way to do this.
I formatted my sdcard to ext2 (because I wanted to put large file (image for wikipedia offline) on my sdcard).
I formatted the beginning (~30MB) of my sdcard to fat32 so that the Nook detect the sdcard and does not trigger an error and the remaining part to ext2.
Then I used a script that mount manually the ext2 partition to /sdcard on boot.
This generally works but I have sometimes a few bug in some applications, especially when I connect and disconnect my Nook to my computer...
The best solution would be to find a way so that Android can automount a ext2 partition by itself but I don't know how to do it.
Instead of using the whole card I partitioned the first 4gb as fat16 (msdos) and then set the rest to ext3. When the fat16 space runs out I'll look into making some sort of script to try to mount the second partition. At the moment with the card acts like a normal 4gb card.
is it possible to repartition the nook to be able to use the space that b&n reserves for its contents? I heard that the space for our files is just 250 mb.
user4242 said:
is it possible to repartition the nook to be able to use the space that b&n reserves for its contents? I heard that the space for our files is just 250 mb.
Click to expand...
Click to collapse
yes of course. If you're used to linux repartitioning and the dd command then it's a breeze. If you're a Windows user who've never done partitioning or disk imaging then you can easily mess up.
I'll assume the former.
It's just a case of:
boot with a noogie.img that you've written to a sdcard (root of card, not partition 1)
then plug it in
now you can see all the nook partitions like it's an external USB drive and fdisk, cfdisk, partitionmagic or whatever you want
Obviously you're gonna want to backup first because if you mess up the only way to restore would be asking one of us off this forum to break the distribution laws and send you a 2gb (or whatever it is) image.
All the details on this forum
Has someone tried editing /system/etc/vold.conf to get a ext-formated SD-Card mounted?
mali100 said:
Has someone tried editing /system/etc/vold.conf to get a ext-formated SD-Card mounted?
Click to expand...
Click to collapse
I checked, I had modified it adding a line "partition 2" in the section "volume_sdcard2" so that Android does not show the message "SD card blank or has unsupported filesystem".
But I couldn't make it mount a ext2 sdcard itself. (if you know how to do it without using another script, I'm interested)
Time to resurrect this thread.
FAT is ugly. File timestamps are in local time (whatever that means, summer? winter?).
The Nook vfat implementation has problems with caching in and out directory info on vfat
and intermittently changes all the modify timestamps by 1, 4 or 5 hours.
This can play havoc if you are trying to keep things synchronized by filetime.
I've decided to have my SD card be ext3
Our volume demon, /system/bin/vold (which is ancient) uses /system/etc/vold.conf to configure automounting.
It presumes that all volumes are vfat.
It seems from a brief look inside that it does handle ext2 and ext3 somehow.
There is also the question of getting it to automount USB drives.
The easiest solution to ext3 on the SD card is to make it non-removable.
First, delete the second section out of vold.conf that relates to the SD card.
Then edit init.rc:
Code:
mkdir /sdcard 0777 system system
...
mount ext3 /dev/block/mmcblk1p1 /sdcard nosuid nodev noatime nodiratime uid=1000,gid=1015,fmask=117,dmask=007
chown system sdcard_rw /sdcard
chmod 0770 /sdcard
If you feel like having 12 partitions on your SD card you can.
That leaves vold only handling the mounting of /media
This exists so that you can serve /media as USB Mass Storage.
You could have /media be a fixed mount by doing what you just did to the SD card.
The only hiccup there would be the Adobe Digital Editions wants to see /media as UMS.
Note: To edit init.rc, download bootutil from the signature, extract, edit and replace init.rc in uRamdisk.
Make sure that you have a backup and a recovery!
Note: All of the above changes to init.rc are wrong.
I can get it to mount in a shell, but not in init.rc
Whoops.
Oops, this thread has been forgotten.
Yes, auto-mounting ext3 SDcards has been solved.
See: http://forum.xda-developers.com/showthread.php?t=2184495

Mount EXT4 MicroSD Card

I've given up on reformatting the internal memory as EXT4 (my last post). However now, I want to mount an external SD card that is EXT4 (or any file format that has UNIX permissions). I can't get my device to mount the card, it says the filesystem is unsupported. Now, that's bull**** since Android has built in support for EXT. After searching threads here on XDA and Google, and even purchasing EzyMount as recommended, I can't get it to mount. I've tried BusyBox and mount commands (as root), with various errors such as "mount operation not supported on transport endpoint". I'm at my wit's end by now, trying to get some filesystem which has support for symlinks and UNIX permissions... any ideas?
kcattakcaz said:
I've given up on reformatting the internal memory as EXT4 (my last post). However now, I want to mount an external SD card that is EXT4 (or any file format that has UNIX permissions). I can't get my device to mount the card, it says the filesystem is unsupported. Now, that's bull**** since Android has built in support for EXT. After searching threads here on XDA and Google, and even purchasing EzyMount as recommended, I can't get it to mount. I've tried BusyBox and mount commands (as root), with various errors such as "mount operation not supported on transport endpoint". I'm at my wit's end by now, trying to get some filesystem which has support for symlinks and UNIX permissions... any ideas?
Click to expand...
Click to collapse
you fully rooted with custom kernel or only with rdlv etc?
First you gotta figure out how to mount this damn thing, gotta be possible.
Then you need to get this done on bootup, either in init.rc or init.d or smth.
You probably just use wrong commands? But I could be wrong, didnt try that yet but would also be interested. Having the file permissions also on SD would be nice, but it could cause trouble with mtp maybe?
zroice said:
you fully rooted with custom kernel or only with rdlv etc?
First you gotta figure out how to mount this damn thing, gotta be possible.
Then you need to get this done on bootup, either in init.rc or init.d or smth.
You probably just use wrong commands? But I could be wrong, didnt try that yet but would also be interested. Having the file permissions also on SD would be nice, but it could cause trouble with mtp maybe?
Click to expand...
Click to collapse
I am rooted, but stock ROM and kernel. MTP is for connecting to a computer? If it is, I don't need that. I have tried
mount -rw -t ext4 /dev/block/mmcblk1p1 /storage/extStorageCard
and variants switching the flags and options.
Interesting... I just typed that command in to make sure I didn't make any typos.... and my phone crashed and rebooted. I typed it again to see if it would cause another crash and it appears to have mounted the card! Whwn I type "df" at the prompt it now shows a 28.6 GB filesystem at that location, which has to be my sd card.
Why, how, I don't know. It works, it's all I can say.

Link2SD on Amazon Fire TV

Problem statement
The Amazon Fire TV has a limited memory sotrage of less than 5GB.
FolderMount allows for moving App data/obb to a USB device. Remaining components of the App, which sometimes are the larger part of the app, can't be transfered using
These remaining components can be 100s of MB and even above 1GB (Sine Mora is 292MB, Walking Dead is 1.14GB)
Solution
Link2SD allows for moving these components to an external SD card in the phone world. Below I'll describe how to do this on the Amazon Fire TV with a USB device.
This post heavily relies on tweaking a post by sashavasko. Major kudos to him. Up to finding his post I was not successful in mounting in a way that Link2SD could see the mount. This was due to a change in Android 4.2+ where one App's mounting isn't seen by others.
Below is a step by step guide for running this. I've posted a script for automating this here : http://forum.xda-developers.com/showpost.php?p=54601505&postcount=33
Requirements: Root, Mouse, Terminal Application
Step 0 - Preparations : Format a USB device to the Ext4 File system and install Link2SD
Ext4
Link2SD refers to parititoning your SDcard to both Ext4 and FAT, this is not required on our USB device. All we need is an Ext4 partiton we can mount for Link2SD.
I had a high end USB device I used for FolderMount. For testing, I got a 16GB Lexar Jump Drive, which got decent reviews. $8 at Staples ( even less with the right coupon. Other sizes are also cheap). Both went into my Powered USB hub.
You can also partition a single FAT32 USB device to two partitons - FAT32 and Ext4. I have verified both options. Please note that for this second option, if you already have files on your FAT32 USB device, you'd have to first copy them to a backup, as the partitioning trashes your data. You will then need to restore the backed up files to the FAT partition.
Format/Partition your USB device to Ext4 using free MiniTool Partition Wizard Home Edition on your Desktop/Laptop. Below is a nice post on this (Refer only to step 1), you can find others. Please note that this refers to an SDCard. We will be doing this on a USB device.
http://forum.xda-developers.com/showpost.php?p=37405779&postcount=1
In partitioning, please verify the partitions are created as Primary. Also, not sure is this is required, but I didn't name my partitions.
There are also linux commands to do this - I didn't investigate these.
Stick the Ext4 partitoned USB device into your Amazon Fire TV and power it up. We will need the device in for Step 2.
Link2SD
Download Link2SD from the Google Play store, or sideload it
Make the directory Link2SD requires
Code:
su
mkdir /data/sdext2
exit
Step 1 - Fix adb localhost
Follow step 1 in sashavasko's post
http://forum.xda-developers.com/showpost.php?p=45102645&postcount=1
Note1:
You will need a terminal app for this
Note2:
This step should only be run once. Running multiple times can mess the /data/misc/adb/adb_keys file as the key values will concatenate with sashavasko's method. This will cause mounting at boot not to work. If you did this or not sure if you've done this, just erase the duplicate keys from the /data/misc/adb/adb_keys file (the end of a single key is "[email protected] ). Or, better yet, if you aren't seeing any other different keys there - simply su and copy /sdcard/.android/adbkey.pub onto this file.
Step 2 - Install scripts
Follow step 2 in sashavasko's post
http://forum.xda-developers.com/showpost.php?p=45102645&postcount=1
Note 1
Look for your Ext4 partitoned device after running:
Code:
adb shell cat /proc/partitions
You should find the Ext4 device under /device/block starting with sd.
For example: My first USB device is sda1, the Ext4 partitoned one was sdb1 (sdb2 when the Lexar drive was partitoned to FAT32 and Ext4).
You should be able to recognize the devices according to their partition sizes.
Note 2
The msd2.sh file should be changed to be:
Code:
#!/system/bin/sh
mount -t ext4 [COLOR="Purple"]/dev/block/[/COLOR][COLOR="Red"]sdb1[/COLOR][COLOR="purple"] /data/sdext2 [/COLOR]&& sleep 5 && /system/bin/vold
where the sdb1 device should be replaced by the device you located in Note 1.
Step 3 - Test the script and grant su permissions
Run this (no su command required, no path to the sd.sh file is required)
Code:
sd.sh
Verify you aren't seeing any errors. You will be granting SU permissions.
Run Link2SD. Go to the menu at the top right. Select "Storage Info" - Verify Link2SD recognizes the Ext4 partiton in the third line (under SD Card 2nd Part. ).
Step 4 - Auto Mount at initialization
For this I'm using the /system/etc/install-recovery.sh script which you should already have. This script loads at boot and calls /system/etc/install-recovery-2.sh (a non existent file).
Create a file at /sdcard/install-recovery-2.sh which contains
Code:
#!/system/bin/sh
/system/xbin/sd.sh
Now move the file to its place:
Code:
su
mount -o rw,remount /system
cp /sdcard/install-recovery-2.sh /system/etc/
chmod 755 /system/etc/install-recovery-2.sh
mount -o ro,remount /system
exit
Now Reboot (Long press remote Select + Play)
Step 5 - Link2SD ready to go
Open Link2SD to verify (as you verified before) that after boot Link2SD sees the Ext4 partiton.
Start moving files using Link2SD :
Select an App
Go to "Create Link" - You will be asked which file types to move. Check them all (not the paid option if you haven't paid).
Link2SD will show "Creating Link...", then an advert (in the non payed version) and then: Application files linked and moved to SD card
Note the expected storage change in the Amazon Fire TV's "About" menu option will be seen after Rebooting.
"Remove Link" works properly
"Move to SD card" is not relevant
Final Words
Don't use this to move system apps, or system-like apps
Responsibly for running this is solely on you. I am only describing what works for me.
Works great thanks
I'd love to see a standalone app for installing this.
Sent from my SM-N900V using XDA Premium 4 mobile app
The msd2.sh file mentioned in Step2/Note2 is used to create a fake external SD Ext4 partition for Link2SD.
You can also use it to create a fake external SD FAT partition at /storage/sdcard1 for FolderMount.
FolderMount automatically recognizes this partition and suggests this as the initial path for its destination path suggestion.
In my case - sda1 is the FAT partition (For me - a USB stick fully formatted to FAT32), and sdb1 is the ext4 formatted USB stick. The same should work with a single partitioned USB stick (but different sd* device names - see original post).
The updated msd2.sh file looks like:
Code:
#!/system/bin/sh
[COLOR="DarkGreen"]mount -t vfat /dev/block/[COLOR="Red"]sda1[/COLOR] /storage/sdcard1[/COLOR] && mount -t ext4 [COLOR="Magenta"]/dev/block/[/COLOR][COLOR="Red"]sdb1[/COLOR] [COLOR="Magenta"]/data/sdext2[/COLOR] && sleep 5 && /system/bin/vold
SaltyCookie_OnLoan2FM_SVE said:
The msd2.sh file mentioned in Step2/Note2 is used to create a fake external SD Ext4 partition for Link2SD.
You can also use it to create a fake external SD FAT partition at /storage/sdcard1 for FolderMount.
FolderMount automatically recognizes this partition and suggests this as the initial path for its destination path suggestion.
In my case - sda1 is the FAT partition (For me - a USB stick fully formatted to FAT32), and sdb1 is the ext4 formatted USB stick. The same should work with a single partitioned USB stick (but different sd* device names - see original post).
The updated msd2.sh file looks like:
Code:
#!/system/bin/sh
[COLOR="DarkGreen"]mount -t vfat /dev/block/[COLOR="Red"]sda1[/COLOR] /storage/sdcard1[/COLOR] && mount -t ext4 [COLOR="Magenta"]/dev/block/[/COLOR][COLOR="Red"]sdb1[/COLOR] [COLOR="Magenta"]/data/sdext2[/COLOR] && sleep 5 && /system/bin/vold
Click to expand...
Click to collapse
The one annoying thing about this is during boot it will read the entire partition. This in turn in my case makes booting the Fire TV really slow. Lets hope I dont have to reboot much because it now takes around 2-3 minutes to boot up.
MadFlava said:
I'd love to see a standalone app for installing this.
Sent from my SM-N900V using XDA Premium 4 mobile app
Click to expand...
Click to collapse
I 2nd this. This is as close as we're gonna get to downloading Apps, ets., straight to an attached external drive but I know enough about this stuff to be somewhat intimidated by the initial instructions. Not that they're not clear, it just looks like I'd have too many avenues to brick my box.
Still...very good work OP. Thanks again.
MarkBP said:
I 2nd this. This is as close as we're gonna get to downloading Apps, ets., straight to an attached external drive but I know enough about this stuff to be somewhat intimidated by the initial instructions. Not that they're not clear, it just looks like I'd have too many avenues to brick my box.
Still...very good work OP. Thanks again.
Click to expand...
Click to collapse
Come on guys, this is XDA developers
OK, I have this brewing. Should post it by tomorrow.
awesome. how easy is it to reverse this entire process? I'd really like to know the risks before I take the plunge
I think the process can be greatly simplified. On my computer I created install-recovery-2.sh with the two lines below:
#!/system/bin/sh
mount -t vfat /dev/block/sda1 /storage/sdcard1 && mount -t ext4 /dev/block/sda2 /data/sdext2 && /system/bin/vold
Then I connected via adb to the fireTV from my computer.
Then an adb push of install-recovery-2.sh to /sdcard and then did an adb shell to the fireTV from my computer and su once there.
Copied from install-recovery-2.sh from /sdcard to /system/etc
Did a chmod 755 on the file to make it executable and then rebooted and all seems to be working well with partitions recognized.
tselling said:
I think the process can be greatly simplified. On my computer I created install-recovery-2.sh with the two lines below:
#!/system/bin/sh
mount -t vfat /dev/block/sda1 /storage/sdcard1 && mount -t ext4 /dev/block/sda2 /data/sdext2 && /system/bin/vold
Then I connected via adb to the fireTV from my computer.
Then an adb push of install-recovery-2.sh to /sdcard and then did an adb shell to the fireTV from my computer and su once there.
Copied from install-recovery-2.sh from /sdcard to /system/etc
Did a chmod 755 on the file to make it executable and then rebooted and all seems to be working well with partitions recognized.
Click to expand...
Click to collapse
Just tried this, didn't work for me (mount not detected).
- tselling, is Link2sd working with this ?
- If someone is working succesfully with Link2sd using tselling's method please report back. This is indeed a shorter route.
failed for me for tselling method
SaltyCookie_OnLoan2FM_SVE said:
Just tried this, didn't work for me (mount not detected).
- tselling, is Link2sd working with this ?
- If someone is working succesfully with Link2sd using tselling's method please report back. This is indeed a shorter route.
Click to expand...
Click to collapse
Link2sd found ok and I linked sevzero without problems. Should note that I use sda1 and sda2 for fat32 in first primary partition and ext4 on second primary pzrtition of same usb flash drive. Any other setup would need to have different script to match your drive setup.
Sent from my SAMSUNG-SGH-I497 using Tapatalk
why does this need more than 1 partition to work anyways? Is it just because the app requires it for some weird reason?
edit: also which partition needs to be the bigger one? do the sizes matter? and does stickmount need to be disabled for this to work?
desc
meadtj said:
why does this need more than 1 partition to work anyways? Is it just because the app requires it for some weird reason?
edit: also which partition needs to be the bigger one? do the sizes matter? and does stickmount need to be disabled for this to work?
Click to expand...
Click to collapse
why does this need more than 1 partition to work anyways? - Link2sd description in play store:
What you need for linking apps:
● root permission.
● a second partition on your SD card.
You should have two partitions on SD card and both should be primary.
The first FAT partition is your standard SD card storage. The second partition is used for application files and can be ext2, ext3, ext4, f2fs or FAT.
You need to use a non-FAT file system (ext2, ext3, ext4 or f2fs) on your second partition in order to link app's private data files. Because the FAT file system (FAT16, FAT32 or exFAT) does not support UNIX file ownership or permissions and will cause a security breakdown of app's private files.
Link2SD Plus can move app's private data files if you have a non-FAT partition
Click to expand...
Click to collapse
So we may be able to use FAT (haven't tried it) but we will lose some moving capabilities.
From my testing - FolderMount does work with the ext4 partiton, so I need two partitions (or 2 usb sticks).
also which partition needs to be the bigger one? - No restriction. Allocate as per your decision and experience with storage costs of apps.
do the sizes matter? - Don't believe her. It does.
Sorry. Uncalled for. Apologies. Not personal. I just had to.
and does stickmount need to be disabled for this to work? - No, it doesn't
983
tselling said:
Link2sd found ok and I linked sevzero without problems. Should note that I use sda1 and sda2 for fat32 in first primary partition and ext4 on second primary pzrtition of same usb flash drive. Any other setup would need to have different script to match your drive setup.
Click to expand...
Click to collapse
Ok, let's try and minimize this. Could it be due to tselling using a single partitioned USB drive, while I'm using two drives ?
I need a report back from someone with a single USB drive who tried tselling's simpler approach. If it failed - Maybe tselling added something along that he wasn't aware of. If it passed - Maybe that's a requirement for the simpler approach.
In other news, the script to automate this is take slightly more than I thought, due to unix-android differences (I come from a unix background). That, and the fact that we may have a simpler solution is delaying me. Oh, also had to stay late at work yesterday, Oooh and the dog ate my laptop.
What about Foldermount?
What about FolderMount for Data and OBB files? Can I still use it with Link2SD on same card?
SaltyCookie_OnLoan2FM_SVE said:
Ok, let's try and minimize this. Could it be due to tselling using a single partitioned USB drive, while I'm using two drives ?
I need a report back from someone with a single USB drive who tried tselling's simpler approach. If it failed - Maybe tselling added something along that he wasn't aware of. If it passed - Maybe that's a requirement for the simpler approach.
In other news, the script to automate this is take slightly more than I thought, due to unix-android differences (I come from a unix background). That, and the fact that we may have a simpler solution is delaying me. Oh, also had to stay late at work yesterday, Oooh and the dog ate my laptop.
Click to expand...
Click to collapse
I think it has to do with the mount points. I have the ext4 partition mounted to /data/ext2 where I think link2sd looks. I think that you could use an entire usb stick with one partition as ext4 mounted to /data/ext2 but your script would change
FROM
##############################################################################################
#!/system/bin/sh
mount -t vfat /dev/block/sda1 /storage/sdcard1 && mount -t ext4 /dev/block/sda2 /data/sdext2 && /system/bin/vold
#############################################################################################
TO
###################################################
#!/system/bin/sh
mount -t ext4 /dev/block/sda1 /data/sdext2 && /system/bin/vold
###################################################
However, I have not tried this. I may try this later today since I have a second fireTV and usb stick arriving today.
also, I am planning to use foldermount with the first fat32 partition I created, but I haven't gotten that far as I want to use the Pro version but need the play store loaded first.
OOPS, I did forget one part "mkdir /data/sdext2" (otherwise the mount fails).
tselling said:
I think it has to do with the mount points. I have the ext4 partition mounted to /data/ext2 where I think link2sd looks. I think that you could use an entire usb stick with one partition as ext4 mounted to /data/ext2 but your script would change
FROM
##############################################################################################
#!/system/bin/sh
mount -t vfat /dev/block/sda1 /storage/sdcard1 && mount -t ext4 /dev/block/sda2 /data/sdext2 && /system/bin/vold
#############################################################################################
TO
###################################################
#!/system/bin/sh
mount -t ext4 /dev/block/sda1 /data/sdext2 && /system/bin/vold
###################################################
However, I have not tried this. I may try this later today since I have a second fireTV and usb stick arriving today.
also, I am planning to use foldermount with the first fat32 partition I created, but I haven't gotten that far as I want to use the Pro version but need the play store loaded first.
Click to expand...
Click to collapse
tselling said:
OOPS, I did forget one part "mkdir /data/ext2" (otherwise the mount fails).
Click to expand...
Click to collapse
i did that too but still didnt work, maybe bc i have 3 partitions. Fat then Ext2 then NTFS
meadtj said:
i did that too but still didnt work, maybe bc i have 3 partitions. Fat then Ext2 then NTFS
Click to expand...
Click to collapse
Sorry, the directory is /data/sdext2
Your mount command is:
mount -t ext4 /dev/block/sda2 /data/sdext2 && /system/bin/vold
Also I am not 100% sure that ext2 filesystem works. ext4 works for sure.

Resources