Related
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?
As many of you have probably heard, you can load Ubuntu along side your Android OS. This has been confirmed on many devices, including N1, Desire, and Incredible. Here is the nexusonehacks post describing how to do it.
But I have found a better way to do it. Normally you mount ubuntu.img as a loopback and run from that. The problem with this is that is has very limited space (250mb or so) as you cannot exceed the size of the .img.
My method is to extract the contents of the .img and run it directly from the sdcard's filesystem.
Please be aware that if you use ClockworkMod Recovery, it will try to backup our new EXT2 partition! It thinks its an app-to-sd partition! I've yet to figure a way around this. Do not follow this tutorial if you make nandroids!
Requirements
- ubuntu.img (must be an ARM port)
- A Linux distro so you can 'cp' to your sdcard
- You will have to make a second partition on sdcard, ext2 type
- Patience and experience. This guide assumes you already know the basics of how to work with Linux
Step 1 Create the partition on sdcard
- Open your Linux distro and insert your sdcard (or enable disk drive on phone)
- Start GParted (or similar) and create an ext2 partition on your card. The partition should be as big as ubuntu.img. I recommend atleast 25% bigger so you have room to install packages and whatnot. FAT32 or NTFS will not work here!
Step 2 Mount ubuntu.img
- Mount ubuntu.img with the following commands (on the Linux distro, not phone):
Code:
sudo su
mkdir /mnt
mkdir /mnt/ubuntu
cd [B]/path/to/ubuntu/image[/B] **IMPORTANT!
mount -t ext2 -o loop ubuntu.img /mnt/ubuntu
Step 3 Copy contents of ubuntu.img to sdcard
- Make sure your new ext2 partition is mounted. We will assume its at /media/ext2sd
- Copy the contents. This will take a very long time depending on speed of card. Mine took roughly 70 minutes
Code:
cp -dRP --preserve=all /mnt/ubuntu/* /media/ext2sd/
Step 4 Update bootubuntu script
Here is a rundown of the modified script:
- Mount root as r/w
- Ensure /mnt/sdcard2 exists
- Mount the second sdcard partition
- Everything else, including chrooting to start Ubuntu! I use 'nice' to lower the priority of chroot so it won't make phone sluggish. Change this if you want.
Download the script
Step 5 Get Ubuntu running
- From here out its the same as any other tutorial. do a 'sh ubuntu.sh' to copy files to phone, then 'bootubuntu' to start it. Hopefully everything goes good for you! You now have much more room to do things!
Reserved..
Is it possible to use ext3/4 and would there be any performance gains?
ext3/ext4 use journaling. Unless you know for sure that your sdcard does wear-leveling, I would not advise using these as they may degrade the life of your card quickly. Another option would be to specifically make the partition without these options, but there is little to no performance gain as sdcards are already slow.
Hy all!
I found a very interesting post over at samdroid.net
My question is its possible to port this mod for our hero?
Link:
http://forum.samdroid.net/f55/i-o-performance-boost-migrate-your-spica-ext2-2218/
Info:
What does it do?
Reformatting /data as ext4 (as it needs journaling for safety), and /system as ext2(as it is mounted ro all the time).
Thx for the answer.
Regards
Wenner
It gives performance boost on Samsung phones because Samsung has it's own filesystem which slows down whole system. Reformatting it to ext gives boost because ext is faster. HTC Android devices has ext partitions as default so it isn't needed.
Wrong, on all counts.
The storage partitions on the HTC Hero and other devices is nand memory, not a block device. ext filesystem is designed for block devices. The filesystems on /data /system /cache etc are all yaffs2, a filesystem designed specifically for Memory Technology Devices like the NAND in our phones.
Furthermore, even if you could format /data, /system etc as a filesystem other than yaffs2 you'd have to do it from outside the ROM, either via recovery or hboot somehow. A journalling filesystem is destructive to flash memory because flash memory has a finite number of writes before it fails. You'd also have to have a custom kernel if the default kernel doesn't support the filesystem you want to switch to.
If you use old style apps2sd and therefore have a partition for it on your sdcard, they're set up to emulate block devices and you should use ext2 for the reasons pointed out earlier. sdcards are still flash memory at heart and thus journalling is destructive.
Thanks for explanation, but i have question - why we don't use yaffs2 for app2sd (which is designed for flash memory)?
And which is faster - yaffs2 or ext2? On Samsung devices reformatting whole system to ext2 gives performance boost (in comparision to RFS).
Hi,I installed topogigi's rom because it had webtop and everything seemed fine,and THEN I read this
"
you can simply use ext4 conversion directly from recovery(THE CWM ONE!) just go in advanced and upgrade to ext4 system;data;cache...
DON'T UPGRADE OSH TO EXT4(WEBTOP PARTITION) CAUSE IT WILL CAUSE THE OSH NOT TO BE MOUNTED (AKA DELETED!)...
I THINK THERE IS A BUG IN RECOVERY EXT4 SCRIPT CAUSE OSH SHOULD WORK EVEN WHEN EXT4"
But...of course I had already converted the file system even the osh...
What to do now people?
I don't have a clue,do I need to reflash something ,to convert the ext4 osh into something else? How?
I'm pretty lost ....
Sent from my ATRIX
Easiest is to reinstall the osh partition (I assume you likely have no files you really care about on it).
Find a webtop.zip for the ATT rom that top's stuff is based on (I assume it is a 2.3.6).
http://forum.xda-developers.com/showthread.php?t=1163009
Once you have that on your phone, just go to recovery and reformat the OSH partition (to put it back as EXT3) and install the zip.
If you really want to keep the webtop you have, it can be done but it more difficult and likely not worth the effort .
EDIT: If you are not certain if it is broken, take a look to see /osh has anything in it. If it is empty, it is broken (not being mounted). If you see a standard looking unix tree, it is fine. It actually can be mounted as an EXT4, but that would take some playing around with system files (see how "webtop to sdcard" gets around the mount problem).
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.