Hi,
I've followed the instructions on how to build froyo on Ubuntu 10.04 32Bit,
I had to disable gdb in /buildroot/local/g8_arm/g8_arm.config
or shot make -i world
make menuconfig breaks everything
....so edit configs by hand.....
then it builds fine.....
thanks to his patch:
www android-hilfe de /android-os-entwicklung-customize/4801-kernel-module-kompilieren-erster-versuch.html
it runs (else unionfs complains about missing symbols..)
Code:
adb push unionfs.ko /data/local/tmp
adb push ntfs.ko /data/local/tmp
I've created a second 2GB ext3 partition on my sdhc class6
Code:
insmod /data/local/tmp/unionfs.ko
mount /dev/block/vold/179:18 /data/newroot
mount -t unionfs -o dirs="/data/newroot/rootfs=rw:/system=ro" unionfs /system
and now i've things like a writeble host file .....
it runs since yesterday here - and is fine.
jens
jensbln said:
Hi,
I've followed the instructions on how to build froyo on Ubuntu 10.04 32Bit,
I had to disable gdb in /buildroot/local/g8_arm/g8_arm.config
or shot make -i world
make menuconfig breaks everything
....so edit configs by hand.....
then it builds fine.....
thanks to his patch:
www android-hilfe de /android-os-entwicklung-customize/4801-kernel-module-kompilieren-erster-versuch.html
it runs (else unionfs complains about missing symbols..)
Code:
adb push unionfs.ko /data/local/tmp
adb push ntfs.ko /data/local/tmp
I've created a second 2GB ext3 partition on my sdhc class6
Code:
insmod /data/local/tmp/unionfs.ko
mount /dev/block/vold/179:18 /data/newroot
mount -t unionfs -o dirs="/data/newroot/rootfs=rw:/system=ro" unionfs /system
and now i've things like a writeble host file .....
it runs since yesterday here - and is fine.
jens
Click to expand...
Click to collapse
For morons like me what does that mean....root access??
Sorry if that is a dumb question
@mothy
so far, temporary root with writable /system directory
So just to be clear. Do you replace the kernel at all?
And do you have to mount the sd partition every time you boot up?
It's for the original Archos Kernel 2.6.29-omap1
Code:
# lsmod
ntfs 213028 0 - Live 0xbf276000
unionfs 74364 1 - Live 0xbf211000
this means you have to
temproot+"re"mount
the writable places, maybe soft-reboot (i use LCDDensity, it's soft-rebooting) and all your're changes are magicly there
instead of using sd, you can just create /data/newroot and let the things go there
Code:
# df -h
/dev/block/mmcblk0p4 299.4M 205.1M 78.9M 72% /data
i don't see any new rom's soon, unless we get a new bootloader, Archos uses mmcblk0 (an SD-Card device) and not mtd, so i think we can forget all that fastboot, flash_unlock mtd stuff.
this is very annoying, maybe i'm wrong,
but it looks like they don't want us to reflash the device :-(
unionfs usually need a own kernel, but the "ugly patches" make it run with the archos gen8 kernel
So i use temproot, gscript, LCDDensity after each reboot - and have all my settings back, apps like adsfree runs...
jens
forgive my lack of knowledge but you keep mentioning ntfs in the code fragments but you havent actually said that this is giving you ntfs support. does your kernal changes allow for reading ntfs volumes?
yes, i hope so, but i havn't tested it until now, minimum is that you can mount ntfs volumes by hand - but maybe it's automounting....
i want test a HD movie from sd, but mine doesnt fit in 4Gig (fat)
jens
i've connected same ntfs disk and:
Code:
usb 2-1:1.0: uevent
usb-storage 2-1:1.0: usb_probe_interface
usb-storage 2-1:1.0: usb_probe_interface - got id
devdb: devpath usb-musb_hdrc-1 not found
scsi0 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 2
usb-storage: waiting for device to settle before scanning
/mnt/flash/releases/G8A/v2.0.53-r80341/arcbuild/linux/drivers/usb/core/inode.c: creating file '002'
hub 2-0:1.0: state 7 ports 1 chg 0000 evt 0002
hub 2-0:1.0: port 1 enable change, status 00000503
scsi 0:0:0:0: Direct-Access SAMSUNG HM160HI PQ: 0 ANSI: 2
sd 0:0:0:0: [sda] 312581808 512-byte hardware sectors: (160 GB/149 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 38 00 00 00
sd 0:0:0:0: [sda] Assuming drive cache: write through
sd 0:0:0:0: [sda] 312581808 512-byte hardware sectors: (160 GB/149 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 38 00 00 00
sd 0:0:0:0: [sda] Assuming drive cache: write through
sda: sda1
sd 0:0:0:0: [sda] Attached SCSI disk
usb-storage: device scan complete
FAT: bogus number of reserved sectors
VFS: Can't find a valid FAT filesystem on dev sda1.
hub 2-0:1.0: state 7 ports 1 chg 0000 evt 0002
hub 2-0:1.0: port 1, status 0100, change 0001, 12 Mb/s
usb 2-1: USB disconnect, address 2
usb 2-1: unregistering device
usb 2-1: usb_disable_device nuking all URBs
usb 2-1: unregistering interface 2-1:1.0
same things more need to be done, a trick could be having a small fat partition, so the system has it's sda1 as fas as expecting .....
jens
After restore to original stock 6.2.2 from TWRP, my KF is stucked in Kindle Fire logo. ADB on but always face exec system/bin/sh failed so I already made factory cable and put KF into fastboot successfully.
I tried to install TWRP again successfully but when I tried to upgrade FFF to latest version by running
Code:
fastboot -i 0x1949 flash bootloader u-boot.bin
I got the message FAILED, partition does not exist.
To make clear my partition is ok or not, I repeated TWRP installation and let it stay in Install Complete phase to go to recovery with ADB.
I run the command
Code:
adb shell
~# parted /dev/block/mmcblk0
And the result is
Code:
GNU Parted 1.8.8.1.179-aef3
Using /dev/block/mmcblk0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted)
next I enter
Code:
print
but nothing happen and it seem that print command stuck.
Anyone please kindly advise what I should do next in order to recover my bricked KF ? Thank you very much
maybe this helps:
http://forum.xda-developers.com/showpost.php?p=22401099&postcount=2
follow the links also ...
good luck !
Thank you for your advice, I tried to follow the link and tried to run
Code:
fastboot -i 0x1949 boot bootloader u-boot.bin
I get failed, cannot load bootloader
but if I run
Code:
fastboot -i 0x1949 boot u-boot.bin
The result is
Code:
C:\kfu\tools>fastboot -i 0x1949 boot u-boot.bin
creating boot image...
creating boot image - 219136 bytes
downloading 'boot.img'... OKAY [ 0.128s]
booting... OKAY [ 0.000s]
finished. total time: 0.128s
And when I tried to run oem format, it stuck.
Code:
C:\kfu\tools>fastboot -i 0x1949 oem format
...
I have no experience how long the re-partitioning takes, still wonder whether cancel this command or let it run T_T
would try the format command without -i 0x1949
the initialization is'nt needed with u-boot.bin ver.1.2 and the command is'nt designed to work with initialization
I tried to run command but failed. <waiting device>
you have allready the hot booted fff loaded ?
give -i 0x18d1 a try at the format command
bradys had a simmilar problem:
http://forum.xda-developers.com/showthread.php?t=1369405&page=10
follow the next 2 sites ...
hope this helps
you have allready the hot booted fff loaded ?
Click to expand...
Click to collapse
I guess not because fastboot -i 0x1949 boot bootloader u-boot.bin did not work and fastboot -i 0x1949 boot u-boot.bin either because after that command finishs, the fastboot oem format return <waiting device>, it means that fff 1.2 is not loaded successfully.
give -i 0x18d1 a try at the format command
Click to expand...
Click to collapse
tried but <waiting device>
bradys had a simmilar problem:
http://forum.xda-developers.com/show...369405&page=10
follow the next 2 sites ...
hope this helps
Click to expand...
Click to collapse
Thank you for your prompt support.
Not really, the symtoms are similar but in his case, the partition table still able to read but mine couldn't be. And he also has chance to rebuild partition mannually but I do not; I cannot run parted /dev/block/mmcblk0, this command return nothing as i mentioned above. T_T
yeutinh said:
I guess not because fastboot -i 0x1949 boot bootloader u-boot.bin did not work and fastboot -i 0x1949 boot u-boot.bin either because after that command finishs, the fastboot oem format return <waiting device>, it means that fff 1.2 is not loaded successfully.
Click to expand...
Click to collapse
your right about that - have also read it in an other thread - loads but don't reload itself
are you able to issue mklabel, mkpart and the other commands like here:
http://forum.xda-developers.com/showpost.php?p=20880465&postcount=58
maybe give eldarerathis a pm - he's the guru on partitioning:
http://forum.xda-developers.com/member.php?u=2676559
are you able to issue mklabel, mkpart and the other commands like here:
http://forum.xda-developers.com/show...5&postcount=58
Click to expand...
Click to collapse
Tried but failed, command stuck
maybe give eldarerathis a pm - he's the guru on partitioning:
http://forum.xda-developers.com/member.php?u=2676559
Click to expand...
Click to collapse
Thanks for advice, already PM him.
Code:
cat /proc/partitions
major minor #blocks name
179 0 7553024 mmcblk0
All partitions gone T_T
Got your PM. I haven't seen anything quite like this before, so all I can really do is take something of an educated guess here. What it looks like may have happened is that the partition table got corrupted or erased, so parted can't read the partition list (again, just a bit of a guess).
Try doing this and post the output that you see:
Boot into recovery
Use adb shell to connect to your Fire
Run "fdisk -l /dev/block/mmcblk0" (that's a lowercase "L")
If (3) doesn't seem to work, try "fdisk /dev/block/mmcblk0". It should give you a little prompt kind of like parted does. Type "p" and hit enter at the fdisk prompt (then use "q" to quit).
If fdisk gives you something sane then your partition table is okay. If it blows up or throws back an error then it's toast, but you might be able to use fdisk to create a new (blank) partition table and then re-create the correct partition layout. Either way, it should get you some more information about what's actually going on with your disk.
Thank you for your support, I appreciate that
Code:
~ # fdisk -l /dev/block/mmcblk0
fdisk -l /dev/block/mmcblk0
fdisk: can't open '/dev/block/mmcblk0': I/O error
~ # fdisk /dev/block/mmcblk0
fdisk /dev/block/mmcblk0
fdisk: can't read from /dev/block/mmcblk0
it means the filesystem on eMMC was accidentally broken down, correct ? But I wonder what make FS down because I did not do anything that impact to partitions, I think
and when I run mount, the result is
mount
rootfs on / type rootfs (rw)
tmpfs on /dev type tmpfs (rw,relatime,mode=755)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
Click to expand...
Click to collapse
Already checked whether eMMC dead or alive http://forum.xda-developers.com/showpost.php?p=13895268&postcount=48
Code:
~ # cat /sys/devices/platform/mmci-omap-hs.1/mmc_host/mmc0/mmc0:0001/name
cat /sys/devices/platform/mmci-omap-hs.1/mmc_host/mmc0/mmc0:0001/name
M8G2FA
Returned name of eMMC
Code:
~ # cat /proc/kmsg | grep mmc0
cat /proc/kmsg | grep mmc0
<6>[ 2.438171] mmc0: new high speed DDR MMC card at address 0001
<6>[ 2.456115] mmcblk0: mmc0:0001 M8G2FA 7.20 GiB
it means that my chip still alive Need your help to clear the messed FS
The I/O error from fdisk is concerning, and kind of makes it sound like the hardware up and died somehow. I was thinking you might be able to use fdisk to create a blank MSDOS partition table, then use parted to switch it to a GPT one (the Fire uses GPT and fdisk doesn't support that), but if it can't even read the disk then that won't work. The fact that FFF's 'fastboot oem format' isn't working also kind of lends to the hardware possibility, but I don't know exactly how it performs the format (you could try PM'ing pokey9000 and see if he'll explain it to you, maybe).
To be honest, I don't think I've seen a lot of recovery options for this sort of thing. The only stuff I can think of are all kind of Linux-geared, and Android is unfortunately lacking in some of the tools that it has available. For instance, one option on a Linux box would be to attempt to zero out the whole disk and then try to re-create everything, but I don't know how you'd handle things like the MBR on Android (or if you even need to). It still may be a possibility, but I have no idea if it would work and your data would all be lost. Worst case you'd end up with a permanently unbootable drive if the MBR/partition table are zeroed out and you can't re-create them, but I guess that's kind of what you have now, in't it?
I think you are right T_T. Will look for workaround solution if any and after that will return to Amazon T_T
You might as well try it.
dd if=/dev/zero of=/dev/block/mmcblk0
Immediately flash a complete system image after this (complete with everything from xloader to media).
If this command says can't open '/dev/block/mmcblk0': I/O error, the chip is probably toast. Unless it's some silly partition abstraction layer caused by twrp or something, in which case you can try to flash a cwm image via fastboot...
If even that fails, you can try to pin-mod that flash -- resetting it. But opening your kindle is probably the last thing you'd want to do if you have the chance to return it, heheh...
I tried dd command already, it returned I/O error also.
Will consider pin-mod method, but could you pls advise more details hehe. It's better than return it to Amazon
This afternoon I tried to play with KF again. I put it to recovery and
Code:
~ # echo /dev/block/mmcblk0 > /sys/dev/devices/platform/usb_mass_storage/lun0/file
echo /dev/block/mmcblk0 > /sys/dev/devices/platform/usb_mass_storage/lun0/fi
le
And come back to Windows to check whether OS can detect the usb_mass_storage of KF.
And when I open HP USB Format Tool, it can detect the usb_mass_storage of KF as Amazon Kindle Fire 0001 (7376MB). I tried to format it but the error return that write protected device. Anyone can explain me what is the problem of my eMMC ?
And when using with GParted
Device information : Amazon Kindle
Size: 7.2 GiB
Path: /dev/sdb
Partition Table: msdos
Head 255
Sectors/track 63
Cylinders 940
Total sector 15106048
Sector size 512
Click to expand...
Click to collapse
what about mk2fs command via adb shell?
my mke2fs /dev/block/mmcblk0p11 brings to mk2fs: short write - what it could be?
Did you fix it yet? If fix, please intro for me. I have problem the same.
a similar problem, someone has already solved it?
My Nexus 7 wifi tablet was working flawlessly for a few months since buying.
It was rooted, unlocked with stock android 4.2.1 and Team Win Recovery 2.3.2.1
Yesterday morning after charging all the night I saw that it was completely turned off. It didn't bother me, because it happened a couple of times before.
But this time, after I'd switched it on it hung on google color logo.
I waited half an hour but to no avail.
So at first I booted to recovery and wiped cache and the like. But the problem remained. Factory reset didn't help either.
So as a last resort I formated everything (including system).
Then I saw surprisingly in fastboot mode that lock state is: LOCKED.
I've tried to unlock it but it ended with an error:
C:\Users\Warp\AppData\Local\Android\android-sdk\platform-tools>fastboot oem unlock
...
(bootloader) erasing userdata...
(bootloader) erasing userdata done
(bootloader) erasing cache...
FAILED (remote: (Unknown error code))
finished. total time: 7.241s
After I'd pressed "yes" to the question "unlock bootloader" on tablet it was displaying text "Neither USP nor CAC patition found" in a loop.
Because there is still TWR installed and I can't wipe it out i think I've lost the guarantee.
I can see my device in fastboot mode:
C:\Users\Warp\AppData\Local\Android\android-sdk\platform-tools>fastboot getvar all
(bootloader) version-bootloader: 4.13
(bootloader) version-baseband: N/A
(bootloader) version-hardware: ER3
(bootloader) version-cdma: N/A
(bootloader) variant: grouper
(bootloader) serialno: XXXXXXXXXXXXXXXXXXXXXX
(bootloader) product: grouper
(bootloader) secure: yes
(bootloader) unlocked: no
(bootloader) uart-on: no
(bootloader) partition-size:bootloader: 0x0000000000600000
(bootloader) partition-type:bootloader: emmc
(bootloader) partition-size:recovery: 0x0000000000c00000
(bootloader) partition-type:recovery: emmc
(bootloader) partition-size:boot: 0x0000000000800000
(bootloader) partition-type:boot: emmc
(bootloader) partition-size:system: 0x0000000028a00000
(bootloader) partition-type:system: ext4
(bootloader) partition-size:cache: 0x000000001bb00000
(bootloader) partition-type:cache: ext4
(bootloader) partition-size:userdata: 0x0000000364700000
(bootloader) partition-type:userdata: ext4
all:
finished. total time: 0.193s
Is there anything left I can try?
AW: No way to unlock device. Is it bricked?
Have you tried reflashing stock rom? Maybe this rewrites recovery, too
Sent from my SK17i running Android 4.1.2
mihahn said:
Have you tried reflashing stock rom? Maybe this rewrites recovery, too
Click to expand...
Click to collapse
Yes, but it can't be done because the device is locked.
Before you do anything drastic, realize that you still have (in TWRP) a privileged execution environment (a root shell).
That means at a minimum you have a root-privileged shell available and some tools for fooling with partitions known to the TWRP kernel.
By drastic, I mean specifically: don't overflash the recovery partition at the command line from the root shell using /sbin/flash_image. Keep "root" until you are sure that nothing else can be done.
Back in a couple minutes - booting my N7 into TWRP right now to have a look at some things.
[ Edit ] From your post I see you have fastboot drivers set up - can you connect to TWRP via ADB?
Thank you for your reply.
Yes, I can see my device using: adb devices
adb shell also works.
[Edit] One more odd thing, when TWRP starts it asks me to enter my password. I think it's related to data encrypted partition but I've never done it for sure.
Well, I have a couple of hypotheses.
I guess I should ask one more question - is it correct that in TWRP you see none of your backups in /sdcard (TWRP mounts /sdcard on when it starts up) ?
If you have anything left on the SD card you want saved, get it backed up to your PC with "adb pull" before proceeding any further. (All suggestions below assume you have nothing left to save anywhere in /data.)
Also, I note that my N7 discharges slowly when plugged into my computer but sitting at the TWRP screen - so get your nexus fully charged before going any further.
The fact that you can boot TWRP means that the bootloader can find your recovery image, so at a minimum that means the bootloader can still understand some of the partitioning information it has available.
It is possible that the initial problem you had was something as simple as a corruption of a ext4 file system involving /cache, /system, or /data - as they need to be mounted after the early boot (ramdisk) initialization has more or less finished up. If they can not be mounted, the late boot processes never occur. Looking at your subsequent problems with unlocking the bootloader indicate a problem with the /cache partition - maybe?
[ The re-locking of the bootloader is odd, though. It suggests something got erased or mangled in a partition of the flash RAM that normally does not get mounted or touched by any of the usual kernel boots (whether we are talking about a recovery boot or any other android kernel boot). That means something other than /system, /cache, or /data - probably misc1, misc2, mfg, or possibly somewhere else (like slack space at the ends of either the boot or recovery partitions, or even in hard-coded location. ]
What happens if you try to rebuild the ext4 filesystems on /cache, /system, and /data?
[ note the partitions below are for the grouper N7 device; do a "adb shell cat /etc/fstab" to see if there are differences if you are on tilapia (3G version of the Nexus 7) ]
C:\foo> adb shell
# umount /data
# umount /cache
# umount /sdcard
# /sbin/mke2fs -t ext4 -m 0 /dev/block/mmcblk0p4
# /sbin/mke2fs -t ext4 -m 0 /dev/block/mmcblk0p3
# /sbin/mke2fs -t ext4 -m 0 /dev/block/mmcblk0p9
Does this succeed or fail? If it fails, what about first trying
# /sbin/erase_image /dev/block/mmcblk0p??? ( substitute correct # for ???)
prior to the mke2fs operation?
If you can get them to succeed, you might try restoring a backup (adb push to your "SD card"), and then doing a restore from TWRP and see if you can get it to boot.
You may also want to get your misc1 and misc2 partitions backed up - they contain the partitioning information (and usually the android "boot communication block), and they are generally identical (down to the last byte):
C:\foo> adb shell
# mount /sdcard (if this fails then you can't do this obviously)
# dd if=/dev/block/mmcblk0p5 of=/sdcard/part5.img bs=4096
# dd if=/dev/block/mmcblk0p8 of=/sdcard/part8.img bs=4096
# exit
C:\foo> adb pull /sdcard/part5.img
C:\foo> adb pull /sdcard/part8.img
If one of misc1 or misc2 got corrupted - and that is what is confusing the bootloader - it should be possible to flash the bad one with the good spare - but let's leave that alone until we see if /cache, /data, and /system can be re-initialized.
I'll come back to this thread in 8 hours or so - time for bed for me.
bftb0 said:
Well, I have a couple of hypotheses.
is it correct that in TWRP you see none of your backups in /sdcard (TWRP mounts /sdcard on when it starts up) ?
Click to expand...
Click to collapse
Yes it mounts it and it is empty (besides TWRP directory). I don't have backup either but it is no problem for me. I just want to start with stock Android 4.2.1 or if it's not possible - wipe out TWRP and send nexus for repairing.
bftb0 said:
What happens if you try to rebuild the ext4 filesystems on /cache, /system, and /data?
Does this succeed or fail?
Click to expand...
Click to collapse
Everything went smoothly, no errors here.
bftb0 said:
If you can get them to succeed, you might try restoring a backup (adb push to your "SD card"), and then doing a restore from TWRP and see if you can get it to boot.
Click to expand...
Click to collapse
I was trying to install a few roms this way, but the flashing never ends. On nexus I can see all the time: Flashing file 1 of 1 /sdcard/aokp_grouper_jb-mr1_build-1.zip
As I saw in recovery.log the problem is at the moment when filesystem is created:
C:\Users\Warp\AppData\Local\Android\android-sdk\platform-tools>adb shell cat /tmp/recovery.log
[cut]
I:Set page: 'main2'
I:Set page: 'install'
I:Set page: 'flash_confirm'
I:Set page: 'flash_zip'
I:Set page: 'flash_zip'
Installing '/sdcard/aokp_grouper_jb-mr1_build-1.zip'...
Checking for MD5 file...
Skipping MD5 check: no MD5 file found.
Creating filesystem with parameters:
Size: 681574400
Block size: 4096
Blocks per group: 32768
Inodes per group: 6944
Inode size: 256
Journal blocks: 2600
Label:
Blocks: 166400
Block groups: 6
Reserved block group size: 47
Created filesystem with 11/41664 inodes and 5415/166400 blocks
and it stops here.
bftb0 said:
You may also want to get your misc1 and misc2 partitions backed up - they contain the partitioning information (and usually the android "boot communication block), and they are generally identical (down to the last byte):
Click to expand...
Click to collapse
Ok, done. I've checked they are identical.
bftb0 said:
I'll come back to this thread in 8 hours or so - time for bed for me.
Click to expand...
Click to collapse
Great I'm waiting impatiently.
Regards
warpek said:
...I don't have backup either...
Click to expand...
Click to collapse
Arrgh - you never made any backups?. I was hoping you had a TWRP backup - they are just tar files, so you can manually untar them into mounted partitions at the command line... and that way see if any errors occur on an individual partition you are working with. But I'll come back to this in a little bit.
warpek said:
Everything went smoothly, no errors here.
Click to expand...
Click to collapse
OK, got it.
warpek said:
As I saw in recovery.log the problem is at the moment when filesystem is created:
[cut]
Creating filesystem with parameters:
Size: 681574400
...
Created filesystem with 11/41664 inodes and 5415/166400 blocks
and it stops here.
Click to expand...
Click to collapse
Well, 650 MB (=681574400 bytes) is the /system partition, and the "Created filesystem" message probably indicates success with a mke2fs operation. But mke2fs does not wipe all the blocks, so it is still possible that the *restore to /system* operation is hanging on a media failure.
warpek said:
Ok, done. I've checked they are identical.
Click to expand...
Click to collapse
Just out of curiosity, do you get a md5sum of 3039dc3a07a56d0392d48787e4a202a1 for your part5.img and part8.img files? In principle, yours should not be identical to mine - especially if there is something unusual in the BCB (Boot Control Block), but there is a chance they are the same as these partitions seem to contain multiple backups of partitioning information. (My N7 appears to have been made in December)
OK, lets try something innocuous - raw read tests on all of your partitions. Let's see if you have a bunch of bad pages in one partition.
With TWRP running
C:\foo> adb shell
# dd of=/dev/null bs=4096 if=/dev/block/mmcblk0boot0
# dd of=/dev/null bs=4096 if=/dev/block/mmcblk0boot1
# dd of=/dev/null bs=4096 if=/dev/block/mmcblk0p1
# dd of=/dev/null bs=4096 if=/dev/block/mmcblk0p2
# dd of=/dev/null bs=4096 if=/dev/block/mmcblk0p3
# dd of=/dev/null bs=4096 if=/dev/block/mmcblk0p4
# dd of=/dev/null bs=4096 if=/dev/block/mmcblk0p5
# dd of=/dev/null bs=4096 if=/dev/block/mmcblk0p6
# dd of=/dev/null bs=4096 if=/dev/block/mmcblk0p7
# dd of=/dev/null bs=4096 if=/dev/block/mmcblk0p8
These should all go through pretty quickly - I omitted the /data partition (p9) because it is huge. The next largest (system/p3) should take about 20 seconds for a successful raw read. If you get a read failure, repeat the command on the offending partition with the "conv=noerror" option, as in
dd of=/dev/null bs=4096 conv=noerror if=/dev/block/mmcblk0p8
Basically I'm just looking for you to narrow down the search to a problem partition. The next step is to try to manually unpack files into /system, /cache, and /data to see if there is a flash media problem in one of those partitions. Unfortunately, this is where TWRP backup files would have been useful: ROM files are not useful for this, and the google factory images e.g. nakasi-jop40d-factory-6ac58a1a.tgz contain image files which are not archives - they are "sparse ext4 images".
Even though you observed no failures with the mke2fs operations, you might want to also try to repeat that process (only for p3, p4, and p9 !) , but this time using the partition erase command first.
# /sbin/erase_image /dev/block/mmcblk0pN
prior to the mke2fs operation.
OK, standing by.
bftb0 said:
Arrgh - you never made any backups?
Click to expand...
Click to collapse
I always do, but I though that because there are no important files for me on the nexus and everything else can be downloaded (system image, twrp) there is no need. Obviously I was mistaken.
bftb0 said:
Just out of curiosity, do you get a md5sum of 3039dc3a07a56d0392d48787e4a202a1 for your part5.img and part8.img files?
Click to expand...
Click to collapse
I used md5sum to co compare those files, here is mine:
part5.img 59071590099d21dd439896592338bf95
part8.img 59071590099d21dd439896592338bf95
bftb0 said:
OK, lets try something innocuous - raw read tests on all of your partitions. Let's see if you have a bunch of bad pages in one partition.
Click to expand...
Click to collapse
Everything looks ok here. No errors and no long time reads.
bftb0 said:
Basically I'm just looking for you to narrow down the search to a problem partition. The next step is to try to manually unpack files into /system, /cache, and /data to see if there is a flash media problem in one of those partitions. Unfortunately, this is where TWRP backup files would have been useful:
Click to expand...
Click to collapse
Is there anything I can I do then?
bftb0 said:
Even though you observed no failures with the mke2fs operations, you might want to also try to repeat that process (only for p3, p4, and p9 !) , but this time using the partition erase command first.
# /sbin/erase_image /dev/block/mmcblk0pN
prior to the mke2fs operation.
Click to expand...
Click to collapse
Ok, done, still no errors.
I've also tried writing test using dd if=/dev/zero of=/dev/block/partition bs=4096 (for partition p3 and p4) and again without any errors.
warpek said:
I used md5sum to co compare those files, here is mine:
part5.img 59071590099d21dd439896592338bf95
part8.img 59071590099d21dd439896592338bf95
Click to expand...
Click to collapse
Hmmmm. I did a little more looking at my own misc partition images, and they each contain 64 repeated (and identical!) blocks of information that are 1280 bytes long - a group of 8 (at minor offsets of 0x4000, 0x5000, 0x6000, 0x7000, 0xc000, 0xd000, 0xe000, 0xf000) that repeat 8 times every 64kB (major offset of 0x10000). If you want to attach one of your misc partition images, I can have a look at it for comparison (it is small - 512 kB, and should not contain any private data). Wait, I just realized: I have a 32GB WiFi N7 - is yours a 16GB?
warpek said:
Is there anything I can I do then?
Click to expand...
Click to collapse
I could shove a (near stock) boot.img and system.img backup from TWRP someplace, but the system image is huge. I don't have a convenient place to drop it - got any suggestions? In principle - barring any other errors - that should boot correctly so long as the ext4 filesystems on /data and /cache are intact and operating correctly.
warpek said:
I've also tried writing test using dd if=/dev/zero of=/dev/block/partition bs=4096 (for partition p3 and p4) and again without any errors.
Click to expand...
Click to collapse
Barring a tar or other archive file which we could unpack directly into (mounted) /system, that was going to be my next suggestion. Rats.
Maybe it is time to try the read/write tests with the /data partition?
Actually, before you do that, what were the dump lengths you got for each of your partitions? Here are mine (using bs=4096):
Code:
/dev/block/mmcblk0boot0 512 ( 2097152 bytes - 2.0MB)
/dev/block/mmcblk0boot1 512 ( 2097152 bytes - 2.0MB)
/dev/block/mmcblk0p1 3072 ( 12582912 bytes - 12.0MB) recovery
/dev/block/mmcblk0p2 2048 ( 8388608 bytes - 8.0MB) boot
/dev/block/mmcblk0p3 166400 (681574400 bytes - 650.0MB) system
/dev/block/mmcblk0p4 113408 (464519168 bytes - 443.0MB) cache
/dev/block/mmcblk0p5 128 ( 524288 bytes - 512kB) misc1?
/dev/block/mmcblk0p6 2560 ( 10485760 bytes - 10.0MB) -WTF?- "staging?"
/dev/block/mmcblk0p7 1280 ( 5242880 bytes - 5.0MB) mfg
/dev/block/mmcblk0p8 128 ( 524288 bytes - 512kB) misc2?
/dev/block/mmcblk0p9 ?? ( ?? bytes - ??MB) data
Note I didn't do my /data partition - I have a 32GB N7, so I suppose that means that /data is 30+ GB in size. Lazy and didn't want to wait.
---------- Post added at 01:40 PM ---------- Previous post was at 12:55 PM ----------
FYI,
shoving some TWRP backup images (system, boot) to my dropbox right now. Lightly-rooted stock. (Added su and SuperSu in /system, and altered default.prop in the boot image so that the secure flag is disabled and the adb daemon starts up straight away). Other than those changes, 100% stock, including kernel.
I'll send a PM when I figure out how Dropbox works.
bftb0 said:
Wait, I just realized: I have a 32GB WiFi N7 - is yours a 16GB?
Click to expand...
Click to collapse
Yes, I've got 16GB version.
bftb0 said:
I could shove a (near stock) boot.img and system.img backup from TWRP someplace, but the system image is huge. I don't have a convenient place to drop it - got any suggestions?
Click to expand...
Click to collapse
I can create ftp account on and send you login data in a private message. Will it be convenient for you?
bftb0 said:
Maybe it is time to try the read/write tests with the /data partition?
Click to expand...
Click to collapse
Yea, but ... now something really strange happened.
All partitions have disappeared. _I'm sure_ that I didn't zeroed the whole mmcblk0 device. Just the partition I mentioned before.
Code:
ls /dev/block
loop0 loop2 loop4 loop6 mmcblk0 mmcblk0bo
loop1 loop3 loop5 loop7 mmcblk0boot0 platform
fdisk -l /dev/block/mmcblk0
Disk /dev/block/mmcblk0: 15.7 GB, 15762194432 bytes
4 heads, 16 sectors/track, 481024 cylinders
Units = cylinders of 64 * 512 = 32768 bytes
Disk /dev/block/mmcblk0 doesn't contain a valid partition table
TWRP still starts but it takes more time.
bftb0 said:
Actually, before you do that, what were the dump lengths you got for each of your partitions? Here are mine (using bs=4096):
Click to expand...
Click to collapse
I don't have partition table now so I it is useless. But for the future use, can you tell me please how I can see this kind of dump?
Edit: I'd be grateful if anyone having Nexus 7 16GB paste output of command:
Code:
adb shell /sbin/fdisk -l /dev/block/mmcblk0
I hope I will be able to create proper partitions on my device then.
But I'm afraid of using fdisk to create partitions because this can lead to destroy current recovery which still starts.
warpek said:
Yes, I've got 16GB version.
I can create ftp account on and send you login data in a private message. Will it be convenient for you?
Click to expand...
Click to collapse
or you could just attach it - should be less than the XDA attachment size limit, and as I mentioned there is no private info in there.
Looking at my own dumped images, it looks like this same partitioning information appears in mmcblk0boot0 190 times (!!), and in mmcblk0boot1 256 times (!!). I need to extract them all and compare checksums to see if they are identical.
warpek said:
Yea, but ... now something really strange happened.
All partitions have disappeared. _I'm sure_ that I didn't zeroed the whole mmcblk0 device. Just the partition I mentioned before.
Code:
ls /dev/block
loop0 loop2 loop4 loop6 mmcblk0 mmcblk0bo
loop1 loop3 loop5 loop7 mmcblk0boot0 platform
fdisk -l /dev/block/mmcblk0
Disk /dev/block/mmcblk0: 15.7 GB, 15762194432 bytes
4 heads, 16 sectors/track, 481024 cylinders
Units = cylinders of 64 * 512 = 32768 bytes
Disk /dev/block/mmcblk0 doesn't contain a valid partition table
TWRP still starts but it takes more time.
I don't have partition table now so I it is useless. But for the future use, can you tell me please how I can see this kind of dump?
Click to expand...
Click to collapse
Holy ****.
(My info was just from collected from looking at the output of individual dd read commands on each partition)
Again, holy **** - that's a world of hurt. I suppose recovery might still be possible, but perhaps only with some exhaustive code review of how the mmc driver determines the partitioning. and possibly some very dangerous patching of areas in mmcblk0boot{0,1}. It does appear that partitioning information is stored redundantly in multiple places on the tablet.
I am wondering - if the partitioning information that the TWRP boot was somehow partially corrupted - then running "dd if=/dev/zero" to write without a "count=" size constraint might have caused an over-run past where the actual partition was supposed to live.
At this point, I wouldn't attempt any more writing operations - especially since TWRP doesn't know where anything lives any longer.
---------- Post added at 02:23 PM ---------- Previous post was at 02:16 PM ----------
For the purposes of rescue you might want to capture some dumps of mmcblk0boot0 and mmcblk0boot1
Since you can not mount the /sdcard to store the dumps temporarily, you should be able to stuff them into ramdisk temporarily and then pull them to your PC via adb in the same TWRP session:
C:\foo> adb shell
# mkdir /tmp/dumps
# dd if=/dev/block/mmcblk0boot0 bs=4096 of=/tmp/dumps/mmcblk0boot0.img
# dd if=/dev/block/mmcblk0boot1 bs=4096 of=/tmp/dumps/mmcblk0boot1.img
# exit
C:\foo> adb pull /tmp/dumps/
The worst that can happen here (if the partitioning for mmcblk0boot{0,1} is wrong - and huge - you'll wedge the TWRP session by filling memory.
Without committing to a lot of effort it looks like you are looking at RMA time.
bftb0 said:
I am wondering - if the partitioning information that the TWRP boot was somehow partially corrupted - then running "dd if=/dev/zero" to write without a "count=" size constraint might have caused an over-run past where the actual partition was supposed to live.
Click to expand...
Click to collapse
Yes, I suppose it could be the case.
bftb0 said:
For the purposes of rescue you might want to capture some dumps of mmcblk0boot0 and mmcblk0boot1
Click to expand...
Click to collapse
Done without problems.
bftb0 said:
Without committing to a lot of effort it looks like you are looking at RMA time.
Click to expand...
Click to collapse
[/QUOTE]
I don't want to bother you with too much digging, so maybe it's time to send my device back do the seller.
But before that ... I think I should wipe out TWRP.
Should I use dd on the whole mmcblk0 device to do that?
Nevertheless I'm really greateful for your time and efforts. Thank you very much.
warpek said:
Should I use dd on the whole mmcblk0 device to do that?
Click to expand...
Click to collapse
Hmmm. Dunno. At this point you might end up borking the bootloader trying something like that.
There have been other threads where folks reported returning devices without bothering to do any clean up - and without repercussions.
Seems believable; the folks that are tasked with repairing units under RMA are not approaching each one as if it were a forensic evaluation. From a pure business standpoint that would be a huge waste of time and money. If they ever get rewarded for anything they do, it's probably a throughput metric (devices repaired or scrapped per work shift). Your unit will be one of many.
Your thanks are welcome, but I have an interest in this anyway. I noticed in digging around that (rather bizarrely) there is a partition that TWRP identifies as "staging" (/dev/block/mmcblk0p6). The bizarre part of this is that a hexdump revealed a few strings that were unicode URLs for XDA's ad networks. !! ?? !!
That rather freaks me out - what the frick is user data (I suppose from web browsing?) doing in a partition that never gets mounted and is (apparently) not in any identify-able file system format?
Back when Amon_RA was packaging his recovery for various devices, he would use a STOCK KERNEL in the boot image for his recovery boot. That pretty much is a guarantee that the kernel drivers (e.g. for MTD/MMC) would behave no differently from the way the device manufacturer does things - including for important things like interpreting partition tables.
With TWRP and CWM we currently have no such assurances that subtle bugs have not crept in to important places unless we repackage their boot images to use stock kernels.
Anyway, I am trying to review what I *think* is partitioning information to see what I can figure out - but you probably shouldn't wait for me.
Good luck with your return.
I don't want to bother you with too much digging, so maybe it's time to send my device back do the seller.
But before that ... I think I should wipe out TWRP.
Should I use dd on the whole mmcblk0 device to do that?
Click to expand...
Click to collapse
Hi warpek, I don't mean to butt in to this thread but I encountered a similar issue to yours this past weekend that's gotten to the point where I can no longer turn on nor get into the bootloader anymore. My question is since our devices have been modified, do you know if there is there any chance that Asus could deny and void the warranty upon finding that out?
There have been other threads where folks reported returning devices without bothering to do any clean up - and without repercussions.
Click to expand...
Click to collapse
Alright guess I'll go give it a shot.
Hi fungosaurus,
For the benefit of the rest of the N7 community - could you say a few words about what ROM/kernel was on your tablet, and (if you know) about what the charge state of the battery was like when the first hint of problem occurred?
A few reports don't mean anything conclusive, but it sure is starting to look like something is going on with "low battery" / "can't turn on" syndromes ... which then unfold into full-blown disasters.
bftb0 said:
Hi fungosaurus,
For the benefit of the rest of the N7 community - could you say a few words about what ROM/kernel was on your tablet, and (if you know) about what the charge state of the battery was like when the first hint of problem occurred?
A few reports don't mean anything conclusive, but it sure is starting to look like something is going on with "low battery" / "can't turn on" syndromes ... which then unfold into full-blown disasters.
Click to expand...
Click to collapse
Oh yes of course. CM10.1 Jan 10 nightly with whichever kernel it came with. As far as I could tell the battery was fully charged when I could no longer power it back on or access the bootloader.
My issue was actually a bit complicated and I might've actually been the one to worsen it through my ignorance. I made a post on Reddit that describes in detail what happened. Does this help?
fungosaurus said:
Does this help?
Click to expand...
Click to collapse
Only time will tell - for instance if lots of folks start reporting troubles with the same kernel.
Sounds more like a hardware problem though. Thanks for the info.
I think I saw a recent news article stating that Asus is shipping about 1 million N7's per month now. If they have shipped 5 million cumulatively, and they have a defect rate of only 0.1% in the first year of service, that would be 5000 owners who might end up on message boards looking for help. Although - since rooters are presumably a small fraction of owners - I guess we should see a much smaller number of folks who are rooted AND experience hardware troubles.
@warpek - the data stored in the misc1/misc2 partitions does in fact appear to be partitioning data. But I don't think you can use "fdisk" for the mmcblk0 device in any event.
bftb0 said:
Hmmm. Dunno. At this point you might end up borking the bootloader trying something like that.
There have been other threads where folks reported returning devices without bothering to do any clean up - and without repercussions.
Click to expand...
Click to collapse
Yes, but to be sure that I won't have any problems while returning my device I zeroed the whole block device.
bftb0 said:
Your thanks are welcome, but I have an interest in this anyway. I noticed in digging around that (rather bizarrely) there is a partition that TWRP identifies as "staging" (/dev/block/mmcblk0p6). The bizarre part of this is that a hexdump revealed a few strings that were unicode URLs for XDA's ad networks. !! ?? !!
Click to expand...
Click to collapse
That is really astounding. Please let us now if you have any conclusions.
Meanwhile I'm sending my nexus to Asus.
Thanks again.
fungosaurus said:
My question is since our devices have been modified, do you know if there is there any chance that Asus could deny and void the warranty upon finding that out?
Click to expand...
Click to collapse
As bftb0 said it shouldn't be any problems but to be sure I zeroed the whole block device area before returning it back.