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.
Hello,
I'm having some issues with partitions and recovery image creation after Windows 8.1 clean installation ( from USB pen drive). Disk situation is in the attachments. First thing I noticed is that there is a new partition between C: and Recovery Partition. The problem is that windows doesn't recognize recovery partition and when I try to
backup it on usb drive the option "Copy the recovery pertition from PC to recovey unit" is gray (unclickable). I tried to copy it with EaseUs Partition Manager but the unit doesn't boot. What can I do in order to rescue Recovery Image?
Tnx a lot
>What can I do in order to rescue Recovery Image?
The rec partition is non-functional once you did the clean install. You can delete all partitions and reclaim the space, and have the partition tool recreate the ESP (EFI Service Partition, required for EFI toys). If using GPT format, also recreate the MSR (Microsoft Reserved Partition, required for GPT disks). Alternatively, you can switch to MBR and skip the MSR.
Then, ESP (100MB space) is the first partition, MSR (128MB) is second, and the rest can be allotted to the main partition. Make sure partition tool is current, else it may not handle EFI stuff. I use freebie Partition Wizard.
More info here http://msdn.microsoft.com/en-us/library/windows/hardware/dn640535(v=vs.85).aspx
For recovery, simply use an image backup tool to back up the main partition once you're done installing and setting up 8.1. There are lots of tools to do this, and you can save the image into a dedicated partition like the MS rec partition, or offline it to USB and save the space for regular use. There is no need to stick with the convoluted MS method.
Abstracts foreyro
e.mote said:
>What can I do in order to rescue Recovery Image?
The rec partition is non-functional once you did the clean install. You can delete all partitions and reclaim the space, and have the partition tool recreate the ESP (EFI Service Partition, required for EFI toys). If using GPT format, also recreate the MSR (Microsoft Reserved Partition, required for GPT disks). Alternatively, you can switch to MBR and skip the MSR.
Then, ESP (100MB space) is the first partition, MSR (128MB) is second, and the rest can be allotted to the main partition. Make sure partition tool is current, else it may not handle EFI stuff. I use freebie Partition Wizard.
Click to expand...
Click to collapse
Thank you for reply,
I suspected there were no chance. I virtually undestand what you suggest but I'm not sure how to do exactly. Should I create a bootable partition
tool? Isn't possible to delete and join partitions during win8.1 installation( when it ask to select the partition for installation)?
>Should I create a bootable partition tool?
Yes. Many partitioning tools come in ISO form. To image the ISO onto a bootable USB stick, the simplest tool to use is Rufus http://rufus.akeo.ie . Rufus can also image the Windows ISO to boot USB, so no need for the dedicated MS tool. More complicated, but also more capable, are multiboot tools that allow booting from multiple ISOs, eg Easy2Boot http://easy2boot.com .
>Isn't possible to delete and join partitions during win8.1 installation
I doubt it is capable as a regular partitioning tool, eg create specific partitions like ESP/MSR, or move them. You do want to delete everything, then recreate the ones you need, to avoid non-contiguous space. If you want to stick with MS stuff, the tool to use is fdisk, but that harks back to the stone age in terms of user-friendliness.
thank you again. I tried first the easier way and deleted partitions during Win installation. The result is in the attachment. Please, tell me your opinion.
Attachments:
Looks like Win install is self-sufficient and can create the needed partitions. As a rule, I do my own partitioning, since Win install will create the Win RE (Recovery Environment) partition, which is useless when I'm handling my own backup/recovery. I also disable UEFI on my boxes and use MBR, which then obviates the need for ESP & MSR, so everything can be allocated to data. GPT is irrelevant for small drives, and EFI is basically a headache. But if you're happy, then it's all good.
Edit for my above post: I meant diskpart, not fdisk.
The other day, I attempted to make a Windows 8 Recovery USB using my external hard drive and the Media Creation tool. I specifically made a new partition for this process, as I had two other partitions on it with data. Making sure that the partition that was empty was selected, I successfully created the media. I couldn't get it to boot, however, and when I looked on the hard drive, its erased and merged my other two partitions, turning them into unallocated space, and the G: partition was the recovery drive.
I don't want to touch the recovery partition, because I don't want to screw anything else up.
Please help, I had a lot of important files on there and I'm not sure what to do.
There are a plethora of apps on the PlayStore that claim to actually "resize" your eMMC partitions. How well do they work? Can you just install it and change your say internal partition from 500MB to 1GB?
To the best of my knowledge, partition tables are kept well hidden and behind lots of complexities on various devices. The repartitioning methods are different on each device and too complex to try out (I know many on the MIUI forum who ended up bricking their devices or damaging their motherboards while trying to repartition).
Then how do these partition apps work?
I'm new to rooting and installing new roms on android systems, but i work making custom linux and windows systems and optimizing for over a decade.
So, my optimizing spirit is tingling to try everything, but this particular thing is just a question, i'm not intending to actually do it.
When using the terminal on TWRP, i've noted that i could fdisk the internal storage (/dev/mmcblk0) and that i could see all the partitions it had, like system, data, cache and so on.
TWRP and other tools only re-format those partitions with ext4 in order to wipe, so i used 'dd' in terminal to zerofill the ones i knew i could wipe and then formatted then in ext4 (with 'dd if=/dev/zero of=partition').
But i had a bigger question and i couldn't find answer nowhere: What would happen if i actually used dd to zero fill EVERYTHING, the entire /dev/mmcblk0, including the very partition table, every byte on it?
Would the device still enter fastboot mode? Would i still be able to connect it on the fastboot utility and flash a new recovery or do something?
Or, if after zero filling, still on the terminal, if i used fdisk to re-create the proper partitions and then formatted them, could i reboot, re-flash the recovery (once there would be the partition for it) and do an very-deep-clean install?
Not that i think that this has any utility, i just wonder if this would end up rendering the device totally useless, or if the fastboot mode is stored in an ROM chip, like a computer bios is.
Guilherme Franco said:
I'm new to rooting and installing new roms on android systems, but i work making custom linux and windows systems and optimizing for over a decade.
So, my optimizing spirit is tingling to try everything, but this particular thing is just a question, i'm not intending to actually do it.
When using the terminal on TWRP, i've noted that i could fdisk the internal storage (/dev/mmcblk0) and that i could see all the partitions it had, like system, data, cache and so on.
TWRP and other tools only re-format those partitions with ext4 in order to wipe, so i used 'dd' in terminal to zerofill the ones i knew i could wipe and then formatted then in ext4 (with 'dd if=/dev/zero of=partition').
But i had a bigger question and i couldn't find answer nowhere: What would happen if i actually used dd to zero fill EVERYTHING, the entire /dev/mmcblk0, including the very partition table, every byte on it?
Would the device still enter fastboot mode? Would i still be able to connect it on the fastboot utility and flash a new recovery or do something?
Or, if after zero filling, still on the terminal, if i used fdisk to re-create the proper partitions and then formatted them, could i reboot, re-flash the recovery (once there would be the partition for it) and do an very-deep-clean install?
Not that i think that this has any utility, i just wonder if this would end up rendering the device totally useless, or if the fastboot mode is stored in an ROM chip, like a computer bios is.
Click to expand...
Click to collapse
The hardware side of fastboot is typically stored on mmcblk0 somewhere in bootloader, meaning it is in the boot partition which is one of the things you would wipe. This would hardbrick your device, rendering it virtually unrecoverable, with a very slim chance of recovering, if its even possible at all, typically, it isn't possible.
Just stick with the tools already designed to handle any wiping that you need.
Sent from my SCH-I535 using Tapatalk
Droidriven said:
The hardware side of fastboot is typically stored on mmcblk0 somewhere in bootloader, meaning it is in the boot partition which is one of the things you would wipe. This would hardbrick your device, rendering it virtually unrecoverable, with a very slim chance of recovering, if its even possible at all, typically, it isn't possible.
Just stick with the tools already designed to handle any wiping that you need.
Sent from my SCH-I535 using Tapatalk
Click to expand...
Click to collapse
That's interesting, i thought my fear was irrational, but it seems to be the case.
But, why is it like that? Why leave everything you need in an RW memory, while you could use a piece of ROM memory to grant the basic functions and the capability of manipulating the RW one (like a PC BIOS)?
In computers you usually don't need to mind wiping everything you can, your device will still work or will be at least recoverable.
Even screwing BIOS and firmwares in computers and some other devices is something that usually won't render the device unrecoverable. Although they sure can cause a hell lot of headache and may need physical intervention like soldering chips and such, i myself strove to find the correct bios images for certain motherboards and to flash the chips because i didn't have an proper flashing equipment, so i had to build an arduino circuit for that (but i luckily worked with detachable chips).
The only other device i know to be rendered unrecoverable are hard drives if you wipe the firmware stored in platter, as it has the service area, which keeps a big part of all information needed to properly address and read the disk and even the other system tracks spread through the disk, that are also needed to control the head, to read and to correct data errors.
Some of these are written at factory, but others must be writable so the hard drive can take care of itself.
But you'd only be able to mess with these data with proprietary low-level software using specific microcode, zero fill and low-level formatting software can't write on any of these tracks, they can only access LBA addressed tracks.
Guilherme Franco said:
That's interesting, i thought my fear was irrational, but it seems to be the case.
But, why is it like that? Why leave everything you need in an RW memory, while you could use a piece of ROM memory to grant the basic functions and the capability of manipulating the RW one (like a PC BIOS)?
In computers you usually don't need to mind wiping everything you can, your device will still work or will be at least recoverable.
Even screwing BIOS and firmwares in computers and some other devices is something that usually won't render the device unrecoverable. Although they sure can cause a hell lot of headache and may need physical intervention like soldering chips and such, i myself strove to find the correct bios images for certain motherboards and to flash the chips because i didn't have an proper flashing equipment, so i had to build an arduino circuit for that (but i luckily worked with detachable chips).
The only other device i know to be rendered unrecoverable are hard drives if you wipe the firmware stored in platter, as it has the service area, which keeps a big part of all information needed to properly address and read the disk and even the other system tracks spread through the disk, that are also needed to control the head, to read and to correct data errors.
Some of these are written at factory, but others must be writable so the hard drive can take care of itself.
But you'd only be able to mess with these data with proprietary low-level software using specific microcode, zero fill and low-level formatting software can't write on any of these tracks, they can only access LBA addressed tracks.
Click to expand...
Click to collapse
The simple answer would be that the manufacturers don't want you messing with the device to begin with so they don't do anything to make flashing or recovering easier for us.
Sent from my SCH-I535 using Tapatalk