I unlocked my HTC One Bootloader, but all my files got wiped :crying:
How can i restore files? I lost all my photos and whatsapp chat history. There must be a possibility?! But how?
thekkk said:
I unlocked my HTC One Bootloader, but all my files got wiped :crying:
How can i restore files? I lost all my photos and whatsapp chat history. There must be a possibility?! But how?
Click to expand...
Click to collapse
I don't think you can recover. It told you this when unlocking.
mb_guy said:
I don't think you can recover. It told you this when unlocking.
Click to expand...
Click to collapse
It told me that personal settings will be deleted, and i thought that only would be settings, etc...
and in the tutorial i've read there was no warning for this
Yeah I don't think you'll get anything back easily at all. Keep that phone backed up in the future!
Sent from my HTC One using Tapatalk
thekkk said:
It told me that personal settings will be deleted, and i thought that only would be settings, etc...
and in the tutorial i've read there was no warning for this
Click to expand...
Click to collapse
No the bootloader unlock screen says personal data (not settings) will be wiped which include the virtual sdcard (/data/media/0)
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
btw this also deleted stock apps like flashlight, calculator, sound trimmer, tuneIn, SoundHound etc.... which are stored in /data/preload
bbinder said:
Yeah I don't think you'll get anything back easily at all. Keep that phone backed up in the future!
Sent from my HTC One using Tapatalk
Click to expand...
Click to collapse
It doesnt matter how difficult it is, but somehow i'm sure there must be a way, the question is how. Because every recovery software cant be used because of de MTP-mode
thekkk said:
It doesnt matter how difficult it is, but somehow i'm sure there must be a way, the question is how. Because every recovery software cant be used because of de MTP-mode
Click to expand...
Click to collapse
Sure. I just personally think that you'll give up, given those circumstances Just being realistic...
Sent from my HTC One using Tapatalk
thekkk said:
the question is how. Because every recovery software cant be used because of de MTP-mode
Click to expand...
Click to collapse
The first step is to not boot the phone until you get a dump of your data partition. Booting to a custom recovery is okay--a full Android boot is not.
In recovery (using the ADB shell), umount data and get a dump of the data partition (/dev/block/mmcblk0p37) using "dd". Since you can't write to the data partition while making its dump, you'll need to write to /system. Since /system isn't very big, you'll need to do the dump in pieces of about 350 MB each (depends on how much free space you have in /system).
The "dd" parameters you'll need are "bs" to speed things up, "skip" to tell it where to start the chunk, and "count" to determine how big the chunk is. Since /data is 25.6 GB, you'll need to do this 60-70 times, and after each chunk, use "adb pull" to copy the chunk to your computer. When you have all the chucks, reassemble them and make sure it's the same size as /dev/block/mmcblk0p37. Make sure it's a valid ext4 filesystem. Then you can start using data recovery tools.
thekkk said:
It doesnt matter how difficult it is, but somehow i'm sure there must be a way,
Click to expand...
Click to collapse
So put your money where your mouth is and do it.
fenstre said:
The first step is to not boot the phone until you get a dump of your data partition. Booting to a custom recovery is okay--a full Android boot is not.
In recovery (using the ADB shell), umount data and get a dump of the data partition (/dev/block/mmcblk0p37) using "dd". Since you can't write to the data partition while making its dump, you'll need to write to /system. Since /system isn't very big, you'll need to do the dump in pieces of about 350 MB each (depends on how much free space you have in /system).
The "dd" parameters you'll need are "bs" to speed things up, "skip" to tell it where to start the chunk, and "count" to determine how big the chunk is. Since /data is 25.6 GB, you'll need to do this 60-70 times, and after each chunk, use "adb pull" to copy the chunk to your computer. When you have all the chucks, reassemble them and make sure it's the same size as /dev/block/mmcblk0p37. Make sure it's a valid ext4 filesystem. Then you can start using data recovery tools.
So put your money where your mouth is and do it.
Click to expand...
Click to collapse
That sounds like something, first of all thanks for your input!
But how should i run this command without booting into android (I'm in clockwork-touch recovery, but doesnt seem to work)? This command works (when booted into android), i've tried it with 'dd', so i guess thats the correct way!
=> If i have to boot into android anyway to do this, i would also have an OTG plus USB-Stick (32GB), then i could do it in about 2 parts to save it directly to the usb-stick. Would that be the better aproach instead of writing it to the /system? because i don't know what action writes to the /sdcard
Just to clarify, i have to execute the following command one after the other(?) :
$ dd if=/dev/block/mmcblk0p37 bs=367001600 count=1 skip=0 of=/system/chunk1.img
adb pull /system/chunk1.img .
$ dd if=/dev/block/mmcblk0p37 bs=367001600 count=1 skip=1 of=/system/chunk2.img
adb pull /system/chunk2.img .
$ dd if=/dev/block/mmcblk0p37 bs=367001600 count=1 skip=2 of=/system/chunk3.img
adb pull /system/chunk3.img .
Do i have to make something special that i can reassemble them later or are there programms out there for that problem?
Um, every time you boot to android you are rewriting the very flash memory you are trying to recover.
The ratio of the amount of work required vs the chances of success is not a favorable one. Unless you are trying to recover video of 'baby's first steps' or a bitcoin private key, I would let this go..
Sent from my HTC One using xda app-developers app
NxNW said:
Um, every time you boot to android you are rewriting the very flash memory you are trying to recover.
The ratio of the amount of work required vs the chances of success is not a favorable one. Unless you are trying to recover video of 'baby's first steps' or a bitcoin private key, I would let this go..
Sent from my HTC One using xda app-developers app
Click to expand...
Click to collapse
There were memories on it, and it would be a pity if they're all gone now
I'm not that type of guy to give up, I have the motivation and the time to do it. I will give it at least a try, I have nothing to loose, except time - but that doesnt matter because I wanna have these data's back
The only one problem I see now is that if I read the block step by step and save this, I don't know how I should reassemble all these files. Anyone has an idea? Reading a block and pull it out of the phone isnt the problem
thekkk said:
=> If i have to boot into android anyway to do this, i would also have an OTG plus USB-Stick (32GB), then i could do it in about 2 parts to save it directly to the usb-stick. Would that be the better aproach instead of writing it to the /system? because i don't know what action writes to the /sdcard
Just to clarify, i have to execute the following command one after the other(?) :
$ dd if=/dev/block/mmcblk0p37 bs=367001600 count=1 skip=0 of=/system/chunk1.img
adb pull /system/chunk1.img .
$ dd if=/dev/block/mmcblk0p37 bs=367001600 count=1 skip=1 of=/system/chunk2.img
adb pull /system/chunk2.img .
$ dd if=/dev/block/mmcblk0p37 bs=367001600 count=1 skip=2 of=/system/chunk3.img
adb pull /system/chunk3.img .
Click to expand...
Click to collapse
That looks exactly right, except that normally people use "bs" as a smaller value and "count" and "skip" as a multiple of that value--I'm not sure whether it makes a difference in the real world. (I.e., instead of bs=4096 count=1 skip=1, people normally write bs=1024 count=4 skip=4.)
thekkk said:
I'm not that type of guy to give up, I have the motivation and the time to do it. I will give it at least a try, I have nothing to loose, except time - but that doesnt matter because I wanna have these data's back
The only one problem I see now is that if I read the block step by step and save this, I don't know how I should reassemble all these files. Anyone has an idea? Reading a block and pull it out of the phone isnt the problem
Click to expand...
Click to collapse
You are awesome. I was sure you'd give up.
And using a USB stick is a very good idea, but since you only have one USB port you can't type the commands on your computer using ADB. And yes, ADB should work fine when you're booted into recovery. If CWM doesn't work, you could try TWRP instead. TWRP will actually let you type the commands on the phone's screen (no need for ADB), so you can attach the USB stick.
If the chunks line up exactly (they will if you use dd like you are), on OSX or Linux you can use a program called "cat" to just dump them into one file: "cat a.txt b.txt" prints both files to the screen, so "cat part1 part2 part3 > combined" will join files into a new one (the new file is overwritten, so be careful). I would have to search online for how to join files on windows. If the chunks overlap, this forum post has a short python script that will detect a matching region at the end of one file and the start of the next and join them to a new file.
Note also that this doesn't guarantee your data will be recoverable. I wish you the best of luck, but flash storage is even trickier than hard drives, because due to wear leveling, it's possible the data you want isn't even being exposed as visible to the OS, with different NAND blocks shown instead.
fenstre said:
That looks exactly right, except that normally people use "bs" as a smaller value and "count" and "skip" as a multiple of that value--I'm not sure whether it makes a difference in the real world. (I.e., instead of bs=4096 count=1 skip=1, people normally write bs=1024 count=4 skip=4.)
You are awesome. I was sure you'd give up.
And using a USB stick is a very good idea, but since you only have one USB port you can't type the commands on your computer using ADB. And yes, ADB should work fine when you're booted into recovery. If CWM doesn't work, you could try TWRP instead. TWRP will actually let you type the commands on the phone's screen (no need for ADB), so you can attach the USB stick.
If the chunks line up exactly (they will if you use dd like you are), on OSX or Linux you can use a program called "cat" to just dump them into one file: "cat a.txt b.txt" prints both files to the screen, so "cat part1 part2 part3 > combined" will join files into a new one (the new file is overwritten, so be careful). I would have to search online for how to join files on windows. If the chunks overlap, this forum post has a short python script that will detect a matching region at the end of one file and the start of the next and join them to a new file.
Note also that this doesn't guarantee your data will be recoverable. I wish you the best of luck, but flash storage is even trickier than hard drives, because due to wear leveling, it's possible the data you want isn't even being exposed as visible to the OS, with different NAND blocks shown instead.
Click to expand...
Click to collapse
If that doesnt work on windows I have no problem to get a linux machine. What really causes concern, is that i allready saved multiple chunks with 350mb and also about 4GB and opened them in DiskInternals Linux Reader, but there was ever the same content, multiple folders and 2 files, but nearly everything about on 0kb, so it was nearly empty. Is that only because the files aren't dumped in one file?
What I actually don't get is that your writing 4*1024, but that are just 4096 Bytes, but before you talked about 350MB. I found out that for this I could also use bs=350M (M for megabytes), but I dont know if that really is a problem, couldn't explain to myself why, but you never know.
When I write directly to the USB, I'm also able to scale the size up to 4GB, because of the file-system-restriction. That would go faster. But I will try to firstly create the 60-70 chunks with 350MB and try to dump them into one file. Hope this will get me where I want to go.
thekkk said:
i allready saved multiple chunks with 350mb and also about 4GB and opened them in DiskInternals Linux Reader, but there was ever the same content, multiple folders and 2 files, but nearly everything about on 0kb, so it was nearly empty. Is that only because the files aren't dumped in one file?
What I actually don't get is that your writing 4*1024, but that are just 4096 Bytes, but before you talked about 350MB. I found out that for this I could also use bs=350M (M for megabytes)...
When I write directly to the USB, I'm also able to scale the size up to 4GB, because of the file-system-restriction. That would go faster. But I will try to firstly create the 60-70 chunks with 350MB and try to dump them into one file. Hope this will get me where I want to go.
Click to expand...
Click to collapse
What I wrote was just an example--I'm not actually suggesting you get the dump in 4 KB chunks.
As far as the chunk sizes, you just need to make sure they line up. If you start with a 350 MB chunk that was made with "bs=1M count=350", you can make the second chunk (a bigger one) with "bs=1M skip=350 count=4000". The problem is that since you used exact byte numbers for BS, it's more complicated to get them to line up correctly. For example, 1M is probably 1000000 bytes in this program, but it could also be 2^20 bytes. Basically, chuck size doesn't matter as long as they're properly lined up. Also, I wouldn't worry about the recovery tool failing until you have all or most of the chunks. However, I see that DiskInternals Linux Reader is a filesystem browser, not a recovery tool. You need a recovery tool, since the files are technically deleted (actually, the filesystem is wiped). You need a tool that looks for the data (all bytes), not what the filesystem officially says is present.
fenstre said:
What I wrote was just an example--I'm not actually suggesting you get the dump in 4 KB chunks.
As far as the chunk sizes, you just need to make sure they line up. If you start with a 350 MB chunk that was made with "bs=1M count=350", you can make the second chunk (a bigger one) with "bs=1M skip=350 count=4000". The problem is that since you used exact byte numbers for BS, it's more complicated to get them to line up correctly. For example, 1M is probably 1000000 bytes in this program, but it could also be 2^20 bytes. Basically, chuck size doesn't matter as long as they're properly lined up. Also, I wouldn't worry about the recovery tool failing until you have all or most of the chunks. However, I see that DiskInternals Linux Reader is a filesystem browser, not a recovery tool. You need a recovery tool, since the files are technically deleted (actually, the filesystem is wiped). You need a tool that looks for the data (all bytes), not what the filesystem officially says is present.
Click to expand...
Click to collapse
I'm trying it now with the following:
$ dd if=/dev/block/mmcblk0p37 of=/system/chunk1.img bs=1048576 count=350 skip=350
One sentence i don't understand, what do you mean by "properly lined up"? Are they not properly lined up when i use the above 1048576 Bytes (exactly 1 MB)?
For the recovery tool i will have a look, thanks for the tipp, if i remember correct, there was stated that this also can recover
thekkk said:
I$ dd if=/dev/block/mmcblk0p37 of=/system/chunk1.img bs=1048576 count=350 skip=350
One sentence i don't understand, what do you mean by "properly lined up"? Are they not properly lined up when i use the above 1048576 Bytes (exactly 1 MB)?
Click to expand...
Click to collapse
That's fine. But you were on to something with the USB stick idea--if I were you, I'd much rather make two dump chunks than 60.
What I mean by "lining up" is that this the following two chunks will not line up--they will have a gap between with missing data:
dd if=/dev/block/mmcblk0p37 of=/system/chunk1.img bs=1M count=350 skip=0
dd if=/dev/block/mmcblk0p37 of=/system/chunk2.img bs=1048576 count=350 skip=350
These two chunks will have overlapping data:
dd if=/dev/block/mmcblk0p37 of=/system/chunk1.img bs=1048576 count=350 skip=0
dd if=/dev/block/mmcblk0p37 of=/system/chunk2.img bs=1M count=350 skip=350
It's not an issue if you're starting from chunk 0 and using the same "bs", but if you wanted to keep the chunks you already made (with a very specific size), and continue making 4GB chunks after that, it might be tricky to get bs/count/skip right so the chunks don't overlap with your data and don't skip any, either. This is "lining up" properly.
fenstre said:
That's fine. But you were on to something with the USB stick idea--if I were you, I'd much rather make two dump chunks than 60.
What I mean by "lining up" is that this the following two chunks will not line up--they will have a gap between with missing data:
dd if=/dev/block/mmcblk0p37 of=/system/chunk1.img bs=1M count=350 skip=0
dd if=/dev/block/mmcblk0p37 of=/system/chunk2.img bs=1048576 count=350 skip=350
These two chunks will have overlapping data:
dd if=/dev/block/mmcblk0p37 of=/system/chunk1.img bs=1048576 count=350 skip=0
dd if=/dev/block/mmcblk0p37 of=/system/chunk2.img bs=1M count=350 skip=350
It's not an issue if you're starting from chunk 0 and using the same "bs", but if you wanted to keep the chunks you already made (with a very specific size), and continue making 4GB chunks after that, it might be tricky to get bs/count/skip right so the chunks don't overlap with your data and don't skip any, either. This is "lining up" properly.
Click to expand...
Click to collapse
Thanks for explenation
So i have my 77 .img chunk-files all on my pc. Btw, Windows does have "cat" also, but only in Windows Powershell, and it's soooo slow... and somehow the combined files are bigger I'll use it in linux, better approach i guess
After I have my final image, I mount that into my ubuntu machine and then try to recover, right? You said something about a "valid EXT4" filesystem, what do I have to pay attention for this? Unfortunatly I'm not a linux-Guru, but should be able to handle it with some help. I think first I try the recover tool from ubuntu that is built-in, because I havn't searched for an alternative. I don't think that i need a special one explicit for Android-files?
Many thanks that you take time and try to help me :good: , I don't think I'm wide away from my goal now. I hope that I'm a lucky guy and I can restore, at least, some files.
thekkk said:
So i have my 77 .img chunk-files all on my pc. Btw, Windows does have "cat" also, but only in Windows Powershell, and it's soooo slow... and somehow the combined files are bigger I'll use it in linux, better approach i guess
Click to expand...
Click to collapse
if you want to use windows to combine multiple files, in a normal command prompt:
copy /b file1.img + file2.img + file3.img [+ etc] outputfile.img
@fenstre, couldn't he have mounted a 64GB OTG Stick and dd the entire partition there in one go?
nkk71 said:
if you want to use windows to combine multiple files, in a normal command prompt:
copy /b file1.img + file2.img + file3.img [+ etc] outputfile.img
@fenstre, couldn't he have mounted a 64GB OTG Stick and dd the entire partition there in one go?
Click to expand...
Click to collapse
Thanks that with windows-command promt worked without any problem
Because of the OTG Stick, the filesystem has a restriction of 4GB files, so I can't dd the entire partition in one go. And I also have the partition now in one .img file. But now I'm really stucked at how to recover this, with something from Windows or Linux? Tried DMDE, it showed me the partition but I couldn't really find some old files
Someone know's whats possible and which programms do you suggest? I have a EXT4 .IMG file with about 27GB and I wanna restore wiped files.
nkk71 said:
@fenstre, couldn't he have mounted a 64GB OTG Stick and dd the entire partition there in one go?
Click to expand...
Click to collapse
Yep, I'm not so smart. Even a 32 GB stick is big enough. He would still need to reformat the stick as EXT3/4 to get around the 4GB size limit, then he'd have to jump through hoops to read the data on his computer.
thekkk said:
Someone know's whats possible and which programms do you suggest? I have a EXT4 .IMG file with about 27GB and I wanna restore wiped files.
Click to expand...
Click to collapse
I've never used one--I just searched for "ext4 undelete". I suspect that Linux will have more options than Windows. This page also lists several utilities you can try:
https://wiki.archlinux.org/index.php/File_Recovery
Let us know how it goes!
Related
Ive used programs like TestDisk to get pictures from a "formatted" flash card. I forgot to backup my SMS messages before doing a wipe (backed up everything...). Is there a way I can access the phones built-in memory using software like TeskDisk?
http://www.cgsecurity.org/wiki/TestDisk
androidmonkey said:
Ive used programs like TestDisk to get pictures from a "formatted" flash card. I forgot to backup my SMS messages before doing a wipe (backed up everything...). Is there a way I can access the phones built-in memory using software like TeskDisk?
http://www.cgsecurity.org/wiki/TestDisk
Click to expand...
Click to collapse
Did you do a nandroid? if not then I am pretty sure the answer is no.
That's like formatting my HDD then asking if can i recover all those programs.
Ace42 said:
That's like formatting my HDD then asking if can i recover all those programs.
Click to expand...
Click to collapse
Umm... you do know that when you format your hard drive you can still get some of the data back, right? Unless you use a secure erase program, the data is still on the hard drive. The same goes for flash memory. Format or delete images from your flash card and use TestDisk to see what you can get back. If you havent written anything to the drive, chances are you can get it all back. For your sake, I hope you securely wipe your hdds before throwing/giving them away. That goes for everyone.
Back to the topic. I just want to know how to access the built-in memory where this stuff is stored. Some type of developer tool maybe?
I'd personally like to know what this really has to do with development. You may be looking for some "developer tool" to recover lost data, but this adds nothing to any development going on or anything.
grandomegabosses said:
I'd personally like to know what this really has to do with development. You may be looking for some "developer tool" to recover lost data, but this adds nothing to any development going on or anything.
Click to expand...
Click to collapse
The chances of such a tool existing would be known by the smart developers/coders in this forum
androidmonkey said:
The chances of such a tool existing would be known by the smart developers/coders in this forum
Click to expand...
Click to collapse
Check the rules of the forum. This section isn't meant to ask developers something. It's meant for development.
I would try booting into recovery and then use adb to manually mount your partitions. I would assume you just need to mount the /data partition.. I know this works on my Magic so just check and make sure that you have the right block device if your running on a Dream!
1. open adb shell
2. make a new directory with mkdir "name of new dir"
3. mount /data with mount -t yaffs /dev/block/mtdblock5 "name of new dir"
4. open new terminal/command prompt and use adb pull command as follows
to bring the data partition over to your computer:
adb pull "name of new dir" "name of file to be placed on computer"
5. now see if you have any files and attempt recovery of your sms database
Good Luck
[EDIT] Oh yeah the other guy's are right you should post this type of question in General next time. Fortunately I'm not a **** so I posted how I would try to rescue my stuff and remember Nandroid would have saved your ass
nrmerritt said:
I would try booting into recovery and then use adb to manually mount your partitions. I would assume you just need to mount the /data partition.. I know this works on my Magic so just check and make sure that you have the right block device if your running on a Dream!
1. open adb shell
2. make a new directory with mkdir "name of new dir"
3. mount /data with mount -t yaffs /dev/block/mtdblock5 "name of new dir"
4. open new terminal/command prompt and use adb pull command as follows
to bring the data partition over to your computer:
adb pull "name of new dir" "name of file to be placed on computer"
5. now see if you have any files and attempt recovery of your sms database
Good Luck
[EDIT] Oh yeah the other guy's are right you should post this type of question in General next time. Fortunately I'm not a **** so I posted how I would try to rescue my stuff and remember Nandroid would have saved your ass
Click to expand...
Click to collapse
Thanks nrmerritt, ill give it a try. How do I get root in adb shell via windows? When I try to mkdir, it says "Read-only file system"
Also, I do have a Dream (G1), any ideas which block to use?
Thanks
Are you using Amon_Ra's latest recovery? On my phone when I boot into recovery mode and connect with adb it's already in a root environment.
About the block device I would try the one I posted. You can always just do an "ls" command on the new directory you mounted it on before you copy it to the computer so can you see if/what files are possibly still left.
As a last resort effort you could also try the "dd" command to make an image of the partition while it's still on the phone then copy that to your computer with adb.
One more thing..If you did a wipe and rebooted your phone, your chances are not very good for recovery since the phone would have written a whole bunch of files to the data partition on first boot into Android. Side note, maybe one day Google will incorporate messages into sync and improve our lives a little.
I don't want to dual-boot, even, just have a nice "normal" Nookie Froyo install on eMMC. I've seen several allude to the fact that it worked for them but no reviews of how they did it. I've backed up my 2.1 install with Clockwork so I'm not really worried about that.
TIA.
It's quite simple actually. All you need is basic knowledge of adb.
All disclaimers apply, I'm not responsible for any damage. Just know that mine is running on internal partitions. And the SD does mount too!
Before doing anything, I would recommend applying a dd from your partitions to your pc.
With, for example on mmcblk0p1 (boot) adb: dd if=/dev/block/mmcblk0p1 of=boot.img
You should do that for each partition to be safe (0p1 to 0p8).
All the following commands can be execute one after one, the separations are only there to makes things a bit more clear.
Then,
Boot to a working Nookie (NF) with your uSD fresh from burning, without any google apps, and without any uSD damaged errors.
Empty your internal system and copy uSD system over, by doing:
- adb shell mount -o remount,rw /dev/block/mmcblk1 / (---there is a space after the 1---)
- adb shell
- mkdir tmpfolder
- mount /dev/block/mmcblk0p5 tmpfolder
- cd tmpfolder
- rm -r * (---note that there is space after the r---)
- cd ..
- cp -r system/* tmpfolder (---this will take a few minutes---)
- umount tmpfolder
Click to expand...
Click to collapse
Then, you need to boot push the attached files (bottom of post) except for the 2 vold files to your boot partition: mmcblk0p1. Unzip, copy content, not zip.
You could very well replace uImage with the new Quickie overclocked uImage for froyo (see dev thread).
To push attached files to boot, do:
- mount /dev/block/mmcblk0p1 tmpfolder
- exit
- adb push [folder-containing-4-attached-files-except-vold.fstab] tmpfolder
- adb shell
- umount tmpfolder
Click to expand...
Click to collapse
I would also recommend erasing all your data. But that's up to you, if you want to keep your data on it. In any case, you can revert back with the data.img you created above . So next part you could skip, haven't tried skipping personally:
Non mandatory, but you could do:
- mount /dev/block/mmcblk0p6 tmpfolder
- cd tmpfolder
- rm -r *
- cd ..
- umount tmpfolder
Click to expand...
Click to collapse
Then you need to push vold.fstab and vold.conf (unzip volds, copy content) to system/etc
Copy vold's to system/etc:
- mount /dev/block/mmcblk0p5 tmpfolder
- exit
- adb push [folder-with-vold's] tmpfolder/etc/
- adb shell
- umount tmpfolder
- rm -r tmpfolder
- exit
Click to expand...
Click to collapse
Then shut down, remove uSD, and boot.
Again, you can choose to push the Quickie uImage, I you prefer, but the accelerometer doesn't work with it at the moment. The 950 kernel does sometimes crash on boot, but once booted is quite stable.
I think that's all folks. I could have been a bit vague at some times, but this should work. And if you made your imgs as recommended, you're bullet proof.
To revert back to initial state with img files, you need to copy files to sdcard and then dd:
- adb shell mount -o remount,rw /dev/block/mmcblk1p1 sdcard
- adb push XXX.img sdcard (--could take a few minutes--)
- dd if=XXXX.img of=/dev/block/mmcblk0pX
Click to expand...
Click to collapse
Do that for each partition.
For those who don't feel up to the task, I could make a CWR flashable zip file of all this. The only thing is, CWR dosen't boot on Nookie just yet. So you couldn't restore with a zip after the change.
[Before doing anything, I would recommend applying a dd from your partitions to your pc.
With, for example on mmcblk0p1 (boot) adb: dd if=/dev/block/mmcblk0p1 of=boot.img
You should do that for each partition to be safe (0p1 to 0p8).
[/QUOTE]
I am a little confused here. What are the names of the 7 other partitions? Thanks, Great guide btw!
See here.
Do you see improved speed and touch response running nookie from emmc?
im getting a "No such file or directory" error after "adb push [folder-with-vold's] tmpfolder/etc"
I created the directory but now it looks like i am stuck at the landscape android splash screen on boot...
any ideas? I am attempting to redo the whole process again just incase i missed something.
Sorry, there's a slash after etc.
Make sure you've copied the systen files, with "ls" inside tmpfolder where you copied system. Should be a etc folder there.
Sam
to the op: I'm not knocking you here, but do you have a basic idea of generic linux file hierarchy or operations in general? Getting a basic grasp on working with files in a linux terminal will make all of these operations make a lot more sense, since most "adb shell" commands are basic linux commands.
FastCR said:
to the op: I'm not knocking you here, but do you have a basic idea of generic linux file hierarchy or operations in general? Getting a basic grasp on working with files in a linux terminal will make all of these operations make a lot more sense, since most "adb shell" commands are basic linux commands.
Click to expand...
Click to collapse
Thanks but I don't see how that comment adds anything here.
Looks like the issue is above commands copy the actual system folder (not the contents of the folder) To the root of the partition. ls shows the folder "system" not the contents including etc. They are inside the folder but if the partition is mounted as system then the folder is redundant. Will check copying the contents and see if that helps.
Once I get it working in will post back to let others know
**** in the first block of code replace
Code:
- cp -r system tmpfolder (---this will take a few minutes---)
with
Code:
- cp -r system[B]/*[/B] tmpfolder (---this will take a few minutes---)
many thanks!
FastCR said:
to the op: I'm not knocking you here, but do you have a basic idea of generic linux file hierarchy or operations in general? Getting a basic grasp on working with files in a linux terminal will make all of these operations make a lot more sense, since most "adb shell" commands are basic linux commands.
Click to expand...
Click to collapse
Why would you go out of your way to say that? It's not constructive. As a junior member with three posts and 0 thanks after a year and a half, sharpen your teeth here at XDA before you act like a big shot.
Right thanks. Changed it.
Has it worked for you?
Sent from my HTC Desire using XDA App
samuelhalff said:
You could very well replace uImage with the new Quickie overclocked uImage for froyo (see dev thread).
Click to expand...
Click to collapse
Are you certain on this part? Last I read in that thread, Froyo needs a different minimum kernel.
UPDATE: Nevermind, I missed this updated effort.
Homer
Well, last time I checked, my NC was running at 950 on froyo with setcpu.
Check the forum. There's a nookie version of quickie. Except accelerometer doesn't work..
First, huge thanks to the second poster - great guide! Can we sticky this?
Second, yes I know what dd does, etc, I've been working with Linux for about ten years . I just don't know the ins and outs of embedded devices yet.
samuelhalff said:
Right thanks. Changed it.
Has it worked for you?
Sent from my HTC Desire using XDA App
Click to expand...
Click to collapse
yeah i was up till 4am last night but got it working. first i tried to use my existing nf sd card... bad idea. would boot from emmc to the touch android screen to begin, but could not get past. i assume it was the issue on nookdevs because wifi was not enabled. so i removed the setupwizard.apk but somehow bricked and was unable to boot from emmc. so i took the following steps to get things working properly:
1. reimage boot and system from the stock 1.0.1 images and reset the nook to stock, didnt even touch. at the intro screen i just powered it off.
2. next i took a fresh nf sdcard and run steps from your post(with the correction to copy system contents)
3. from there i had a working nf from sdcard! i did my tweaks (google apps, market fix and button remapping from nookdevs froyo tips)
i might to put together a post with a more verbose set of instructions for a one stop froyo shop but if i do i will be sure to give you credit for your contribution.
thanks again!
Hi,
Second, yes I know what dd does, etc, I've been working with Linux for about ten years . I just don't know the ins and outs of embedded devices yet.
Click to expand...
Click to collapse
Well, that's a nice contrast. I've been working on Linux/Android for about 2 months now
I should have mentioned that the NF uSD Card must be a newly burnt image, without all the nookie tips added to it. Of course, your Google framework will crash if you port it without your data.
By the way, there's a nice trick to get past the numb android interface, simply touch every corner of the screen, starting with top left and going clockwise. You'll then be sent the your home screen, and from there you'll log on to google account again.
I think the best way of doing it would to create a flashable .zip, which I'll make tonight if I find the time and if people are really interested. But don't forget CWR dosen't work on nookie for the time being. The only way back would be through adb.
So, does anyone wish to have a flashable zip of this? Or will it be a waist of time?
Sam
samuelhalff said:
Hi,
Well, that's a nice contrast. I've been working on Linux/Android for about 2 months now
I should have mentioned that the NF uSD Card must be a newly burnt image, without all the nookie tips added to it. Of course, your Google framework will crash if you port it without your data.
By the way, there's a nice trick to get past the numb android interface, simply touch every corner of the screen, starting with top left and going clockwise. You'll then be sent the your home screen, and from there you'll log on to google account again.
I think the best way of doing it would to create a flashable .zip, which I'll make tonight if I find the time and if people are really interested. But don't forget CWR dosen't work on nookie for the time being. The only way back would be through adb.
So, does anyone wish to have a flashable zip of this? Or will it be a waist of time?
Sam
Click to expand...
Click to collapse
I would love a flashable .zip. I think many others would as well.
starkruzr said:
I would love a flashable .zip. I think many others would as well.
Click to expand...
Click to collapse
Can't wait for a flashable zip. Maybe even some cm7 release candidates would make me real happy.
Sent from Nooted NookColor using XDA App
I just switched over to android from maemo and all I have to say is, wheres the linux???
Anyways, I'm trying to get a few things working and the environment si so different. For example when attempting to run clockwork mod in xterm I type the following:
dd if=/dev/block/mmcblk0p6 of=/sdcard/mmcblk0p6.backup bs=4096
to which I am returned:
2560+0 records in
2560+0 records out
10485760 bytes transferred in 1.461 secs (7177111 bytes/sec)
So I assume everything is going as planned, then I type:
dd if=/data/recovery.img of=/dev/block/mmcblk0p6 bs=4096
to which I am greeted with:
/data/recovery.img: cannot open for read: no such file or directory
ummmm.... what?
and no apt-get?
Can someone direct me somehere t make this transition less, alien? I was hoping I can try and get a meego style rom going for android but alas, I'm stuck at the baby steps...
ieuo said:
I just switched over to android from maemo and all I have to say is, wheres the linux???
Anyways, I'm trying to get a few things working and the environment si so different. For example when attempting to run clockwork mod in xterm I type the following:
dd if=/dev/block/mmcblk0p6 of=/sdcard/mmcblk0p6.backup bs=4096
to which I am returned:
2560+0 records in
2560+0 records out
10485760 bytes transferred in 1.461 secs (7177111 bytes/sec)
So I assume everything is going as planned, then I type:
dd if=/data/recovery.img of=/dev/block/mmcblk0p6 bs=4096
to which I am greeted with:
/data/recovery.img: cannot open for read: no such file or directory
ummmm.... what?
and no apt-get?
Can someone direct me somehere t make this transition less, alien? I was hoping I can try and get a meego style rom going for android but alas, I'm stuck at the baby steps...
Click to expand...
Click to collapse
For your error: You need to first push a recovery.img to /data before running: # dd if=/data/recovery.img of=/dev/block/mmcblk0p6 bs=4096.
apt-get indeed does not work in android.
The best I could offer you is Google or searching the forums here on xda. For a basic rundown of the android os here a good place to start: http://developer.android.com/index.html
Thanks, honestly I guess I was just hoping for a much more linux feel to the commands.
I'm assuming I MUST push with ADB? I can't just drag and drop?
Sorry for such a basic question, I just thought at lest a few thigs would be the same if it had the linux kernel. Meh, such is tech.
Wow, so I found designgears thread, followed each step exactly and referred to the dev site and I just don't get it. It seems so simple even.
From what I can tell push should do the exact same as a drop to root sd (or wherever else I specify).
When I push in ADB, it just runs ADB with no signs of any push event happening. Ok I've seen things like that before when working with maemo.
Then if I move forward, I get the same resut as if I had just dropped into my root sd, which I must assume works, because xterm and ADB give the same output. Then I go to flash, and errors galore.
I have all the drivers, and have triple checked the android dev site plus a vast number of searches on google and here.
My mistakes HAVE to be on some basic level. Either wrong directory or wrong pathname. However, I check, recheck, and the triple reference my coding, followed by checking again. If I can't do a simple push and flash I can't even start anything with android.
I'm beggining to think I should have just posted in a different area as my single simple question goes much deeper than I thought....
If you can... post a very detailed run down of exactly what u did and the commands u used... see if we cant isolate the error
Sent from my LG Thrill 4G...
So just to clarify, are you using ADB or xterm ?
And push does the same as drag drop, but with normal sdcard mount, you do not have access to \system, \data etc. you only have access to \sdcard. So its useful to use adb is you want to push files to any of these directories.
ieuo said:
Wow, so I found designgears thread, followed each step exactly and referred to the dev site and I just don't get it. It seems so simple even.
From what I can tell push should do the exact same as a drop to root sd (or wherever else I specify).
When I push in ADB, it just runs ADB with no signs of any push event happening. Ok I've seen things like that before when working with maemo.
Then if I move forward, I get the same resut as if I had just dropped into my root sd, which I must assume works, because xterm and ADB give the same output. Then I go to flash, and errors galore.
I have all the drivers, and have triple checked the android dev site plus a vast number of searches on google and here.
My mistakes HAVE to be on some basic level. Either wrong directory or wrong pathname. However, I check, recheck, and the triple reference my coding, followed by checking again. If I can't do a simple push and flash I can't even start anything with android.
I'm beggining to think I should have just posted in a different area as my single simple question goes much deeper than I thought....
Click to expand...
Click to collapse
Well I would post all of that but as of today the 3d option in video player went missing so I did a factory reset and as the phone rebooted I was in clockwork mod. I can only assume my code was fine and that something is odd with my phone. Might have to get a replacement this weekend.
I currently have my touchpad split (16 GB to each) between the stock WebOS and an Ubuntu chroot partition. I don't really use the Ubunut partition all that often and was wondering if there is a way to use that existing partition for a CM install. All of the CM install instructions I have seen involve working with the single stock partition. Is there a way for me to install and dual boot to a CM on my old ubuntu partition, or do I have to Doctor the device back to it's original partition? I would prefer to give CM a full 16 GB to work within (I think from what I read the basic install gives it 1.5 GB). Thanks for the help.
the answer is no. the ubuntu chroot that you setup used a ext3fs. you will need to remove that store-ext3fs partition, extend your logical volume /dev/store/media to use all of the free space, and resize your fat32 partition back to its original size, which should be approx 26G. all your commands such as lvresize, resizefat, lvscan, df, mount, umount etc. can all be done through novaterm.
after you get your volume back to size then you can go ahead and throw the android of your choice on it. if you need detailed help let me know and ill post a more detailed walk through.
Thanks a lot for the response. If you have a method that I could wipe out the ubuntu partition without doctoring i would appreciate it. If I do not have to loose all of my WebOS stuff it would be much more convenient. I am reasonably familiar with linux command line, but less so with novaterm and WebOS structure.
QUOTE=funkbuqet;35322160]Thanks a lot for the response. If you have a method that I could wipe out the ubuntu partition without doctoring i would appreciate it. If I do not have to loose all of my WebOS stuff it would be much more convenient. I am reasonably familiar with linux command line, but less so with novaterm and WebOS structure.[/QUOTE]
Have you considered Taylor on preware http://forums.webosnation.com/webos...partition-filesystem-editor-beta-testing.html .
Features include:
Unmount Partition
Check Filesystem
Repair Filesystem
Corrupt Filesystem
Resize Filesystem
Resize Partition
Mount Partition
Create Partition
Delete Partition
Install instructions can be found here http://en.m.webos-internals.org/wiki/Testing_Feeds?wasRedirected=true . It may be just what you are looking for.
funkbuqet said:
Thanks a lot for the response. If you have a method that I could wipe out the ubuntu partition without doctoring i would appreciate it. If I do not have to loose all of my WebOS stuff it would be much more convenient. I am reasonably familiar with linux command line, but less so with novaterm and WebOS structure.
Click to expand...
Click to collapse
http://www.webos-internals.org/wiki/Application:MetaDoctor#How_to_remove_the_ext3fs_partition
heres a link to help you step by step.
when you get to the resize part of this guide it might get a little confusing. there is an easier way to extend the logical volume size and then resizefat.
instead of writing down the size of the ext3fs before you remove it and then adding that number to the size of the store-media you can just remove the ext3fs then run
# lvresize -l +100%FREE /dev/mapper/store-media
you can check to see if it added all the free space to the logical volume with
# lvscan and/or #lvdisplay
then you can run
# resizefat /dev/mapper/store-media 26G
this will resize the fatpartition to 26Gig which is right about what it should be. you can fine tune it down to the M (megabyte) or even the K (kilobyte) to make sure you get every last bit of space if you want. just make sure that you dont try to resize fat to a size that is larger than the logical volume. if what i just said is confusing then just follow the guide in the link exactly.
one more thing. before you start making any changes run
# cat /etc/fstab
if yo usee a line like.. /dev/mapper/store-ext3fs /media/ext3fs auto noatime 0 0
then you need to remove it before going too far other wise it will attempt to automatically mount the ext3fs partition on reboot because it doesnt know that you removed it.
i hope this helps some, i've had a few beers and got a little buzz going on so if im not making sense i apologize.
haxin said:
http://www.webos-internals.org/wiki/Application:MetaDoctor#How_to_remove_the_ext3fs_partition
heres a link to help you step by step.
when you get to the resize part of this guide it might get a little confusing. there is an easier way to extend the logical volume size and then resizefat.
instead of writing down the size of the ext3fs before you remove it and then adding that number to the size of the store-media you can just remove the ext3fs then run
# lvresize -l +100%FREE /dev/mapper/store-media
you can check to see if it added all the free space to the logical volume with
# lvscan and/or #lvdisplay
then you can run
# resizefat /dev/mapper/store-media 26G
this will resize the fatpartition to 26Gig which is right about what it should be. you can fine tune it down to the M (megabyte) or even the K (kilobyte) to make sure you get every last bit of space if you want. just make sure that you dont try to resize fat to a size that is larger than the logical volume. if what i just said is confusing then just follow the guide in the link exactly.
one more thing. before you start making any changes run
# cat /etc/fstab
if yo usee a line like.. /dev/mapper/store-ext3fs /media/ext3fs auto noatime 0 0
then you need to remove it before going too far other wise it will attempt to automatically mount the ext3fs partition on reboot because it doesnt know that you removed it.
i hope this helps some, i've had a few beers and got a little buzz going on so if im not making sense i apologize.
Click to expand...
Click to collapse
That look pretty easy. Thanks for all of the help I will try this when I get home this evening.
Everything seems to have worked fine. Thanks for all your help.
basic question - If i use Acme3 to install CM9 or 10, where does it install and can I change how much disk space is allocated to android?
funkbuqet said:
Everything seems to have worked fine. Thanks for all your help.
basic question - If i use Acme3 to install CM9 or 10, where does it install and can I change how much disk space is allocated to android?
Click to expand...
Click to collapse
you dont need to worry about that really. what happens is when you install Cyanogenmod 9 for example on the touchpad it creates 3 seperate logical volumes /dev/store/cm-system [304 MB] approx
/dev/store/cm-cache [200 MB] approx /dev/store/cm-data [1.50 GB] approx for a total of just about 2GIGs of space. cyanogenmod now thinks that the 1.5gigs is the internal storage and that the rest of the media partition is "sdcard" even though technically all of it is internal storage. this way you dont have to take any storage away from webos and webos wont take any storage away from android. its shared.
once you have android installed 1.5gigs of space is usually plenty to install all the apps you want, but you can always choose to install apps to sdcard as well. youll see when you get everything up and running and you start exploring the file system with a decent browser like es file explorer or root file browser by jrummy. so basically both operating systems will have access to all of the storage. hope this helps.
Excellent. Thanks again for all your help.
Sent from my SPH-L710 using xda app-developers app
Hello
It wasn't like this before , but now I got only 12 gigabytes of which 7 gigabytes are used and the rest is free.
what happened to 6 gigabytes of my storage?
even factory reset didn't do any good.
what should I do? (I have boot loader installed on my device )
Pictures, please. We need to first confirm your problem, but obviously, we can't reproduce something like this. What version of the tablet did you buy, 16 or 32?
Here it is.
device kfhd 16 gb 7.3.0
help please
Code:
adb shell su -c "du"
find out what is using up your storage space
The rom itself probably takes up that remaining space.
This is a Kinology HD using XDA Premium
soupmagnet said:
Code:
adb shell su -c "du"
find out what is using up your storage space
Click to expand...
Click to collapse
By this code?
It says " sh: du: not found "
Krsmqn said:
The rom itself probably takes up that remaining space.
This is a Kinology HD using XDA Premium
Click to expand...
Click to collapse
when I get my backup it's no more that 800 mb.
hamidwt said:
By this code?
It says " sh: du: not found "
Click to expand...
Click to collapse
Oh yeah, you need busybox installed.
soupmagnet said:
Oh yeah, you need busybox installed.
Click to expand...
Click to collapse
Ok installed it , what now?
could you explain?
hamidwt said:
Ok installed it , what now?
could you explain?
Click to expand...
Click to collapse
Ok
The 'du' (disk usage) command will give you a more detailed and accurate layout of your current disk's usage. You can enter the command as it is or append a specific directory to only get the usage of that directory.
i.e...
Code:
adb shell su -c "du /data"
or
Code:
adb shell su -c "du /data/media/Download"
You can make the output human readable by adding the '-h' flag to the command...
Code:
adb shell su -c "du -h"
You can also get a grand total for a directory by adding the '-c' flag...
Code:
adb shell su -c "du -h -c"
With this, you can figure out what, if anything, is taking up that much storage or if there is an error in how the OS is actually reporting it.
Using this command I got this
does this mean 12.7 gb is used up ? or is this the whole disk space?
either way it doesn't add up.
In my kindle it shows that the whole disk space is 12.6 gb and 6.2 of this space is taken.
Okay, let's make it simple.
Code:
adb shell su -c "du -h -c -d 1"
That will only display directories one level deep. It will make it easier for you to identify which of the directories is using up so much space. Then you can go from there.
If it is the data directory that seems to be the problem, edit the command as such...
Code:
adb shell su -c "du -h -c -d 1 /data"
...and so on and so forth until you find the source of the problem.
The 'du' command will only display your usage, not the entire disk size, so something definitely seems off about your output.
Thank you man , i really appericiate your help.
Apparently we found the problem , I dont know how it's possible though ! but it seems that this 5.7gb which is in the sdcard and at the same time is not in the sdcard is the problem! now how am i gonna fix it?
Try /mnt/sdcard instead of /sdcard
there is an exact copy of my sdcard in this data/media folder
which one is culprit ?
hamidwt said:
there is an exact copy of my sdcard in this data/media folder
which one is culprit ?
Click to expand...
Click to collapse
'/mnt/sdcard' and '/data/media' are the same thing so subtract the total of '/mnt/sdcard' from your grand total.
I only have 1.6GB used from my internal storage, and 'du' does add the two directories ('/mnt/sdcard' & '/data/media') together, but my storage as reported by the Kindle still only shows 1.6GB used, so I'm guessing there is something off about your OS. Are you running a custom ROM like Kinology?
What exactly is the problem here? First, the image shows that you have 7g free, not used. Second, the du output shows that you have several "culprits" as is pretty normal. There's a large chunk in books, another large chunk in movies, and some smaller, but not insignificant, chunks in music, download, and media. Additionally, there appears to be a lot of data on the "root" of the sdcard (not in any subfolder).
If you're asking about the number 12 itself, that's all you get. The Kindle has 16g, of which 4 is reserved for Android.
psych0phobia said:
What exactly is the problem here? First, the image shows that you have 7g free, not used. Second, the du output shows that you have several "culprits" as is pretty normal. There's a large chunk in books, another large chunk in movies, and some smaller, but not insignificant, chunks in music, download, and media. Additionally, there appears to be a lot of data on the "root" of the sdcard (not in any subfolder).
If you're asking about the number 12 itself, that's all you get. The Kindle has 16g, of which 4 is reserved for Android.
Click to expand...
Click to collapse
The problem is that my Kindle says i have 12gb storage, it wasnt like this before, at least now i know what the problem is, i have about 6 gb data including music videos and etc but what has happened here is that there is another copy of this 6gb data, so while i have 6gb data it has taken 12gb of my disk.
And where does the kernel get stored?
This is a Kinology HD using XDA Premium
soupmagnet said:
'/mnt/sdcard' and '/data/media' are the same thing so subtract the total of '/mnt/sdcard' from your grand total.
I only have 1.6GB used from my internal storage, and 'du' does add the two directories ('/mnt/sdcard' & '/data/media') together, but my storage as reported by the Kindle still only shows 1.6GB used, so I'm guessing there is something off about your OS. Are you running a custom ROM like Kinology?
Click to expand...
Click to collapse
So they are the same.
No im not using custom rom or kinology. I just installed bootloader and stuff.
Is there anyway i can get rid of the whole data, and start fresh? Or if i wait until cm10 is out, would that fix this?
I have factory cable.