Related
Hi all
I have all my apps and data moved to the sdcard a while back but my phone crashed and I decided to move only the apps to the sdcard.
I'm trying remove the /system/sd/data folder on the sdcard and keeps getting that error message. How to fix it?
Thanks
This should only happen if an NFS export is mounted to a linux box of some sort, and that export has changed or otherwise become inaccessible.
any idea how to fix it?
i have this problem, i'm not able to delete the data folder beacause of that error. :/
your ext2 partition is corrupted. this happens quite a lot if data is moved to the sdcard. boot up linux and run fsck on the sdcard and that should fix it.
cool. I'll give that a try.
Thanks
I'm having this problem too. Can you provide some basic instructions for how to mount and fix under linux? I have an ubuntu vmware image I can boot to on my windows pc and a usb card reader. Will that suffice?
When you plug the card into an ubuntu box it should automatically mount it as the next available drive. You'll have to figure out what device node the card shows up as, unmount it (umount /dev/<insert device name here>), and then run a filesystem check (fsck /dev/<insert device name here>) on the unmounted card. The utility will report various problems about "inodes" which you will want to say yes to fix. Once it has run through the file system should be in a consistent state and ready for use again.
You run the risk of losing stuff written to the card (which is probably corrupt anyways) when you run the fsck so you may want to take a copy of the data first.
On a side note: I am not sure what the default mount options are listed for moving the stuff onto the sd card in the faqs but I suspect it may help prevent corruption to mount the card on android with the sync option. Though, this will definitely slow writes to the card. It would definitely be a bad idea to remove the card while your G1 is running either way.
equid0x said:
On a side note: I am not sure what the default mount options are listed for moving the stuff onto the sd card in the faqs but I suspect it may help prevent corruption to mount the card on android with the sync option. Though, this will definitely slow writes to the card. It would definitely be a bad idea to remove the card while your G1 is running either way.
Click to expand...
Click to collapse
I was thinking of using the sync option, but then I read this at http://linux.die.net/man/8/mount:
sync
All I/O to the file system should be done synchronously. In case of media with limited number of write cycles (e.g. some flash drives) "sync" may cause life-cycle shortening.
Click to expand...
Click to collapse
Busybox seems to have an fsck command built in, but I don't think all the supporting stuff is there. I'd like to have a way to fsck my ext2 partition while on the go and not near my linux box.
I know that you can't fsck without unmounting the partition and of course it would be bad to unmount the partition with apps on it while the phone is running, but I was thinking it would be nice to be able to boot into the recovery console.
I tried this and attempted to do a fsck on /dev/mmcblk0p2 with the fsck in busybox as follows:
Code:
busybox fsck -t ext2 /dev/mmcblk0p2
But the error I got was that fsck.ext2, which is the actual executable that should be used, isn't there.
What would it take to get this onto the system so that I could boot into recovery and do a quick fsck and then reboot back into phone mode?
I was thinking of using the sync option, but then I read this at http://linux.die.net/man/8/mount:
Click to expand...
Click to collapse
Where flash lifetime is concerned... I agree, this will certainly have some impact. However, the amount of wear concerned really depends on the number of write cycles the particular flash you are writing to can handle, and how good any wear leveling in the memory controller is. Modern flash memory will likely last on the order of years even with tons of writing going on. If all you are moving to the card are the apps, that data will likely be written once (or maybe a few times over the life of an app) and only re-read from that point forward. The caching will eventually commit any data in the buffer to "disk" regardless of how much is actually there. The idea is to line up all the writes so they can be done efficiently. Where ext3 is concerned, the commit interval is 5 seconds by default, I am not sure what it was in ext2 but I imagine it is similar. Ext2 is not really a flash optimized filesystem, but it is readily available on basically any linux distro, and is supported on Android. A better fs for flash drives where write cycles are an issue might be something like jffs2 or yaffs.
At any rate, sd cards are cheap. Why not just throw it away when it starts to die?
But the error I got was that fsck.ext2, which is the actual executable that should be used, isn't there.
What would it take to get this onto the system so that I could boot into recovery and do a quick fsck and then reboot back into phone mode?
Click to expand...
Click to collapse
You would have to compile an ARM6 compatible version of fsck and get it onto the recovery partition so you could run it.
just turn off your phone, pull out the sdcard, boot on a linux os and
then in console type :
fsck -p /dev/your_ext2_partition
Is there any way to clear this error message on a windows xp computer?
Maybe use pargon partion manager, but where do I go to fix it in pargon?
equid0x said:
Ext2 is not really a flash optimized filesystem, but it is readily available on basically any linux distro, and is supported on Android. A better fs for flash drives where write cycles are an issue might be something like jffs2 or yaffs.
Click to expand...
Click to collapse
Hmm... Well, we know that yaffs is supported on Android because that's what the onboard storage uses. So I wonder why the tutorial for apps-on-sdcard suggests creating an ext2 partition? Couldn't we create a yaffs partition on the sdcard and use that instead?
Maybe because yaffs isn't as commonly supported in non-Android partitioning tools (which you would have to use to set up the card initially)?
In any case, if there's no real downside to having the partition be yaffs, how can I go about formatting it as such? I don't recall seeing such an option on gParted or anything, but then again I didn't look that carefully.
So can anyone clue me into how I might add yaffs/yaffs2 support to my desktop linux box? I'd like to try using a yaffs2 partition rather than ext2 to see if I get better reliability, but I need to add support for that filesystem first. Can't seem to figure out how to do that quite yet...
You will likely need to create the partition from the terminal using something like fdisk or cfdisk which will allow you to select the proper filesystem ID. The command for creating the filesystem is mkyaffs. The fstab in android will need to be modified to enable mount of this file system at boot. You will need to install all of the yaffs support tools on a linux desktop to get access to the mkyaffs command.
Yaffs is designed to be used directly on NAND or NOR flash memory (not abstracted through the controller built into an SD card) but it may work anyways. I am not very familiar with the specifics of this particular FS. Most of these flash filesystems are designed to provide a bootable root filesystem for an embedded device.
Yaffs kernel support can be built into a custom kernel with the instructions here:
http://yaffs.net/howto-incorporate-yaffs
Its not likely you will find pre-made packages for any of this in a common distro like Ubuntu. So, you will need to know how to compile it all by hand. A good starting point for a lot of linux info is The Linux Documentation Project at:
http://www.tldp.org/
FWIW I have built homebrew linux based routers for dual ISPs, IPSEC VPN and the like using a lightly modified version of CentOS and 4GB CF cards plugged into an ATA adapter. I used EXT2 on these and they were in production use at a small 13 server farm for a couple of years before being replaced with newer equipment without any failures whatsoever.
I have also used CF cards in small 200Mhz cube PCs as basic web kiosks for extended periods of time without any failures as well.
Under normal usage patterns on a mobile device probably does not require a large amount of writes in the grand scheme of things. I'd say it is fairly likely that your card will outlive the device you are using it in regardless of the filesystem in use.
If you are seeing lots of corruption I would suspect a flakey/failing SD card or some other hardware related problem. It definitely pays to buy high quality flash media. I would also suggest not allowing the phone to constantly run dead if you know things are being written to the SD card, since random power failures during a write to flash can permanently damage the media.
Can someone confirm that the cupcake builds unmount the /system/sd directory properly?
I'm using JF1.5 with apps2sd (unionfs version) and it appears like there is NEVER a clean unmount when the phone gets turned off or rebooted... I get constant corruption.
As a test:
1) on computer: fsck.ext2 /dev/mmcblk0p2 and make sure ext2 partition of the sd card is clean
2) insert card into phone allow it to fully boot
3) turn off phone
4) on computer: fsck.ext2 /dev/mmcblk0p2
Without exception it says:
e2fsck 1.41.5 (23-Apr-2009)
/dev/mmcblk0p2 was not cleanly unmounted, check forced.
Click to expand...
Click to collapse
sometimes it has to fix the FS, and other times it doesn't - but I have been getting killed by filesystem corruption.
Question: I almost constantly have the phone pluged into my computer via USB to charge, this this causing unclean unmounts during phone shutdown?
Could it be a bad card? I doubt it since the fat32 partion is working just fine. It's a pqi 4gb class6
Thanks!
It just crapped out on me - it's looping right now with the unionfs mod - it worked pretty much all day then just now I got a message saying the card was removed (which it wasn't) - I rebooted, and now it's looping!
here is the 'adb shell logcat' output
http://pastie.org/472880
I like where it says:
E/AndroidRuntime( 134): *** EXCEPTION IN SYSTEM PROCESS. System will crash.
Click to expand...
Click to collapse
I can't be the only one experiencing these issues! Am I?
(using thedude v1.0 with apps2sd2 (unionfs version))
UPDATE: fsck saved the day and stopped the looping... very frustrating...
try move dalvik-cache back for safety. I am not sure if the init process knows you have mounted an extra device, it may not umount it for you before it halts the system, which could explain the "not cleanly unmounted" issue.
the problem is you can't really umount safely since if you umount when installd is still running, it will notice all your apps are missing....
man I can't help much since I don't really know much coding but I encountered a similar problem... I dunno why but my phone decided to delete the ext2 partition... I had to reformat, worked afterwards, but still didn't make my a2sd work properly... I have still to figure out what to do...
drak0 said:
As a test:
1) on computer: fsck.ext2 /dev/mmcblk0p2 and make sure ext2 partition of the sd card is clean
2) insert card into phone allow it to fully boot
3) turn off phone
4) on computer: fsck.ext2 /dev/mmcblk0p2
Click to expand...
Click to collapse
When I first updated my phone would loop and never boot, then I found something different, on the RC33 my ext2 was mounted as dev/mmcblkp02, but now on adp1.5 its dev/block/mmcblkp02 once I fixed that I have had 0 issues at all
billc.cn said:
try move dalvik-cache back for safety. I am not sure if the init process knows you have mounted an extra device, it may not umount it for you before it halts the system, which could explain the "not cleanly unmounted" issue.
the problem is you can't really umount safely since if you umount when installd is still running, it will notice all your apps are missing....
Click to expand...
Click to collapse
Yea, I forgot to mention that I don't have the dalvik-cache moved, just apps and app-private.
re: can't unmount safely
Hmm, seems reasonable that the microsd card could be unmounted after the java runtime is killed... I mean, there has to be a process of things that get shutdown when you power down the phone... *shrug*
I'm just shocked most everyone else is having nothing but good luck with their apps2sd - doesn't make sense - ext2 is such a turd filesystem with regards to not being unmounted correctly...
It hasn't died on me again, so that's good! it's been a few hours
I guess normally ext2 won't fail that easily. if we sync before reboot and try not to do much write to that ext2 partition, it shouldn't matter whether it's properly unmounted or not.
drak0 said:
I'm just shocked most everyone else is having nothing but good luck with their apps2sd
Click to expand...
Click to collapse
Uhh.. what? Have you completely missed the approximately _million_ "MAI A2SD KILLED MAH PHONE" posts on these forums?
After I changed app2sd symlink method to unionfs I start experience problems. I.e. I have to reinstall some apps to make them work: some were forced close and some can't find Internet connection (no idea how can that be related). It feels like symlink method is more safe. May be I'll try to use mount -bind to see how it works.
PS: I moved only /data/app and /data/app-private, didn't touch any cache.
PPS: I personally think unionfs is evil
welp, I've given up with this for now - apps2sd is crap - I appreciate the hard work the devs put into it, but it just isn't very robust. my phone is constantly crushing the ext2 partition and almost daily I'm funning fsck on it to fix it - very very annoying....
Hopefully someone can get this resolved...
So I was using Slax. Great LiveCD/USB linux, extremely customizable, modular, fast, and small, and has the capability of either:
- saving changes to its rootfs onto an AUFS mounted on a non-linux FS (FAT32, NTFS) using posixovl (POSIX Overlay FS) with metadata (permissions, etc.) being held in files
- saving changes to a fixed-size loop mount image.
This got me thinking.
If we could insert all the necessary modules, code, etc. for posixovl into the Android linux, and make a modified a2sd script that takes advantage of posixovl, we could effectively do away with the requirement for crazy partitioning.
It should be simple enough for ROM devs to implement, assuming it's ready and installed:
1. Create folder on main partition if it doesn't exist, something like /sdcard/system/[app, app-private, dalvik-cache, app_s]
2. In the init scripts, before the a2sd stuff, mount /sdcard/system with posixovl on /system/sd
3. Run a2sd as normal, it should automatically just work.
I'll hopefully test this once I get my phone to a stable development/testing stage, and I don't need to make phone calls for a while. Anyone else is welcome to try to implement this idea.
My current test environment:
- HTC Dream (T-mo G1) with the deadly SPL of doom
- Cyanogen Experimental, latest build
- Amon_RA's modded recovery
- Wipe /data, move all existing apps to backup, remove a2sd partition, Backup for Root Users to restore some settings and data
Anyone with ideas or improvements, please let me know.
To be tested:
- Feasibility (can it work?)
- Functionality (does it work?)
- Portability (Can it work on other ROMs and devices like Hero, Pulse, Blur etc.? If so, will likely be moved to XDA's new Android board)
- Stability (Will everything Force Close on boot? Does it run fast enough? Does anything get corrupted over time?)
Links:
- http://sourceforge.net/projects/posixovl - Sourceforge page for posixovl
In desktop linux you can create a file with the touch command, and mount the file to a mountpoint after formatting it to ext4 for example.
Maybe this is the easier way?
I have done this about 5 years ago, but I will try it today and report if it worked.
edit: ok done already:
1. create a file of the desired size, eg: dd if=/dev/zero of=filename bs=filesize count=1
2. use mke2fs to format the file
3. create a mountpoint and mount the file
thats all. Now I have a 128MB file on my PC, mountable and usable like a partition.
Archont said:
In desktop linux you can create a file with the touch command, and mount the file to a mountpoint after formatting it to ext4 for example.
Maybe this is the easier way?
I have done this about 5 years ago, but I will try it today and report if it worked.
Click to expand...
Click to collapse
As far as I know, you can do that on the mobile Android, too, and that does work in theory. This technique involves mounting a loop filesystem, and it too will allow one-partition apps2sd, but it's less flexible, and I would think slower, than the overlay method.
For a 512MB apps image:
Create empty 512MB file
# dd if=/dev/zero of=/sdcard/apps.img bs=1024k count=512
Format it to Ext2
# mke2fs -L Apps2SD /sdcard/apps.img
Unmount existing a2sd
# umount /system/sd
mount new a2sd image
# mount -t ext2 -o loop /sdcard/apps.img /system/sd
Make the usual directories, and a mountpoint for the old a2sd partition
# mkdir /system/sd/app; mkdir /system/sd/app-private; mkdir /system/sd/dalvik-cache; mkdir /system/sd/apps-tmp
Mount the old a2sd partition
# mount -t ext2 /dev/mmcblk0p2 /system/sd/apps-tmp/
Move all files from the old partition to the image file
# mv /system/sd/apps-tmp/* /system/sd/
Unmount and remove the mountpoint, we don't need it anymore
# umount /system/sd/apps-tmp
# rmdir /system/sd/apps-tmp
Finally, you add the following line to the init script where the a2sd auto mount happens, and comment out the old line.
Code:
[...]
mount -t ext2 -o loop /sdcard/apps.img /system/sd
#mount -t ext2 /dev/mmcblk0p2 /system/sd/
[...]
This should do what you described, in theory. I can't say whether it will work or not. I can't tell whether it will or won't screw up your phone, I can't be held responsible if you screw something up or overlook the details. Either of us might have made a typo somewhere; apply common sense before doing anything.
This sounds great! I think this would also be usefull for someone like me, who has a sd card that doesn't want to be partitioned anymore (cross-linked files??). Only thing possible is fat32 or ntfs.
Am I correct with my assumption?
This sounds a lot harder and more complicated then partioning. Your also talking about a lot of work needing to be done just so people can avoid doing a simple thing like partioning a sd card. I would say it would be very difficult alone to get the os to run a virtual mounting service especially since that will take up resources and slow down the phone. There is a reason they only use this technique on live cds is it works but its slow. most of the computers they are running on have 1gig of ram and 2ghz cpu's. i really dont think the g1 can push this.
I do not think that this is great, it definitely is slower than a ext4 partition on a good class 6 microSD card. And it is more vulnerable to data loss since 2 different filesystems including a 20 year old non-journaling fs at the base of this construct are involved.
Another problem that came to my mind: when you mount your SD card as external USB device to a PC, the file containing your apps will no longer be accessible, or Android will make using the phone as external data storage impossible.
Interesting.
There is, however, a major problem: What happens when you unmount the fat partition on the phone in order to connect with a computer using UMS? Answer: everything on the phone will crash and burn since the apps filesystem will suddenly disappear = BAD.
posixovl is a nice find though...
Note that aufs, loopmount linux filesystems, etc., wouldn't be needed with this since posixovl appears to be vfat with posix extensions, so you should be able to just use posixovl directly on the sdcard.
There are several problems with that though... i.e. how reliable is posixovl regarding users tampering with it?
In any case, a prerequisite for use of it would be certain other changes being planned...
You might want to contribute to this thread:
http://forum.xda-developers.com/showthread.php?t=577941
(note: the thread links to a thread at android-platform, the one here has, as expected, gone off on a tangent... just ignore the junk.)
TylTru said:
So I was using Slax. Great LiveCD/USB linux, extremely customizable, modular, fast, and small, and has the capability of either:
- saving changes to its rootfs onto an AUFS mounted on a non-linux FS (FAT32, NTFS) using posixovl (POSIX Overlay FS) with metadata (permissions, etc.) being held in files
- saving changes to a fixed-size loop mount image.
This got me thinking.
If we could insert all the necessary modules, code, etc. for posixovl into the Android linux, and make a modified a2sd script that takes advantage of posixovl, we could effectively do away with the requirement for crazy partitioning.
It should be simple enough for ROM devs to implement, assuming it's ready and installed:
1. Create folder on main partition if it doesn't exist, something like /sdcard/system/[app, app-private, dalvik-cache, app_s]
2. In the init scripts, before the a2sd stuff, mount /sdcard/system with posixovl on /system/sd
3. Run a2sd as normal, it should automatically just work.
I'll hopefully test this once I get my phone to a stable development/testing stage, and I don't need to make phone calls for a while. Anyone else is welcome to try to implement this idea.
My current test environment:
- HTC Dream (T-mo G1) with the deadly SPL of doom
- Cyanogen Experimental, latest build
- Amon_RA's modded recovery
- Wipe /data, move all existing apps to backup, remove a2sd partition, Backup for Root Users to restore some settings and data
Anyone with ideas or improvements, please let me know.
To be tested:
- Feasibility (can it work?)
- Functionality (does it work?)
- Portability (Can it work on other ROMs and devices like Hero, Pulse, Blur etc.? If so, will likely be moved to XDA's new Android board)
- Stability (Will everything Force Close on boot? Does it run fast enough? Does anything get corrupted over time?)
Links:
- http://sourceforge.net/projects/posixovl - Sourceforge page for posixovl
Click to expand...
Click to collapse
lbcoder said:
Interesting.
There is, however, a major problem: What happens when you unmount the fat partition on the phone in order to connect with a computer using UMS? Answer: everything on the phone will crash and burn since the apps filesystem will suddenly disappear = BAD.
Click to expand...
Click to collapse
I kinda overlooked that point. Oops.
Though this same problem does exist on regular apps2sd when you remove the card without dismounting it, killing all apps and their processes, and freezing Dalvik's method of autostarting some apps.
I do tend to swap cards every now and then, but only after a reboot. Dalvik re-enumerates and caches dex, which makes for a slow boot, but it seems to just work in most cases that the apk install doesn't drop the app's functional payload (helper Linux/shell utils, libraries, NDK .so's) in /data/data (like some emulators, the Android Scripting Environment)
lbcoder said:
There are several problems with that though... i.e. how reliable is posixovl regarding users tampering with it?
Click to expand...
Click to collapse
As far as I know, the metadata files are marked as hidden and system files, and begin with a '.'. And I haven't tried this, but I think modifying the actual files under Windows has no negative effects, but moving, deleting, or copying files would likely be a no-no.
Also, I don't think there's a 'fsck' for posixovl, meaning that if any metadata files were screwed with the wrong way, the entire overlay FS would be trashed.
lbcoder said:
In any case, a prerequisite for use of it would be certain other changes being planned...
You might want to contribute to this thread:
http://forum.xda-developers.com/showthread.php?t=577941
(note: the thread links to a thread at android-platform, the one here has, as expected, gone off on a tangent... just ignore the junk.)
Click to expand...
Click to collapse
I checked that out. It was actually a small inspiration for what I was thinking of.
In any case, Android's package management system needs an overhaul. The package storage needs to be de-Linuxified, as all it is is a bunch of .apk files and .dex/.odex files, the UIDs of apps are in the AndroidManifest.xml, right?
In a somewhat unrelated note, app data needs to be moved to a specified folder structure on the sdcard. My card is full of folders in the root directory with random names.
If I'm understanding you correctly, you're talking about storing an image file on the normal SD card partition(which has to be FAT32 as far as I've seen) and then mounting it, correct? This idea has been talked about at length before on at least 3 separate occasions(2 of which were on this very forum) and found to be a bad idea due primarily to massive security risks since FAT32 has no permissions.
Also, I believe cyanogen ended up dumping unionfs/aufs due to rampant memory issues.
If you are talking about mounting an image from the FAT32 partition, please don't endorse this. We don't want to be throwing in security bugs into android, especially ones such as this which can't be plugged up.
As a modification to what I said: If you're suggesting doing this(or something similar) on a separate filesystem, after that project to change the AOSP to support one with permissions is finished, then I'm in full support.
If you want to go for a single partition on the sd card, why don't you just make the entire card use ext4? Your linux desktop reads it anyway, it uses journaling and so on, I guess it would be faster compared to fat32 and it is definitely safer to use.
And i guess it is not too complicated to mount this partition and use it for pictures, music and so on.
I have not tried this (yet) and I go to bed in 20 minutes, but maybe I will start testing something in that direction tomorrow.
[email protected] said:
If I'm understanding you correctly, you're talking about storing an image file on the normal SD card partition(which has to be FAT32 as far as I've seen) and then mounting it, correct? This idea has been talked about at length before on at least 3 separate occasions(2 of which were on this very forum) and found to be a bad idea due primarily to massive security risks since FAT32 has no permissions.
Also, I believe cyanogen ended up dumping unionfs/aufs due to rampant memory issues.
If you are talking about mounting an image from the FAT32 partition, please don't endorse this. We don't want to be throwing in security bugs into android, especially ones such as this which can't be plugged up.
As a modification to what I said: If you're suggesting doing this(or something similar) on a separate filesystem, after that project to change the AOSP to support one with permissions is finished, then I'm in full support.
Click to expand...
Click to collapse
UNIX permissions don't do anything in the way of "security" unless you have no access to the actual storage device from another computer (as is the case with the unrooted Dream's internal memory), or unless encryption is used. The posixovl driver OVERLAYS Unix permissions over Fat32 filesystems. But even still, with Unix permissions, nothing's stopping someone else from mounting the Ext2 partition and using chown and chmod.
And the image file on the SD card's Fat32 partition is a complete Ext2 partition complete with Permissions. Nothing is lost.
Archont said:
If you want to go for a single partition on the sd card, why don't you just make the entire card use ext4? Your linux desktop reads it anyway, it uses journaling and so on, I guess it would be faster compared to fat32 and it is definitely safer to use.
And i guess it is not too complicated to mount this partition and use it for pictures, music and so on.
I have not tried this (yet) and I go to bed in 20 minutes, but maybe I will start testing something in that direction tomorrow.
Click to expand...
Click to collapse
We'd just have to find the part in the Android that mounts /sdcard/, and change 'vfat' to 'ext2'. The only reason I wouldn't do this, is because it would immediately make it incompatible with Windows and Mac's default FS drivers. As far as I know, the only FS's that are supported universally within Linux, Mac, and Windows, are FAT and NTFS. And NTFS can be made to have crude support for permissions through security descriptors. Although, the Dream SPL, the Recovery images, and most of Android only uses FAT32.
This is discussed in android-platform Group :
http://groups.google.com/group/andr...read/thread/bf0709c157451cd9/f6aee1830c84620f
The goal is to be able to integrate this in android.
And not having to partition the SDCard is one of the requirements so far...
Unix permissions are not stored using fat or vfat, and ntfs is not really supported in desktop linux and i guess it cannot be used in android linux.
I would not use windows anyway so this is no problem to me, and there are drivers around to mount ext systems in windows. As Mac OS is based on unix there will be a solution for this too.
Access usind adb push and pull, via ftp and so on is not touched by using ext4 on the entire sd card I guess.
And if you don't go the easy way using gparted on a live cd or usb device to create 2 partitions, you will have to live with some disadvantages anyway.
Finally I want to say that my ideas are far from being perfect or usable at all, I see this thread as a kind of brainstorming.
im not as linux or android savvy as probably any of you but before the current method of creating a swap partition became the "standard", people used a swap file on the sdcard and linked that. seems similar to what you are suggesting here.
ofcourse when mounting the fat partition elsewhere (ums in windows for example) that swap file could no longer be used within android. i dont see a way to get passed the same issue, but worse here, due to android not having crucial apps when the fat partition is mounted.
then again, i am pretty much over my head in this conversation and could be over looking something...
I'm kind of fascinated by the FUSE + posixovl method of doing this. In the long run I have a feeling that it's going to perform like ****, but I think it's worth testing.
I managed to get both libfuse and mount.posixovl built and running on Android.
posix-overlay(/sdcard/fuse) on /sdcard/fuse type fuse.posixovl (rw,nosuid,user_id=0,group_id=0,default_permissions)
Giving this a little testing now, it definitely works.
Code:
/sdcard/fuse # ls -l
drwxr-xr-x 2 1000 1000 4096 Nov 5 17:17 test
TylTru said:
UNIX permissions don't do anything in the way of "security" unless you have no access to the actual storage device from another computer (as is the case with the unrooted Dream's internal memory), or unless encryption is used. The posixovl driver OVERLAYS Unix permissions over Fat32 filesystems. But even still, with Unix permissions, nothing's stopping someone else from mounting the Ext2 partition and using chown and chmod.
And the image file on the SD card's Fat32 partition is a complete Ext2 partition complete with Permissions. Nothing is lost.
We'd just have to find the part in the Android that mounts /sdcard/, and change 'vfat' to 'ext2'. The only reason I wouldn't do this, is because it would immediately make it incompatible with Windows and Mac's default FS drivers. As far as I know, the only FS's that are supported universally within Linux, Mac, and Windows, are FAT and NTFS. And NTFS can be made to have crude support for permissions through security descriptors. Although, the Dream SPL, the Recovery images, and most of Android only uses FAT32.
Click to expand...
Click to collapse
Ya, I meant more from the standpoint of a rogue app. Since FAT32 has no permissions, what would prevent such an app from modifying the stored image file to, say, change a trusted app with superuser permissions to some new code of its own making to, for example, watch for credit card numbers and send them back to the person who made the original rogue app? I'm always hesitant with any ideas that suggest storing an image file on the sdcard for appstosd for this reason.
Forget it, it's useless.
An overlay filesystem prevents you from enabling USB storage.
If you want to play around with FUSE on Android, here's a repository for my port of libfuse..
http://github.com/cyanogen/android_external_fuse
Hi,
I have an idea. I used symbian S60 of Nokia, Symbian can install app to sdcard. I see that when I mount sdcard to PC, my phone immediately hold all activations of all applications on my phone. And they have a PC sync software that help us access sdcard but not mount sdcard (like that we copy file from computer to sdcard via debug mode on android).
I think we should find out how symbian can do it and we will use their way .
I'm not a developer, I'm just an user.
I talked to a few people about this, and some deep kernel voodoo is going to be needed for this to really happen without partitioning.
Another idea is to forge ahead with this, and ditch the "unmount fs for usb storage" and use RNDIS + Samba or something like that instead to access files on SD. I kind of like this idea.
While working with Link2sd, I moved a ton of apps to the SD's 2nd partition, using f2fs file system. Rebooting the phone (XT926 - 4.4.2 - rooted), the 2nd partition was no longer accessable and, of course, the apps vanished. Worse, I can't re-install some of them. I get the "not enough storage" gripe. Short of doing an FDR, is there any hope of recovering the data or at least making it possible to re-install the lost apps? FWIW, I tried reading the SD under Win7 (nothing found, of course) and SuSE Linux with f2fs.tools installed. Still nothing.
How SOL am I?
I did an FDR.
It looks as though EXT3 is a workable choice. Right? Wrong?
I posted following is posted at the end of Working CWM Recovery for LOCKED 183.46.15 + Deodex and more
[... I]t appears that two related problems have shown up. And those error messages lead to 2 points.
A) Apps like Link2SD and Apps2SD, which move data from the internal "SD" to a real SD, fail to work. The errors all feature some form of the mount failing.
B) busybox isn't visible to these apps.
Busybox is located in /system/xbin. The link apps try to mount a second partition on the external SD. The mount utility is supplied by busybox. The errors say that /sbin/busybox can't be found. I think the system PATH is supposed to make calls to /sbin/busybox resolve to /system/xbin/busybox. I created a symlink from /system/xbin/busybox to /sbin/busybox. That changed the nature of the error messages somewhat but otherwise didn't correct the "mounts don't work" problem. After rebooting the phone, the symlink had to be created again as it wasn't present after the reboot.
I spent a lot of time with the Apps2SD developer (no reply from the Link2SD developer), trying to figure out what was going wrong. At the end of the day (literally), the problem was, in her mind, the ROM. Of course the ROM in the MAXX HD is locked up, so that can't be the source of the problem. But... is it possible that deodexing, or at least the process that installed the deodexing mod, subtly broke something related to busybox?
Click to expand...
Click to collapse
There isn't much to be added here except to ask if anyone has used one of the "link to SD" apps successfully.
RBEmerson said:
While working with Link2sd, I moved a ton of apps to the SD's 2nd partition, using f2fs file system. Rebooting the phone (XT926 - 4.4.2 - rooted), the 2nd partition was no longer accessable and, of course, the apps vanished. Worse, I can't re-install some of them. I get the "not enough storage" gripe. Short of doing an FDR, is there any hope of recovering the data or at least making it possible to re-install the lost apps? FWIW, I tried reading the SD under Win7 (nothing found, of course) and SuSE Linux with f2fs.tools installed. Still nothing.
How SOL am I?
Click to expand...
Click to collapse
Sent from my Eon_62i using XDA Free mobile app
You don't say... [/wink]
So does Link2SD not work with f2fs? I get "Second partition not found"
Hiya! I don't believe my problem is device specific. The background of how I ended up in this crappy situation is, but I believe the resulting issue is general. Should I be wrong, tell me and I'll move this to my device's section.
Short question: how can I (and can I?) restore data in a partition that got deleted, if no new filesystem has been created over it?
Long background: I have a Xiaomi Mi2-S 32GB. It used to have a peculiar layout: a double system partition (/system1 and /system2)¹, a small internal storage (/userdata)², and a big emulated SD card (/storage)³.
Let's explain why:
¹ False dual boot: the active system is installed in the first partition. When installing an update with the official app, the newer system gets installed in the second and that one gets booted. So, should this newer system fail to boot, you have an older one correctly working and ready to boot.
² and ³: so that the whole storage partition containing photos, music, videos, downloads, backups, saved games and such can be accessed with MTP, while the userdata containing apps and complementary system things is kept safe. This last decision, however, brings up a new problem: userdata can't be accessed by user to put his files or by apps without root permissions to store data (like photos), while storage can't be used to install apps, or even to move them using Link2SD or such. Some users might find storage is insufficient for their videos and music, while others might find userdata is too little for their games, and they are both stuck in this situation.
I was in the second group, so I altered my layout using stillka's guide on xiaomi.eu (Sorry, I can't post links). I extended my userdata, so that my storage resulted smaller. Plus, I understood altering a partition would mean deleting all the partitions before that one, and recreating them thereafter.
Until this point, all was OK. I installed Ivan's AOSP Lollipop for unmerged partitions, and found out it would experience random reboots with True Dual Boot. So I stuck with False one and forgot about everything. I kept that version without updating for a long time.
Then, several months later, my phone started rebooting randomly anyway. I figured I would come back to MIUI to get Xiaomi's support for an official ROM.
Little did I know they decided to change layout in the meantime. MIUI got so big the size of the two systems was insufficient. So they decided to merge them into an unique partition big enough. So, while flashing with the official tool MiFlash, it practically altered my system layout, having to delete all that was placed before them (cache, userdata and storage), never telling me what it was going to do, advising me to back my storage up somewhere. All I did was back up my userdata into storage, confident flashing their official ROM with their official tool would just write into system, since nobody told me otherwise.
So this is the result: the old, small size of userdata is back, and everything that comes after is left without any filesystem: these are the last line in parted's print output
20 327MB 336MB 8389kB ext4 persist
21 336MB 1409MB 1074MB ext4 system
22 1409MB 1812MB 403MB ext4 cache
23 1812MB 5570MB 3758MB ext4 userdata
24 5570MB 31.3GB 25.7GB storage
Click to expand...
Click to collapse
I've tried parted's rescue command, but it is unable to find a partition lying there. I don't have my old layout, so I'm not able to precisely know where my old storage began, but I remember it to be around 18 GiB in size. I've tried all ranges possible (from the current end of userdata, 18 G from the end and so on) but no dice.
Can someone tell me if there is any hope, and what can I try?
Now I'm trying to dd the whole eMMC, or even just the last partition, to my computer to work on it using, say, testdisk. There is just one problem.
Obviously, I must issue the commands in my PC's environment, as I've nowhere to dump the biggest partition in my phone to, on it. So it goes something like
Code:
adb shell su -c "cat /dev/block/mmcblk0" | pv > mmcblk0.raw
The problem is, even if my phone was rooted by TWRP and in my options menu, the su binary is not found
/sbin/sh: su: not found
Click to expand...
Click to collapse
What should I do? Should I manually push the su binary in /system/bin? Where should I take su? From my PC?
This link should be helpful to you. Though its for MI3, the guy explains exactly how he recreates all the stock partitions one by one using the parted utility.
However, I think even before you try that, I think you should consider using the shortcut suggested in this link. If you can alter the flash_all.bat slightly and add the gpt_both0.bin, it can re-create the stock partitions (at least this is what the poster has done for Mi3/Mi4, since yours is Mi2, I'm not so sure, you may have to find out).
Finally, here is one more link that you may want to read up.
---------- Post added at 06:34 AM ---------- Previous post was at 06:34 AM ----------
This link should be helpful to you. Though its for MI3, the guy explains exactly how he recreates all the stock partitions one by one using the parted utility.
However, I think even before you try that, I think you should consider using the shortcut suggested in this link. If you can alter the flash_all.bat slightly and add the gpt_both0.bin, it can re-create the stock partitions (at least this is what the poster has done for Mi3/Mi4, since yours is Mi2, I'm not so sure, you may have to find out).
Finally, here is one more link that you may want to read up.
The problem is I don't have to restore stock partitions. That was already done against my knowledge, only that the last partition was left without a filesystem. If anything, I should restore my previous, custom layout, I have no trace left about.
I've managed to use testdisk. It is not able to find any partition in my phone eMMC though...
Testdisk's failure might be because of a wrong geometry setting, even if it sounds strange to me.
This is the ouput of parted's print
parted print said:
Error: Both the primary and backup GPT tables are corrupt. Try making a fresh
table, and using Parted's rescue feature to recover partitions.
Model: (file)
Disk /media/Storage/mmcblk0.raw: 31.4GB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags:
Click to expand...
Click to collapse
This is fdisk's p
fdisk p said:
Disk mmcblk0.raw: 29.2 GiB, 31354139648 bytes, 61238554 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000
Device Boot Start End Sectors Size Id Type
mmcblk0.raw1 1 4294967295 4294967295 2T ee GPT
Click to expand...
Click to collapse
2T? Seriously?
Given that parted doesn't give those errors when run directly in adb, maybe something has gone wrong in the process of dumping my memory. I've issued this command:
Code:
adb shell dd if=/dev/block/mmcblk0 | pv | dd of=/media/Storage/mmcblk0.raw
Did I do something wrong?
This is what testdisk tells me in the analyse menu:
testdisk analyse said:
Disk mmcblk0.raw - 31 GB / 29 GiB - CHS 3812 255 63
Current partition structure:
Partition Start End Size in sectors
1 P EFI GPT 0 0 2 267349 89 4 4294967295
Warning: Bad ending head (CHS and LBA don't match)
No partition is bootable
Click to expand...
Click to collapse
It also detects an Intel table, which is rather odd. Selecting Intel or GPT gives the same result anyway, a big, round zero.
Rather than messing with partition tables using parted, I think there is a simple thing you can try:
1. Restore stock partition tables as it is (using the linked guide or some other means).
2. Restore the stock partitions themselves, something like this:
dd if=/sdcard/system.img of=/dev/block/mmcblk0
dd if=/sdcard/boot.img of=/dev/block/mmcblk1
These are just examples, you know which partition number corresponds to system.img, boot.img, etc. If you can do the above successfully, you will have restored the handset back to stock settings (both partitions and data) and it should start working in theory.
I'm not sure whether I'm not describing my problem clearly or I'm not understanding your suggestion.
The fact is my phone works correctly, it is not bricked. Right now I'm booting MIUI 8. My system partition is alright. My problem is my storage partition (the emulated SD card with all my personal data in it) got deleted, and I'm trying to get it back.
And the layout I had when my storage partition was available was not the stock one, but was already altered by me, as in storage was smaller in order to make more room for userdata (more apps). So, restoring stock layout would not give me my storage's previous start and end points.
k, now I understand your issue! If you want to recover data from a damaged (in this case non-existent) storage partition, have you tried any linux recovery programs (those may be your only option) though I'm not sure how many of them are designed to work with an eMMC.
Or is it the case that you don't care anything about recovering your personal data and just want to fix the storage partition, so the Mi2 file-manager recognizes it?
>> 2T? Seriously?
Yes, that's normal. I've observed even on MediaTek based devices that the partition tables leave that much extra space on the /storage partition (which is typically the last) though its actual physical size is just 2-3GB. You either got the starting/ending points of /storage partition in your MBR/GPT tables wrong (CHS/LBA numbers) or it is just a case of formatting this partition so that the Mi2 recognizes it. In that case, you can just try formatting it to FAT32 or something (but remember that you will loose all your personal data in that case).
Indeed my whole concern is trying to recover what was on it. For all I know, there's the possibility everything was wiped the instant MiFlash destroyed my storage partition, but since no new filesystem was written on it I'm not abandoning hope.
What I did was dump my eMMC to work on it using Linux restore programs (testdisk, mainly), but something must have gone wrong when dumping it. I will try to save the correct partition table and feeding it to TestDisk, but somehow I get the idea this won't solve my problem.
Is there anyway to get the eMMC's geometry parameters to input them manually in TestDisk?
The card is described by parted as "MMC SEM32G", and the parameters I can change are cylinder geometry (number of cylinders, default 3812), head geometry (number of heads: 1-255, default 255), sector geometry (numbers of sectors per track: 1-63, default 63) and sector size.
> What should I do? Should I manually push the su binary in /system/bin? Where should I take su? From my PC?
If you were still unable to take the dump for want of the su binary, then here is an easier way to disk dump the partitions without requiring the su binary at all, but you'll need the CWM image of your Mi2 device:
1. Start phone in Fastboot mode by long-pressing DnVolume+Start buttons.
2. Connect to USB Cable (ensure adb drivers and fastboot are installed).
3. Run this command: fastboot boot /path/to/CWM.img
4. Once phone boots into CWM, adb commands will work! Just mount the system partition in RW.
5. Using adb shell take the dump (you won't be needing root now since the partitions are in RW mode):
dd if=/dev/block/mmcWhatEver of=/sdcard/whatEver.img
EDIT
And if for some reason this doesn't work and you absolutely MUST copy the su binary, you can get the latest zip from the ChainFire.eu site, unzip the su binary and SuperSu.apk files and push the former in /system/xbin/su and the latter in /system/app folders using adb.
Of course, you'll have to provide correct permissions to the su binary, enable the setuid bit on it and finally symlink it to /bin/su.
I got the su binary by letting CWM recovery root my device. However, issuing commands with su copies just the first few bytes. In particular:
Code:
adb shell /system/xbin/su -c "dd if=/dev/block/mmcblk0" | pv | dd of=/media/Storage/mmcblk0.raw
Get 38B, while
Code:
adb shell su -c "cat /dev/block/mmcblk0" | pv > /media/Storage/mmcblk0.raw
Gets 25B.
Anyway, I can't use your suggestion: I don't have an /sdcard partition on my phone anymore: it's the one I'm trying to recover (the last 25.7GB without any filesystem in the partition table I posted in the OP). I must dump them on my PC.