Hey guys,
On some ROMs update scripts, I've been noticing that the ROMs delete from the system partition using a delete_recursive("/system") command instead of just bombing the system partition with a format. I was just suggesting that wouldn't it be a better idea to run a ext4 format on the /system partition, therefore you have a "clean slate" instead of deleting stuff from /system and leaving stuff behind in the ext4 journal?
The reason I say this is that if any blocks are actually bad, a delete won't reveal them. If you format the system partition using mkfs.ext4, it allows the system to do a quick scan for bad blocks and mark them before formatting, and finally copying files to the system partition.
One would just have to do something like this in their update-script:
Code:
run_program("/sbin/busybox","mkfs.ext4 -L system -m 0 <mtdblock of system partition>");
Again, this is only a suggestion. Feel free to argue!
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.
Nexus 10 16 GB
I took the 4.4.3 OTA, which worked fine. Then I flashed TWRP 2.7.1.0, which worked fine. Then I used TWRP to install SuperSU 1.99. Prior to reboot I wiped the cache. During this the Nexus turned off by itself. When I rebooted it got stuck in boot at the merging circles (it didn't hang, the circles kept moving).
- TWRP works fine
- ADB works fine
- /proc/partitions shows all partitions listed
- /dev/block/platform/dw_mmc.0/... shows all partitions listed, with correct hard links
- "e2fsck cache" partition says:
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open cache
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
- "fdisk -l" shows nothing
- "fdisk -l cache" shows the correct partition size
- fastboot erase cache just hangs at:
"<waiting for device>"
Running e2fsck on system and userdata is clean. e2fsck the other partitions (boot, efs, metadata, misc, param, recovery) gives an error, but I'm guessing they're not ext partitions.
I'm worried that TWRP hosed the cache partition. I could try to flash stock manually, but I'm worried that ADB won't see the cache partition (it can't even wipe it). If I can fix the cache partition i should be able to reboot while keeping all my data intact.
Any ideas?
Also, any EASY way of copying over all my data with ADB? I guess I could just ADB PULL the TWRP nandroid files?
LVM is a logical volume manager. It joins underlying physical partitions into a pool which can be divided to virtual partitions. Since there are no real partition layout changes, hard bricking is a lot more difficult (but not impossible).
You may have BlePart installed previously, it makes no difference. You can use stock partition layout.
WARNING: LVM requires you to install LVM compatible ROMs. Do not install non-LVM ROM if you have LVM installed.
All your data will be wiped.
Current space division
If you would like to change this, open the zip META-INF/com/google/android/update-binary, find the partition sizes, and modify data partition size (the total space is nearly 3GiB so watch the space).
System - 800MiB
Cache - 10MiB
Data - 2000MiB
Internal SD - rest of the free space
Requirements
LVM-compatible recovery installed
Strongly recommended: Unlocked pink screen
How to install
Download the zip from downloads below
Save it to your phone's EXTERNAL SD card
Reboot to recovery (if you notice errors it is normal, since LVM is not yet installed)
Install the zip from your external SD
Your phone will automatically reboot in 3 seconds
How to uninstall
Method 1
Download the zip from downloads below
Save it to your phone's EXTERNAL SD card
Reboot to LVM recovery
Install the zip TWICE (first time it will notify you LVM is installed, second time it uninstalls it)
Your phone will automatically reboot in 3 seconds
Method 2
Install any non-LVM recovery (TWRP recommended as some older CWM recoveries cannot format vfat properly)
Reboot to recovery
Wipe/Format system, data, cache, internal storage partitions (and repair file system if errors occur)
Reboot recovery
Method 3
Install stock ROM
Downloads
BlePart-LVM-11
Hello, Blefish
These lines i need to change? When i clean applications i have empty space in "System" 220mb, and "Data" i have 270mb empty space.
/sbin/lvm lvcreate -L 700M -n system lvpool;
/sbin/lvm lvcreate -L 10M -n cache lvpool;
/sbin/lvm lvcreate -L 2350M -n userdata lvpool;
/sbin/lvm lvcreate -l 100%FREE -n media lvpool;
Click to expand...
Click to collapse
P.S. Can i delete directly application from system.new.dat?
Good,thanks!
BlePart-LVM-11 uploaded.
This change is minor. It only simplifies installing/uninstalling and makes it easier for the end user. It also adds necessary checking mechanism to make sure the user is installing LVM from a proper location with proper tools.
My external sd card don´t work, can I still get it done?
MazdaGTI said:
My external sd card don´t work, can I still get it done?
Click to expand...
Click to collapse
Through ADB sideload you can do it . You need to install necessary drivers and ADB if you are on windows. Technically it is possible to use ADB and push the zip to /tmp/ for example, and install from there aswell.
I decided to re-partition my tablet's internal storage to free more space for user apps and data. Unfortunately I got part way through the guide and decided to reboot my tablet (which was a bad idea), as now I can mount all the partitions in twrp using the mount -a command and editing the fstab file, but in twrp it shows system, data, and cache as not being present.
Any help is greatly appreciated