I did some research and am close to how the singleimage.bin is created. From what I am seeing it is a combination of 4 files with some gpt info at top and bottom. I have bricked my device and am looking for the right singleimage to restore it to. below is the list of file and there order and decimal for where they are in the file.
(taken from 5.0.1 gpe ota)
|_____________________________________________|
| File name | HEX | DECIMAL |
|_____________________|___________|____________|
1) sbl1_8226.mbn | 4400 | 17408 |
2) emmc_appsboot.mbn | 8C400 | 574464 |
3) rpm.bin | 203400 | 2110464 |
4) tz.bin | 280400 | 2622464 |
|_____________________________________________|
The space inbetween the files is filed with 0's. It is exactly what the name says: a singleimage. It is the memory layout of the phone. Since we are restoring it completey blank (hence blank-flash) we only flash the needed files.
So seeing this I am hoping someone with the 8226 chip (xt1032 has it dont know about others) would be willing to dd ther mmcblk0 partition (the whole phone) which is runnng 5.0.1 and this will allow us to unbrick our phone.
Information came from http://www.droidrzr.com/index.php/topic/50897-bricked-blank-screen-no-boot-options-just-black-screen-no-text-or-graphics/
finding out the partition layout I did myself using a binary viewer and comparng files.
I tried flashing the singleimage but was greeted with "invalid HDLC frame". so it is not quite fixed yet. Can anyone explain to me what this HDLC frame is?
bludotos said:
I did some research and am close to how the singleimage.bin is created. From what I am seeing it is a combination of 4 files with some gpt info at top and bottom. I have bricked my device and am looking for the right singleimage to restore it to. below is the list of file and there order and decimal for where they are in the file.
(taken from 5.0.1 gpe ota)
|_____________________________________________|
| File name | HEX | DECIMAL |
|_____________________|___________|____________|
1) sbl1_8226.mbn | 4400 | 17408 |
2) emmc_appsboot.mbn | 8C400 | 574464 |
3) rpm.bin | 203400 | 2110464 |
4) tz.bin | 280400 | 2622464 |
|_____________________________________________|
The space inbetween the files is filed with 0's. It is exactly what the name says: a singleimage. It is the memory layout of the phone. Since we are restoring it completey blank (hence blank-flash) we only flash the needed files.
So seeing this I am hoping someone with the 8226 chip (xt1032 has it dont know about others) would be willing to dd ther mmcblk0 partition (the whole phone) which is runnng 5.0.1 and this will allow us to unbrick our phone.
Information came from http://www.droidrzr.com/index.php/topic/50897-bricked-blank-screen-no-boot-options-just-black-screen-no-text-or-graphics/
finding out the partition layout I did myself using a binary viewer and comparng files.
I tried flashing the singleimage but was greeted with "invalid HDLC frame". so it is not quite fixed yet. Can anyone explain to me what this HDLC frame is?
Click to expand...
Click to collapse
I found this. Scroll to the second post
http://forum.xda-developers.com/showthread.php?t=2086142
It is there all explained . I hope you can find something usefull in it
bludotos said:
So seeing this I am hoping someone with the 8226 chip (xt1032 has it dont know about others) would be willing to dd ther mmcblk0 partition (the whole phone) which is runnng 5.0.1 and this will allow us to unbrick our phone.
Click to expand...
Click to collapse
I'm running 5.0.1 gpe on my 1032. I'll help you with it if you give proper instructions about what exactly commands I should do. should I do it in adb shell and so on and so forth.
S0bes said:
I'm running 5.0.1 gpe on my 1032. I'll help you with it if you give proper instructions about what exactly commands I should do. should I do it in adb shell and so on and so forth.
Click to expand...
Click to collapse
Thank you for offering this!
I will at least need these partitions:
sdl1: mmcblk0p2
DDR: mmcblk0p3
aboot: mmcblk0p4
rpm: mmcblk0p5
tz: mmcblk0p6
sdi: mmcblk0p7
to extract them, do:
>su
>dd if=/dev/block/mmcblk0p? of=/sdcard/images/???.img
replace "?" with the correct name. ex: dd if=/dev/block/mmcblk0p3 of=/sdcard/images/DDR.img
once done, zip them up and upload.
or you can also do a full back up: (will provide more information to me)
>su
>dd if=/dev/block/mmcblk0 of=/sdcard/full_image.img
I would really appreciate this.
Thank you again.
bludotos said:
Thank you for offering this!
I will at least need these partitions:
sdl1: mmcblk0p2
DDR: mmcblk0p3
aboot: mmcblk0p4
rpm: mmcblk0p5
tz: mmcblk0p6
sdi: mmcblk0p7
to extract them, do:
>su
>dd if=/dev/block/mmcblk0p? of=/sdcard/images/???.img
replace "?" with the correct name. ex: dd if=/dev/block/mmcblk0p3 of=/sdcard/images/DDR.img
once done, zip them up and upload.
or you can also do a full back up: (will provide more information to me)
>su
>dd if=/dev/block/mmcblk0 of=/sdcard/full_image.img
I would really appreciate this.
Thank you again.
Click to expand...
Click to collapse
I don't want to curb your enthusiasm, but generating a new singleimage.bin has already been done and tried and it does not work. Singleimage.bin contains 5 partitions: sbl, ddr, aboot, rpm and TZ. We already have a dump of those partitions taken from a Lollipop upgraded Moto G, and I already tried using those partitions to recreate singleimage.bin. It still fails. My guess is the flashing procedure fails even BEFORE trying to flash singleimage.bin, very likely due to incompatible programmer/qboot version.
Camazza said:
I don't want to curb your enthusiasm, but generating a new singleimage.bin has already been done and tried and it does not work. Singleimage.bin contains 5 partitions: sbl, ddr, aboot, rpm and TZ. We already have a dump of those partitions taken from a Lollipop upgraded Moto G, and I already tried using those partitions to recreate singleimage.bin. It still fails. My guess is the flashing procedure fails even BEFORE trying to flash singleimage.bin, very likely due to incompatible programmer/qboot version.
Click to expand...
Click to collapse
aww. been starting to thnk that. although, have you tried using another programmer file? I noticed that it starts to flash the singleimage and then stops due to a "error sending packet". So it passed the HDLC frame validation (maybe programmer_8626 doesnt check HDLC?)
I've been trying every possible combination of programmer/qboot possible with no results. We must wait for a newer qboot/programmer. I know this is sad news, but even I got tired of repetedly trying to do something impossible.
Our only hope, but a very remote one, is for someone much smarter than I am to start listening on the Qualcomm COM port and trying to interpret what's going on, especially what's failing and why. But I guess it's too hard of a job for something we *should* be able to fix in a couple weeks' time.
EDIT:
Here's what the debug of qboot reports
I - opening device: \\.\COM5
D - \\.\COM5 opened
I - OKAY [ 0.000s]
I - greeting device for command mode
D - Receiving HELLO packet
D - TARGET PROTOCOL INFO:
D - name: sahara
D - version: 2
D - compatible version: 1
D - maximum packet length: 1024
D - mode: Image transfer pending
D - Switching to "Command" mode
D - Sending HELLO_RESP packet
D - Receiving COMMAND_READY packet
I - OKAY [ 0.016s]
I - identifying device
D - Reading device serial number
D - Sending CMD_EXEC packet, cmd=1
D - Receiving CMD_EXEC_RESP packet
D - Reading device id
D - Sending CMD_EXEC packet, cmd=2
D - Receiving CMD_EXEC_RESP packet
D - Reading SBL SV
D - Sending CMD_EXEC packet, cmd=7
D - Receiving CMD_EXEC_RESP packet
I - ...serial = 0x2F4C742
I - ...chip-id = 0x800 (MSM8226)
I - ...chip-rev = 0x0
I - ...sv-sbl = 0x0
I - OKAY [ 0.016s]
I - finding files
I - ...programmer = programmer.mbn
I - ...singleimage = singleimage.bin
I - OKAY [ -0.000s]
I - validating files
I - OKAY [ -0.000s]
I - switching to download mode
D - Sending CMD_SWITCH_MODE packet
I - OKAY [ -0.000s]
I - greeting device for image downloading
D - Receiving HELLO packet
D - TARGET PROTOCOL INFO:
D - name: sahara
D - version: 2
D - compatible version: 1
D - maximum packet length: 1024
D - mode: Image transfer pending
D - Sending HELLO_RESP packet
I - OKAY [ 0.016s]
I - sending programmer
D - Loading file: programmer.mbn
D - Receiving READ_DATA packet
D - Sending 80 bytes
D - Receiving READ_DATA packet
D - Sending 4096 bytes
D - Receiving READ_DATA packet
D - Sending 4096 bytes
D - Receiving READ_DATA packet
D - Sending 4096 bytes
D - Receiving READ_DATA packet
D - Sending 4096 bytes
D - Receiving READ_DATA packet
D - Sending 4096 bytes
D - Receiving READ_DATA packet
D - Sending 4096 bytes
D - Receiving READ_DATA packet
D - Sending 4096 bytes
D - Receiving READ_DATA packet
D - Sending 4096 bytes
D - Receiving READ_DATA packet
D - Sending 4096 bytes
D - Receiving READ_DATA packet
D - Sending 4096 bytes
D - Receiving READ_DATA packet
D - Sending 4096 bytes
D - Receiving READ_DATA packet
D - Sending 4096 bytes
D - Receiving READ_DATA packet
D - Sending 516 bytes
D - Receiving END_IMAGE_TX packet
D - Sending DONE packet
D - Receiving DONE_RESP packet
I - OKAY [ 0.031s]
I - flashing singleimage
D - Loading file: singleimage.bin
D - Pinging RDL...
D - No data from serial, retrying...
D - No data from serial, retrying...
D - No data read from serial after 2 tries
D - No data from serial, retrying...
D - No data from serial, retrying...
D - No data read from serial after 2 tries
D - \\.\COM5 closed
FAILED (blank-flash:sdl-transfer-image:sdl-hello:invalid HDLC frame)
anyway here you go
tell me if you still need a full image
question then for those who really know how this works. Does programmer.mbn read the HDLC frames? If so this means that generating the singleimage is not so important as modifying the programmer.mbn to accept the singleimage. I read up more on HDLC frames and the issue seems to be that when escaping the 0x7e bits or other bits (the partitions "frame starter/ender") they are invalid. Since it ends so quickly it must be finding an end to a frame too quickly? In which case we really do need to wait for motorola to release androd 5.
bludotos said:
Thank you for offering this!
I will at least need these partitions:
sdl1: mmcblk0p2
DDR: mmcblk0p3
aboot: mmcblk0p4
rpm: mmcblk0p5
tz: mmcblk0p6
sdi: mmcblk0p7
Guys, Its not that I am new but I may not know much. I may be wrong, but I found something in /proc (file called partitions) that shows something about these partitions. I have root browser and was trying to find about these partitions. There are other files also which give some more info. Is it helpful. Please correct me if I am wrong. Thnks.
Click to expand...
Click to collapse
We have partition information. We need programmer.mbn which will write the single image to the phone
I have the same problem. But where can we get the programmer.mbn? Is it included in some OTA files of 5.0.2 or do we have to wait until motorolas secret files leak.
I don't know but maybe the programmer is part of the motoboot.img but I have no idea how to extract it.
Well, if somebody has already modified the singleimage, can you please upload it.
Thought I did. Will upload later today then. The programmer.mbn is a proprietary file and there for needs to be leaked. I checked the motoboot.img and it does not contain it. Upgrades don't process the same s restoring from hardbrick.
Shut up you lier
Don't be over smart. Who has generated singleimage.mbn for bootloader 41.19.
lol @Ahlad be cool , being a newbie in xda doesn't mean he isn't smart , he is trying to get solution for for the issue , try to help him or just skip the thread and move on @bludotos i hope you will find a solution soon , keep trying
There is no solution unless I could get the key to decrypt the (been a while since I had time to work on it) header for each partition. I won't be continuing to work on this due to lack of time. Finishing up my cs degree.
The problem is not generating 'singleimage.bin', it's simply a disk image that's easy enough to generate.
The problem is programmer.mbn which checks the BOOTLOADER version of the phone (before flashing single image), read here for more info.
The solution would be to either wait for an updated programmer.mbn or finding a way come up with a modified programmer.mbn that passes digital signature verification.
tal.aloni said:
The problem is not generating 'singleimage.bin', it's simply a disk image that's easy enough to generate.
The problem is programmer.mbn which checks the BOOTLOADER version of the phone (before flashing single image), read here for more info.
The solution would be to either wait for an updated programmer.mbn or finding a way come up with a modified programmer.mbn that passes digital signature verification.
Click to expand...
Click to collapse
Yeah, what he said. I'm not good with explaining stuff but, that's pretty much what I meant.
Ahlad said:
Don't be over smart. Who has generated singleimage.mbn for bootloader 41.19.
Click to expand...
Click to collapse
where it is? i mean where is the singleimage.mbn???
is there any way to extract these files from a working moto g, if yes please tell me how to do that
Related
Was on : LSv3.2 ROM / AK.355 AOSP kernal / All of a sudden phone rebooted and ended up in Bootloop
Phone Boots to Boot loader and Recovery just fine , TWRP showing 0MB as storage space. And getting following logs when I try to do MOUNT or FORMAT operation.
E: Cannot munt storage /Data/system etc
And same issue in fresh FAASHING, I get the following message
E: FAILED (remote: flash write failure)
Does this mean my Flash Memory is gone and need to change Motherboard fix issue ? Please let me understand the issue, Any help is deeply appreciated.
RA
Hey.. No relax.. Your software is messed up.. Do this--->>>
1. download the nexus factory image from Google developers
2. download wugfresh toolkit
3. Go to "flash stock+unroot" and tick device is softbricked
4. navigate to the factory image you have downloaded
5. let the toolkit finish,
PS:- DO NOT INTERRUPT THE FLASHING PROCESS
The device should boot up
Sent from my Nexus 4 using XDA Free mobile app
I tried it first; it didn't work (Nexus Root Toolkit by WugFresh) gave same message :crying:. I tried flashing standalone using fastboot commands that also gives same error. Copied the full log from NRT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
sending 'radio' (45537 KB)...
OKAY [ 1.453s]
writing 'radio'...
FAILED (remote: flash write failure)
finished. total time: 1.469s
rebooting into bootloader...
OKAY [ 0.016s]
finished. total time: 0.016s
archive does not contain 'boot.sig'
archive does not contain 'recovery.sig'
archive does not contain 'system.sig'
archive does not contain 'tos.img'
Creating filesystem with parameters:
Size: 14129561600
Block size: 4096
Blocks per group: 32768
Inodes per group: 8144
Inode size: 256
Journal blocks: 32768
Label:
Blocks: 3449600
Block groups: 106
Reserved block group size: 847
Created filesystem with 11/863264 inodes and 95427/3449600 blocks
Creating filesystem with parameters:
Size: 587202560
Block size: 4096
Blocks per group: 32768
Inodes per group: 7168
Inode size: 256
Journal blocks: 2240
Label:
Blocks: 143360
Block groups: 5
Reserved block group size: 39
Created filesystem with 11/35840 inodes and 4616/143360 blocks
--------------------------------------------
Bootloader Version...: MAKOZ30d
Baseband Version.....: M9615A-CEFWMAZM-2.0.1701.03
Serial Number........: 003a98544753509d
--------------------------------------------
checking product...
OKAY [ 0.016s]
checking version-bootloader...
OKAY [ 0.016s]
checking version-baseband...
OKAY [ 0.016s]
sending 'boot' (6366 KB)...
OKAY [ 0.219s]
writing 'boot'...
FAILED (remote: flash write failure)
finished. total time: 0.328s
Booting up your freshly flashed stock device...
------------------------------------------------------------------
Wait for your device to finish booting up...
- It may appear to be boot looping; just wait...
- It could take 5-10 minutes; please be patient...
When its finally booted back up, please remember
to re-enable USB debugging if you plan on using
the toolkit to perform other operations.
NOTE: If this process was too quick and your device
is still in bootloader mode, then flashing stock may
have failed or been incomplete. Simply check the
log above: if you notice it skipped steps because it
didn't meet certain requirements, like the bootloader
or baseband version, then consider enabling 'Force Flash'
mode in the toolkits options menu and trying the
'Flash Stock + Unroot' processs again. Cheers.
Press any key to exit...
Oh... yup... flash memory is bad
Sent from my Nexus 4 using XDA Free mobile app
Thanks @ arkangel72.
Any other opinion from anyone ? Please let me know
RA
I browsed the net.. You have to take your phone to LG.. You have a hardware failure
Sent from my Nexus 4 using XDA Free mobile app
Thanks Sir - I have replace the logic board and phone back to work. (Got a Phone whose screen was damaged and swapped the boards) I have followed YouTube video on Nexus 4 fixes to conduct the board replacement, Pretty easy and straight forward.
RA
I was updating my Mom's Nexus 4 to 4.4 (with the intention of bringing it to the current version to address various security issues -- like stagefright), but it appears to have "soft-bricked" as some people are calling it.
- locked bootloader
- not rooted.
- stock firmware
It goes into a "bootloop"? Where the Google logo displays forever (at least 30 minutes) w/o doing anything.
Normally I'd have spent more time doing this (e.g. backing it up, etc). But due to various personal mishaps in the past year, my tech environment is incomplete and a mess. I've never had problems w/ OTA updates so I foolishly went ahead w/o an adb backup -- which would have at least given me most files (even if I have to redo the entire setup). Also, due to poor timing, I was in a rush to get this done so she'd have a week or so before her trip to get used to the small changes (yes, she freaks out over small changes like the camera UI being different). So, whenever you're doing 2 things at once, you never pay attention to one thing fully. And this is also what happened to the OTA update -- so if there were ANY error messages or anything during the update, I did not notice. =(
Unfortunately I also don't have the device in front of me (things like work get in the way of personal masochism -- aka playing with tech).
Anyhow... I'm not exactly certain if it was going to 4.4. When I downloaded the OTA images for the Nexus 4 for 4.4 and tried to flash using the flash-all tool, it complained that the bootloader was not the right one. When I pulled down 4.3 and tried to flash, it did not complain about that bootloader version. So perhaps it didn't properly flash the bootloader? In any case, is there any chance of getting at the files now before a wipe?
What confuses me, is why I cannot flash w/ a STOCK image. Aren't they signed? Even with a locked bootloader, couldn't it in theory let the right images in?
Also, I'm normally in a windows environment, but due to my machines all being down, I'm on the work MacBook Pro instead. So unfortunately I can't try WugFresh's rootkit -- although I'm not sure it would help w/ a locked boot loader.
So... the questions are:
1) Is there a way to flash to a stock OTA image w/o losing data?
2) Or if that's not possible, is it possible to get the data from the phone?
3) Or I'm out of luck and I shouldn't waste any more time trying to recover what's lost?
(Btw, I didn't lose everything -- e.g. I have photos, sms and call logs backed up. WhatsApp used to be backed up, but it seems like both the 3rd party solution and WhatsApp themselves have stopped supporting some sort of offline backup. So mainly just concerned about files in Downloads or Documents or something -- everything else I've made sure was "on the cloud".)
First you might try going into Recovery (assuming you can) and wipe the cache partition, then reboot and see if that fixes it. I have had this glitch occur during an OTA update before (It might have been the 4.4 update actually), and wiping the cache and rebooting fixed it every time.
I am trying to understand what happened and what you did exactly. You have a locked bootloader, aren't rooted, and on stock. You are saying OTA and that you tried to flash via flash-all. Are you using the term OTA and referring to the image files in the tarball as the same thing? OTA is the zip file which only contains the files necessary to go from one version to the next higher version. The .tgz factory image file has all of the image files for a complete build. You would not have been able to flash them with a locked bootloader however. Is that what happened here? You tried to flash the img files on a locked bootloader?
Are you able to boot into Fastboot? (Power off your Nexus 4, and reboot it into fastboot mode by holding the volume down button and power.) If so, will your computer recognize your device? You should install Minimal ADB and Fastboot: http://lifehacker.com/the-easiest-way-to-install-androids-adb-and-fastboot-to-1586992378 on your Mac and see if it will recognize your device.
If you can get it recognized in Fastboot, you can then just use the fastboot oem unlock command in a terminal window. If you can get the bootloader unlocked, you can then flash the image files properly to recover the device. Here are some instructions: http://www.androidcentral.com/how-unlock-nexus-4-bootloader (***This will wipe your device and you will lose your data if you have to go this route***)
The first thing I did was to try wiping the cache after recovery mode, but that did not take it out of the boot loop. AFAIK, in 4.3 you can't wipe the dalvik cache from stock recovery. Something similar also happened to me on my Nexus 4 a while back and yes, wiping the cache then did the trick (also think it was 4.4). It fixed it then on my Nexus 4, but not on the current one.
The initial flash was applied OTA. (e.g. There's been an "upgrade" icon in the notifications bar for like over a year.) So you touch the notification, it tells you to reboot and install and I let it w/o paying much attention to it afterwards until I noticed that it only displayed a Google logo afterwards (for over 30 minutes). If that flash takes longer than that, I could have screwed up and interrupted it. :crying: I can't recall how long the 4.4 takes to flash.
Since it was in a boot loop, I thought I could reflash from the tgz images from here: https://developers.google.com/android/nexus/images?hl=en, but of course w/ a locked boot loader, nothing will flash.
Looking at this thread, there seems to be a "manual" way to unlock the boot loader w/o wiping the device IF the Nexus 4 was on a version younger than 4.3.
http://forum.xda-developers.com/nex...ot-unlock-bootloader-wipe-data-t2300480/page4 - comment 35 for "steps", somewhere else for confirmation that it's not working for 4.3 and later.
So, it seems like there is no way to reflash this phone w/ anything w/o wiping the data (4.3 and after) -- which was what this question was about.
So maybe this bears repeating (to be clear). The question is:
Is there a way to recover from a boot loop caused by an OTA update from 4.3 to 4.4 when it is a stock and unrooted rom, with a stock (locked) boot loader without losing data?
-or- Is there a way to recover the data in such a state?
Of course there seems to be a way to JTAG it, but... that scares me (since I've never done that kind of stuff): http://forensicswiki.org/wiki/JTAG_LG_E960_(Nexus_4)
But I do have another question, if I accidentally interrupted the flash, is it possible to get it going again?
This might be insightful (but probably not).
--------
Code:
mbpro:occam-krt16s tofumaster$ ./flash-all.sh
sending 'bootloader' (2203 KB)...
OKAY [ 0.072s]
writing 'bootloader'...
FAILED (remote: not supported in locked device)
finished. total time: 0.073s
rebooting into bootloader...
OKAY [ 0.001s]
finished. total time: 0.001s
sending 'radio' (45537 KB)...
OKAY [ 1.437s]
writing 'radio'...
FAILED (remote: not supported in locked device)
finished. total time: 1.438s
rebooting into bootloader...
OKAY [ 0.001s]
finished. total time: 0.001s
archive does not contain 'boot.sig'
archive does not contain 'recovery.sig'
archive does not contain 'system.sig'
archive does not contain 'vendor.img'
Creating filesystem with parameters:
Size: 6189744128
Block size: 4096
Blocks per group: 32768
Inodes per group: 8048
Inode size: 256
Journal blocks: 23612
Label:
Blocks: 1511168
Block groups: 47
Reserved block group size: 375
Created filesystem with 11/378256 inodes and 50366/1511168 blocks
Creating filesystem with parameters:
Size: 587202560
Block size: 4096
Blocks per group: 32768
Inodes per group: 7168
Inode size: 256
Journal blocks: 2240
Label:
Blocks: 143360
Block groups: 5
Reserved block group size: 39
Created filesystem with 11/35840 inodes and 4616/143360 blocks
--------------------------------------------
Bootloader Version...: MAKOZ20i
Baseband Version.....: M9615A-CEFWMAZM-2.0.1700.84
Serial Number........: 0xxxxxxxxxxxxxxb
--------------------------------------------
checking product...
OKAY [ 0.002s]
checking version-bootloader...
FAILED
Device version-bootloader is 'MAKOZ20i'.
Update requires 'MAKOZ30d'.
finished. total time: 0.010s
Code:
mbpro:occam-krt16s tofumaster$ cd ..
mbpro:Nexus4 tofumaster$ ls
occam-jwr66y-factory-74b1deab_(v4.3).tgz occam-krt16s-factory-2006f418_(v4.4).md5
occam-krt16s occam-krt16s-factory-2006f418_(v4.4).tgz
mbpro:Nexus4 tofumaster$ md5 occam-jwr66y-factory-74b1deab_\(v4.3\).tgz > occam-jwr66y-factory-74b1deab_\(v4.3\).md5
mbpro:Nexus4 tofumaster$ ls
occam-jwr66y-factory-74b1deab_(v4.3).md5 occam-krt16s-factory-2006f418_(v4.4).md5
occam-jwr66y-factory-74b1deab_(v4.3).tgz occam-krt16s-factory-2006f418_(v4.4).tgz
occam-krt16s
mbpro:Nexus4 tofumaster$ cat *.md5
MD5 (occam-jwr66y-factory-74b1deab_(v4.3).tgz) = 6f6db7729bc6b8089683bc5297a09b93
MD5 (occam-krt16s-factory-2006f418_(v4.4).tgz) = e60c3077c9bc9bd106eb3077992f0d6c
mbpro:Nexus4 tofumaster$ tar xvzf occam-jwr66y-factory-74b1deab_\(v4.3\).tgz
x occam-jwr66y/
x occam-jwr66y/radio-mako-m9615a-cefwmazm-2.0.1700.84.img
x occam-jwr66y/flash-base.sh
x occam-jwr66y/bootloader-mako-makoz20i.img
x occam-jwr66y/flash-all.bat
x occam-jwr66y/image-occam-jwr66y.zip
x occam-jwr66y/flash-all.sh
Code:
mbpro:Nexus4 tofumaster$ cd occam-jwr66y
mbpro:occam-jwr66y tofumaster$ ls
bootloader-mako-makoz20i.img flash-base.sh
flash-all.bat image-occam-jwr66y.zip
flash-all.sh radio-mako-m9615a-cefwmazm-2.0.1700.84.img
mbpro:occam-jwr66y tofumaster$ ./flash-all.sh
sending 'bootloader' (2201 KB)...
OKAY [ 0.072s]
writing 'bootloader'...
FAILED (remote: not supported in locked device)
finished. total time: 0.073s
rebooting into bootloader...
OKAY [ 0.001s]
finished. total time: 0.001s
sending 'radio' (54321 KB)...
OKAY [ 1.712s]
writing 'radio'...
FAILED (remote: not supported in locked device)
finished. total time: 1.713s
rebooting into bootloader...
OKAY [ 0.001s]
finished. total time: 0.001s
archive does not contain 'boot.sig'
archive does not contain 'recovery.sig'
archive does not contain 'system.sig'
archive does not contain 'vendor.img'
Creating filesystem with parameters:
Size: 6189744128
Block size: 4096
Blocks per group: 32768
Inodes per group: 8048
Inode size: 256
Journal blocks: 23612
Label:
Blocks: 1511168
Block groups: 47
Reserved block group size: 375
Created filesystem with 11/378256 inodes and 50366/1511168 blocks
Creating filesystem with parameters:
Size: 587202560
Block size: 4096
Blocks per group: 32768
Inodes per group: 7168
Inode size: 256
Journal blocks: 2240
Label:
Blocks: 143360
Block groups: 5
Reserved block group size: 39
Created filesystem with 11/35840 inodes and 4616/143360 blocks
--------------------------------------------
Bootloader Version...: MAKOZ20i
Baseband Version.....: M9615A-CEFWMAZM-2.0.1700.84
Serial Number........: 0xxxxxxxxxxxxxxb
--------------------------------------------
checking product...
OKAY [ 0.002s]
checking version-bootloader...
OKAY [ 0.002s]
checking version-baseband...
OKAY [ 0.002s]
sending 'boot' (6194 KB)...
OKAY [ 0.200s]
writing 'boot'...
FAILED (remote: not supported in locked device)
finished. total time: 0.213s
mbpro:occam-jwr66y tofumaster$ fastboot devices
0xxxxxxxxxxxxxxb fastboot
A solution!
Okay, just to update anyone following this thread.
I sideloaded this: http: // www . androidpolice . com /2013/11/21/the-nexus-4-finally-gets-4-4-heres-how-you-can-flash-the-kitkat-krt16s-ota-manually-root-or-unlock-not-required/
And it worked. But I haven't slept in over 24 hours, so... I think I'm going to sleep now (have to be up in another 4...). Will post more details later (or answer any questions).
More details
Okay, not much to add, but sometimes these details can be helpful in the future for other people.
When I first posted this, I was past the point of diminishing returns (e.g. where anything you do creates more problems than fixes them). So I was thinking down the wrong path.
ariesgodofwar pointed out that I was trying to apply a the Factory Image over the phone which was NOT the OTA image (which contains only the things it needs to do an update). This clued me in. The OTA update is always a patch. And I'm glad the factory images did not apply because inside the .tgz is a userdata.img which would have wiped all my data anyhow. So... lucky that did not happen.
Instead, I found a signed OTA update (at Android Police) and then used the adb "sideload" technique to apply it. Fortunately, it looked like either nothing was patched successfully the first time, or it happily skipped fully patched files (e.g. maybe it was a mix between 4.3 and 4.4 which was why it was stuck in a boot-loop) and never told me about it on the logs.
Anyhow, it seems to have patched okay, and then went back to the Recovery Menu where I did another Cache Partition Wipe just in case before rebooting. After that, it went to optimizing apps and everything worked as expected. :victory:
In the link above, there's another link that shows you exactly how to get it into the Recover Menu but here it is anyhow: http: // www . androidpolice . com /2012/11/13/android-4-2-build-jop40c-rolling-out-to-the-nexus-7-now-manual-download-link-available/
(btw, how on earth did I post links in the 2nd post???)
Okay...So I feel like a complete ID10T (IDIOT). I managed to Soft Brick Nexus 6P. Currently it goes between the white Google Logo with the unlock icon at the bottom and the "Your device software cannot be check for corruption Please lock the Bootloader." Image. I have tried using WUGFresh Toolkit to flash the files as well as just using the factory image to no avail.
I can get into TWRP but even when flashing CM13 it just sits at the white Google logo and does not continue.
Does anyone have any suggestions?
Perhaps try manually flashing factory instead of using wugfresh's toolkit. I had a similar situation and that's what got me lot of my jam, but that may have been because wugfresh's kit wasn't updated for all the marshmallow shenanigans. So make sure you're on the latest version too
jasonftfw said:
Perhaps try manually flashing factory instead of using wugfresh's toolkit. I had a similar situation and that's what got me lot of my jam, but that may have been because wugfresh's kit wasn't updated for all the marshmallow shenanigans. So make sure you're on the latest version too
Click to expand...
Click to collapse
I tried that as well. I installed the Android SDK and put the angler-mmb29m-factory-8c31db3f files in adb folder on that's on the root of C:\ and ran the flash-all.bat. It goes though the process but I still get the same bootlooping issue.
C:\adb>fastboot devices
8XV5T15B10000200 fastboot
C:\adb>flash-all
target reported max download size of 494927872 bytes
sending 'bootloader' (3526 KB)...
OKAY [ 0.137s]
writing 'bootloader'...
OKAY [ 0.208s]
finished. total time: 0.347s
rebooting into bootloader...
OKAY [ 0.125s]
finished. total time: 0.126s
target reported max download size of 494927872 bytes
sending 'radio' (48472 KB)...
OKAY [ 1.611s]
writing 'radio'...
OKAY [ 2.170s]
finished. total time: 3.782s
rebooting into bootloader...
OKAY [ 0.015s]
finished. total time: 0.017s
target reported max download size of 494927872 bytes
archive does not contain 'boot.sig'
archive does not contain 'recovery.sig'
archive does not contain 'system.sig'
archive does not contain 'vendor.sig'
Creating filesystem with parameters:
Size: 58688266240
Block size: 4096
Blocks per group: 32768
Inodes per group: 8192
Inode size: 256
Journal blocks: 32768
Label:
Blocks: 14328190
Block groups: 438
Reserved block group size: 1024
Created filesystem with 11/3588096 inodes and 271280/14328190 blocks
Creating filesystem with parameters:
Size: 104857600
Block size: 4096
Blocks per group: 32768
Inodes per group: 6400
Inode size: 256
Journal blocks: 1024
Label:
Blocks: 25600
Block groups: 1
Reserved block group size: 7
Created filesystem with 11/6400 inodes and 1438/25600 blocks
--------------------------------------------
Bootloader Version...: angler-02.45
Baseband Version.....: angler-02.50
Serial Number........: MY SN
--------------------------------------------
checking product...
OKAY [ 0.020s]
checking version-bootloader...
OKAY [ 0.020s]
checking version-baseband...
OKAY [ 0.018s]
sending 'boot' (12045 KB)...
OKAY [ 0.428s]
writing 'boot'...
OKAY [ 0.184s]
sending 'recovery' (12981 KB)...
OKAY [ 0.453s]
writing 'recovery'...
OKAY [ 0.192s]
erasing 'system'...
OKAY [ 0.402s]
sending sparse 'system' (463062 KB)...
OKAY [ 15.904s]
writing 'system'...
OKAY [ 6.511s]
sending sparse 'system' (466961 KB)...
OKAY [ 16.220s]
writing 'system'...
OKAY [ 6.804s]
sending sparse 'system' (479253 KB)...
OKAY [ 17.006s]
writing 'system'...
OKAY [ 7.519s]
sending sparse 'system' (481623 KB)...
OKAY [ 16.713s]
writing 'system'...
OKAY [ 6.772s]
sending sparse 'system' (79148 KB)...
OKAY [ 2.786s]
writing 'system'...
OKAY [ 1.134s]
sending 'vendor' (185129 KB)...
OKAY [ 6.096s]
writing 'vendor'...
OKAY [ 3.017s]
erasing 'userdata'...
OKAY [ 1.012s]
sending 'userdata' (141002 KB)...
OKAY [ 4.674s]
writing 'userdata'...
OKAY [ 2.135s]
erasing 'cache'...
OKAY [ 0.091s]
sending 'cache' (5752 KB)...
OKAY [ 0.228s]
writing 'cache'...
OKAY [ 0.107s]
rebooting...
finished. total time: 116.562s
Press any key to exit...
Click to expand...
Click to collapse
I literally mean flash manual, like type it all out, I had issues with the flash all too
jasonftfw said:
I literally mean flash manual, like type it all out, I had issues with the flash all too
Click to expand...
Click to collapse
Thanks! I will try that and report back.
I tried manually typing out all the commands and it still just bootlooping at the Google logo. It will show it for about 22 seconds and then go black for 4 seconds. Any other suggestions?
What exactly did you do to softbrick it ?
If you connect with ADB, can you dump a log while booting ?
If not: what I'd try is do a factory reset, try a boot, when it loops, boot into TWRP. Then check if there's a log in /data/tombstones
gekkehenkie11 said:
What exactly did you do to softbrick it ?
If you connect with ADB, can you dump a log while booting ?
If not: what I'd try is do a factory reset, try a boot, when it loops, boot into TWRP. Then check if there's a log in /data/tombstones
Click to expand...
Click to collapse
Well when I received it, it was on 6.0.0 (MDB08L) so I rooted it and installed xposed framework. I was trying to install the OTA update for 6.0.1 and of course it failed with TWRP, so I decided I would just factory reset and start over and that was where the problem start. Once I rebooted it started bootlooping and has been doing so every since.
mxjcmxjc said:
Well when I received it, it was on 6.0.0 (MDB08L) so I rooted it and installed xposed framework. I was trying to install the OTA update for 6.0.1 and of course it failed with TWRP, so I decided I would just factory reset and start over and that was where the problem start. Once I rebooted it started bootlooping and has been doing so every since.
Click to expand...
Click to collapse
Hmm wish I knew a way how to help you but if you flashed all partitions to factory and also did a factory reset and if that still doesnt help, then I'd be out of idea's. I'd try to dump logs like I said in my previous posts, maybe there's something in there but still, it doesn't make any sense to me, so I doubt there's something in the logs to go by but who knows. ..
Maybe though it's encryption related ? I'm still a bit confused myself there how all that fits in.
gekkehenkie11 said:
Hmm wish I knew a way how to help you but if you flashed all partitions to factory and also did a factory reset and if that still doesnt help, then I'd be out of idea's. I'd try to dump logs like I said in my previous posts, maybe there's something in there but still, it doesn't make any sense to me, so I doubt there's something in the logs to go by but who knows. ..
Maybe though it's encryption related ? I'm still a bit confused myself there how all that fits in.
Click to expand...
Click to collapse
I checked the Tombstone folder and found 10 files there. Here is the link to the dumps. I really hope it helps.
mxjcmxjc said:
I checked the Tombstone folder and found 10 files there. Here is the link to the dumps. I really hope it helps.
Click to expand...
Click to collapse
Your error is "couldn't find an OpenGL ES implementation". So what we know:
1) The kernel boots
2) System image loads, it runs libEGL.so, this lib is in your system image.
3) libEGL.so tries to access the OpenGL implementation. This stuff is located in the vendor partition. And this is where it goes wrong. It says it cant find that file. What this means ? Not really sure. It could mean that the vendor partition is not good, maybe try to flash it again ? Also, what happens if you try to make a logcat during boot ? Issue:
adb logcat > out.txt
And see if it saves something after the bootloop. Maybe there's a better hint in there.
*EDIT2* also see if the openGL implementation is even there ! It should look like this:
[email protected]:/vendor/lib64/egl # ls -al
-rw-r--r-- root root 47200 2009-01-01 04:00 eglSubDriverAndroid.so
-rw-r--r-- root root 103256 2009-01-01 04:00 libEGL_adreno.so
-rw-r--r-- root root 210776 2009-01-01 04:00 libGLESv1_CM_adreno.so
-rw-r--r-- root root 7288296 2009-01-01 04:00 libGLESv2_adreno.so
-rw-r--r-- root root 661552 2009-01-01 04:00 libq3dtools_adreno.so
-rw-r--r-- root root 361800 2009-01-01 04:00 libq3dtools_esx.so
[email protected]:/vendor/lib64/egl #
gekkehenkie11 said:
Your error is "couldn't find an OpenGL ES implementation". So what we know:
1) The kernel boots
2) System image loads, it runs libEGL.so, this lib is in your system image.
3) libEGL.so tries to access the OpenGL implementation. This stuff is located in the vendor partition. And this is where it goes wrong. It says it cant find that file. What this means ? Not really sure. It could mean that the vendor partition is not good, maybe try to flash it again ? Also, what happens if you try to make a logcat during boot ? Issue:
adb logcat > out.txt
And see if it saves something after the bootloop. Maybe there's a better hint in there.
*EDIT2* also see if the openGL implementation is even there ! It should look like this:
[email protected]:/vendor/lib64/egl # ls -al
-rw-r--r-- root root 47200 2009-01-01 04:00 eglSubDriverAndroid.so
-rw-r--r-- root root 103256 2009-01-01 04:00 libEGL_adreno.so
-rw-r--r-- root root 210776 2009-01-01 04:00 libGLESv1_CM_adreno.so
-rw-r--r-- root root 7288296 2009-01-01 04:00 libGLESv2_adreno.so
-rw-r--r-- root root 661552 2009-01-01 04:00 libq3dtools_adreno.so
-rw-r--r-- root root 361800 2009-01-01 04:00 libq3dtools_esx.so
[email protected]:/vendor/lib64/egl #
Click to expand...
Click to collapse
I'm not getting any output from logcat when trying to boot it seems.
I just sit there like this.
C:\adb>adb logcat > out.txt
- waiting for device -
mxjcmxjc said:
I'm not getting any output from logcat when trying to boot it seems.
I just sit there like this.
C:\adb>adb logcat > out.txt
- waiting for device -
Click to expand...
Click to collapse
Ok so it's not getting to that point, which makes sense I realize now, since first thing it does is trying to get display up (it's not even getting beyond that).
So, let's see if your vendor partition seems correct. boot into TWRP, connect via 'adb shell', then 'mount /vendor' and then:
Code:
ls -al /vendor/lib64/egl
and see if all the files are there that I listed in my post on the previous page of this thread
I'm having the same issue. I stupidly tried to flash the OTA update via TWRP and now the phone won't go past the Google logo. Even when I restore my backup, it still won't go past that screen.
I didn't back up the vendor partition though (didn't know that I needed to).
My phone was not rooted. All I had was the custom recovery so that I can install MoaAB.
Now I have to wait until tomorrow because my USB C to USB A cable is at work. Hopefully we can get this fixed soon.
gekkehenkie11 said:
Ok so it's not getting to that point, which makes sense I realize now, since first thing it does is trying to get display up (it's not even getting beyond that).
So, let's see if your vendor partition seems correct. boot into TWRP, connect via 'adb shell', then 'mount /vendor' and then:
Code:
ls -al /vendor/lib64/egl
and see if all the files are there that I listed in my post on the previous page of this thread
Click to expand...
Click to collapse
Sorry for the late reply...
Yes the files are there. I was able to mount the vendor partition in TWRP and then use the File Manager to see the directory.
https://www.dropbox.com/s/3yq97hs75me933m/IMG_20151211_002153.jpg?dl=0
Just another detail. Whenever I restarted the device prior to bootlooping. I would have to enter my pattern before Android would start.
Closed at OP's request.
Brief synopsis
Bootloader unlock isn't likely. Amazon provide the facility to unlock the bootloader, but there is no way of getting the key.
The program which is locking the bootloader appears to be specific to MediaTek and Amazon, therefore, there isn't any source code.
The partitions with an Android bootimg header are all signed with two Amazon certificates. This includes the Little Kernel (LK) and the kernel itself.
The preloader is custom built for Amazon. The preloader doesn't respond to SP Flash Tool because it's constantly in a reboot loop when in 'META mode'. I presume it's intentional; a different version can however be installed (See 'However...').
However...
@bibikalka has found some strings in tz.img refering to a bootloader unlock. There is an amzn_unlock_verify function in lk too.
There must be a is a way to get the preloader to work properly with SP Flash Tool. However, this won't allow you custom ROMs, just reinstall Amazon's software. The software installed is still verified during the boot process. See this unbrick guide to install a different preloader. The preloader is not signed or checked by the boot process.
There is a small chance some part of the boot process could be fooled.
Downgrade potential
An anti-rollback program appears to have been built in to the bootloader which prevents any attempt at downgrading the software on the device. This is rather irritating, and means that downgrading is almost impossible. Only the preloader seems to be unaffected by this anti-rollback system – so, if you attempted to downgrade, and caused your device to become bricked, then you can restore the version you left.
Note that I vaguely reference to the preloader, uboot and lk collectively as 'the bootloader'.
Original post
I previously had downloaded the 5.0.1 and 5.1.1 LK versions, and thought, why not run these through binwalk?
For the old, 5.0.1 bootloader, putting lk.bin through binwalk gave:
Code:
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
204256 0x31DE0 SHA256 hash constants, little endian
292292 0x475C4 Android bootimg, kernel size: 0 bytes, kernel addr: 0x5D73255B, ramdisk size: 1869570592 bytes, ramdisk addr: 0x6D692074, product name: ""
330144 0x509A0 Unix path: /mnt/build/workspace/fireos-release_500-patch-build/bootable/bootloader/ufbl-features/project/../features/common_openssl/crypto/
330752 0x50C00 Unix path: /mnt/build/workspace/fireos-release_500-patch-build/bootable/bootloader/ufbl-features/project/../features/common_openssl/crypto/
334248 0x519A8 Unix path: /mnt/build/workspace/fireos-release_500-patch-build/bootable/bootloader/ufbl-features/project/../features/common_openssl/crypto/
339912 0x52FC8 Unix path: /mnt/build/workspace/fireos-release_500-patch-build/bootable/bootloader/ufbl-features/project/../features/common_openssl/crypto/
341028 0x53424 Unix path: /mnt/build/workspace/fireos-release_500-patch-build/bootable/bootloader/ufbl-features/project/../features/common_openssl/crypto/
350360 0x55898 Unix path: /mnt/build/workspace/fireos-release_500-patch-build/bootable/bootloader/ufbl-features/project/../features/common_openssl/crypto/
351732 0x55DF4 Certificate in DER format (x509 v3), header length: 4, sequence length: 1067
353656 0x56578 Certificate in DER format (x509 v3), header length: 4, sequence length: 1069
369736 0x5A448 CRC32 polynomial table, little endian
397548 0x610EC LZMA compressed data, properties: 0x91, dictionary size: 33554432 bytes, uncompressed size: 134217728 bytes
Whilst the 5.1.1 bootloader's lk.bin gave:
Code:
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
204960 0x320A0 SHA256 hash constants, little endian
293720 0x47B58 Android bootimg, kernel size: 0 bytes, kernel addr: 0x5D73255B, ramdisk size: 1869570592 bytes, ramdisk addr: 0x6D692074, product name: ""
332024 0x510F8 Unix path: /mnt/build/workspace/fireos-ship_511-patch-build/bootable/bootloader/ufbl-features/project/../features/common_openssl/crypto/cry
332628 0x51354 Unix path: /mnt/build/workspace/fireos-ship_511-patch-build/bootable/bootloader/ufbl-features/project/../features/common_openssl/crypto/mem
336096 0x520E0 Unix path: /mnt/build/workspace/fireos-ship_511-patch-build/bootable/bootloader/ufbl-features/project/../features/common_openssl/crypto/asn
341712 0x536D0 Unix path: /mnt/build/workspace/fireos-ship_511-patch-build/bootable/bootloader/ufbl-features/project/../features/common_openssl/crypto/evp
342820 0x53B24 Unix path: /mnt/build/workspace/fireos-ship_511-patch-build/bootable/bootloader/ufbl-features/project/../features/common_openssl/crypto/obj
352064 0x55F40 Unix path: /mnt/build/workspace/fireos-ship_511-patch-build/bootable/bootloader/ufbl-features/project/../features/common_openssl/crypto/x50
353420 0x5648C Certificate in DER format (x509 v3), header length: 4, sequence length: 1067
355344 0x56C10 Certificate in DER format (x509 v3), header length: 4, sequence length: 1069
371656 0x5ABC8 CRC32 polynomial table, little endian
So there you go! The bootloader uses OpenSSL to check the partition against two DER format certificates. Ignore the LZMA header for now; binwalk thinks almost everything is LZMA compressed.
Can you run binwalk with -e and post the 5.1.1 certs here
benwaffle said:
Can you run binwalk with -e and post the 5.1.1 certs here
Click to expand...
Click to collapse
Look at the thread about the 5.1.1 lk.bin in this forum and download the binary so you can run binwalk on it yourself.
Here is the lk.bin file, zipped. You can try and run '-e' on this binary.
The extracted certificates appear to contain format strings for decompression/compression error and debug messages. It doesn't look right. But the top of the files are valid certificate headers (or appear to be to the untrained eye).
Thanks @benwaffle.
Good effort!
I shall note that Amazon must have a way to un-brick the devices with MTK tools, they would not swap motherboards in order to revive them ...
The problem with the public MTK tools that it's even impossible to create a scatter file automatically (read only operation), meaning that the formats are such that MTK tools don't understand:
http://forum.xda-developers.com/fire-hd/help/mtk-tools-people-hopeless-bricks-t3139784
There is also an attempt to look at which partitions change when 5.0.1 goes to 5.1.1, and frankly, it's not many places to hide (only a couple of partitions):
http://forum.xda-developers.com/amazon-fire/help/understand-5-1-1-bootloader-bricking-fix-t3301991
On Fire 2014 I also looked at the strings within the bootloaders, and they had some interesting stuff regarding unlocking:
http://forum.xda-developers.com/showpost.php?p=61288384&postcount=57
I wonder if it's possible to patch the very first thing that boots (preloader), and have it pass the unlocking flags around ? Or is preloader also encrypted fully ?
bibikalka said:
Good effort!
I shall note that Amazon must have a way to un-brick the devices with MTK tools, they would not swap motherboards in order to revive them ...
The problem with the public MTK tools that it's even impossible to create a scatter file automatically (read only operation), meaning that the formats are such that MTK tools don't understand:
http://forum.xda-developers.com/fire-hd/help/mtk-tools-people-hopeless-bricks-t3139784
There is also an attempt to look at which partitions change when 5.0.1 goes to 5.1.1, and frankly, it's not many places to hide (only a couple of partitions):
http://forum.xda-developers.com/amazon-fire/help/understand-5-1-1-bootloader-bricking-fix-t3301991
On Fire 2014 I also looked at the strings within the bootloaders, and they had some interesting stuff regarding unlocking:
http://forum.xda-developers.com/showpost.php?p=61288384&postcount=57
I wonder if it's possible to patch the very first thing that boots (preloader), and have it pass the unlocking flags around ? Or is preloader also encrypted fully ?
Click to expand...
Click to collapse
Thanks @bibikalka!
Yes – Amazon must have a way of flashing firmware. I wonder if there is a JTAG header on the board as well. The Fire HD 6 had a 'JDEBUG' port, as seen in iFixit's teardown photographs: https://www.ifixit.com/Teardown/Kindle+Fire+HD+6+Teardown/29815#s70239
There might be a bootloader unlock then! It might need someone to decompile uboot to see how to trigger the unlock.
I've only managed to get the preloader_prod.img at this moment in time (I haven't taken preloader.img off). The SHA256 hash starts at around 95% (117KB out of 121KB) of the file, according to binwalk.
Hi,
I'm sorry to shatter hopes for bootloader rollback, but I was looking at the strings in preloader_prod.img and found this:
Code:
$ strings images/preloader_prod.img | grep -i rollback
[ANTI-ROLLBACK] Processing anti-rollback data
[ANTI-ROLLBACK] Failed to read block 0
[ANTI-ROLLBACK] PL: %x TEE: %x LK: %x
[ANTI-ROLLBACK] Need to update version
[ANTI-ROLLBACK] Invalid checksum!
[ANTI-ROLLBACK] Checksum validated
[ANTI-ROLLBACK] PL version mismatch!
[ANTI-ROLLBACK] L: %x R: %x
[ANTI-ROLLBACK] Updating PL version
[ANTI-ROLLBACK] TEE version mismatch!
[ANTI-ROLLBACK] Updating TEE version
[ANTI-ROLLBACK] LK version mismatch!
[ANTI-ROLLBACK] Updating LK version
[ANTI-ROLLBACK] All checks passed
[ANTI-ROLLBACK] Updating RPMB block...
[ANTI-ROLLBACK] Unable to update RPMB block (wc)
[ANTI-ROLLBACK] Unable to update RPMB block (write)
[ANTI-ROLLBACK] RPMB block updated
[RPMB] Failed to initialize anti-rollback block
[RPMB] Anti-rollback block initialized
[RPMB] Valid anti-rollback block exists
[ANTI-ROLLBACK] Invalid anti-rollback state, skipping
There is more stuff when looking for rpmb...
A little bit of googling leads to: https://docs.google.com/viewer?url=patentimages.storage.googleapis.com/pdfs/US20140250290.pdf
This doesn't look good at all
These strings might give a bit hope:
Code:
[RPMB] Invalid magic, re-creating...
[RTC] clear rpmb program mode flag in rtc register
So something could be stored in the realtime clock and the device might recover if the RPMB block gets destroyed. I can't find any mention of OTP or fuses in the image.
EDIT: It seems rpmb can be accessed through /dev/block/mmcblk0rpmb. I've uploaded mine (5.0.1) to: http://bork.cs.fau.de/~michael/fire/
It seems to only contain a few ones and many zeroes.
It would be interesting to get the rpmb of a 5.1.1 device to compare:
Code:
$ adb shell
[email protected]:/ $ su
[email protected]:/ # dd if=/dev/block/mmcblk0rpmb of=/sdcard/rpmb.bin
1024+0 records in
1024+0 records out
524288 bytes transferred in 0.093 secs (5637505 bytes/sec)
I would not advise trying to flash the 5.0.1 rpmb to a 5.1.1 device!
Regards,
Michael
stargo said:
Hi,
I'm sorry to shatter hopes for bootloader rollback, but I was looking at the strings in preloader_prod.img and found this:
Code:
$ strings images/preloader_prod.img | grep -i rollback
[ANTI-ROLLBACK] Processing anti-rollback data
[ANTI-ROLLBACK] Failed to read block 0
[ANTI-ROLLBACK] PL: %x TEE: %x LK: %x
[ANTI-ROLLBACK] Need to update version
[ANTI-ROLLBACK] Invalid checksum!
[ANTI-ROLLBACK] Checksum validated
[ANTI-ROLLBACK] PL version mismatch!
[ANTI-ROLLBACK] L: %x R: %x
[ANTI-ROLLBACK] Updating PL version
[ANTI-ROLLBACK] TEE version mismatch!
[ANTI-ROLLBACK] Updating TEE version
[ANTI-ROLLBACK] LK version mismatch!
[ANTI-ROLLBACK] Updating LK version
[ANTI-ROLLBACK] All checks passed
[ANTI-ROLLBACK] Updating RPMB block...
[ANTI-ROLLBACK] Unable to update RPMB block (wc)
[ANTI-ROLLBACK] Unable to update RPMB block (write)
[ANTI-ROLLBACK] RPMB block updated
[RPMB] Failed to initialize anti-rollback block
[RPMB] Anti-rollback block initialized
[RPMB] Valid anti-rollback block exists
[ANTI-ROLLBACK] Invalid anti-rollback state, skipping
There is more stuff when looking for rpmb...
A little bit of googling leads to: https://docs.google.com/viewer?url=patentimages.storage.googleapis.com/pdfs/US20140250290.pdf
This doesn't look good at all
These strings might give a bit hope:
Code:
[RPMB] Invalid magic, re-creating...
[RTC] clear rpmb program mode flag in rtc register
So something could be stored in the realtime clock and the device might recover if the RPMB block gets destroyed. I can't find any mention of OTP or fuses in the image.
EDIT: It seems rpmb can be accessed through /dev/block/mmcblk0rpmb. I've uploaded mine (5.0.1) to: http://bork.cs.fau.de/~michael/fire/
It seems to only contain a few ones and many zeroes.
It would be interesting to get the rpmb of a 5.1.1 device to compare:
Code:
$ adb shell
[email protected]:/ $ su
[email protected]:/ # dd if=/dev/block/mmcblk0rpmb of=/sdcard/rpmb.bin
1024+0 records in
1024+0 records out
524288 bytes transferred in 0.093 secs (5637505 bytes/sec)
I would not advise trying to flash the 5.0.1 rpmb to a 5.1.1 device!
Regards,
Michael
Click to expand...
Click to collapse
How interesting. Thanks @stargo! I've updated the OP accordingly to your findings. Yes, it seems more complex than previously thought. I'll upload my 5.1.1 rpmb binary soon.
Hi there! As se en within I read mtk is a very hard platform to work with, because they are very closed, and they hardly ever release any source, so most Roms are ports of a similar decide. I'll have a search for a device with this same soc to ser if i can come back with related info. That's why I'm surprised we have cm here!
RESTOCK is a new Nexus 7 2013 repair and factory reset tool for Windows. The NRT app (Nexus Root Toolkit) is similar but is old, closed-source, unsupported, abandoned, does no eMMC diagnostics and most importantly - it offers no repartitioning. Unlike NRT, Restock is specialized and optimized for Nexus 7'13 only, with streamlined operation and minimal user input.
If fastboot mode is available, then no matter what software problems like bootloops or softbricks are observed, or what custom ROM you had used before - Restock will restore your tablet to original, latest stock image, factory setup in 10 minutes (more time for one-off components download if necessary). Unforeseen issues should be reported in this thread and hopefully will be resolved within 24 hours.
If fastboot mode is not available, try the unbricking guide first.
For hardware issues, check this thread.
FEATURES
supports both flo and deb variants
small app download size (2.5MB)
automatic latest stock image (mob30x) and USB driver download from official google.com locations
robust, reliable USB device detection and driver installation - tested on Windows: XP-32, W7-32/64, W10-64(1809)
eMMC memory test and diagnostics
automatic device unlocking
option of repartition to original factory layout
- precise and reliable for any eMMC size, including 64GB and 128GB mods
- required for repartition scripts which check for original layout and flashing specific custom ROMs like e.g. Ubuntu Touch
- advised for selling in original factory condition and resolving difficult ROM flashing issues and starting from scratch
minimal user interaction and fully scripted auto-processing
the Restock script is open for inspection, corrections and improvements; post your comments and suggestions here
USAGE
download the attached zip file
unzip it
double-click on "restock.bat"
follow the prompts
SAMPLE OUTPUT
Code:
Nexus 7'13 Restock v1 @2019 k23m
SUPPORT - http://bit.ly/2C35sLZ
WARNING - installing factory image will ERASE ALL DATA from the device
Enter device name [flo OR deb]: flo
Downloading USB drivers and the latest factory image.
If not deleted, will not be downloaded again.
-- https://dl-ssl.google.com/android/repository/latest_usb_driver_windows.zip
Resolving dl-ssl.google.com... 74.125.24.190, 74.125.24.91, 74.125.24.93, ...
Connecting to dl-ssl.google.com|74.125.24.190|:443... connected.
WARNING: cannot verify dl-ssl.google.com's certificate, issued by 'CN=GTS CA 1O1,O=Google Trust Services,C=US':
Unable to locally verify the issuer's authority.
HTTP request sent, awaiting response... 200 OK
Length: 8682859 (8.3M) [application/zip]
Saving to: 'latest_usb_driver_windows.zip'
latest_usb_driver_windows.zip 14%[======> ] 1.21M 383KB/s eta 19s
...
-- https://dl.google.com/dl/android/aosp/razor-mob30x-factory-52684dff.zip
Resolving dl.google.com... 172.217.25.46
Connecting to dl.google.com|172.217.25.46|:443... connected.
WARNING: cannot verify dl.google.com's certificate, issued by 'CN=GTS CA 1O1,O=Google Trust Services,C=US':
Unable to locally verify the issuer's authority.
HTTP request sent, awaiting response... 200 OK
Length: 505296115 (482M) [application/zip]
Saving to: 'razor-mob30x-factory-52684dff.zip'
razor-mob30x-factory-52684dff 86%[=============================> ] 417.98M 410KB/s eta 2m 57s
...
1. boot the Nexus in fastboot mode: when OFF press POWER + VOLUME DOWN
2. when in the bootloader menu, connect it to your PC
3. wait a few seconds, then...
Press any key to continue . . .
...
...
INFO: Successfull installation of 'd:\restock\data\usb_driver\android_winusb.inf'.
INFO: Returning with code 0x1
Device not found...
1. disconnect it from PC
2. reboot to bootloader again
3. reconnect it to PC
Press any key to continue . . .
Verify...
eMMC test...
If it freezes here, the chip is faulty and needs replacement.
eMMC OK
Lock status...
GPT...
Partitions had been changed.
Restore original partitions? [y/n]: y
Wait...
sending 'bootloader' (3911 KB)...
OKAY [ 0.141s]
writing 'bootloader'...
OKAY [ 1.518s]
finished. total time: 1.658s
rebooting into bootloader...
OKAY [ -0.000s]
finished. total time: 0.008s
Wait...
sending 'gpt' (35 KB)...
OKAY [ 0.016s]
writing 'gpt'...
OKAY [ 0.109s]
finished. total time: 0.141s
rebooting into bootloader...
OKAY [ -0.000s]
finished. total time: 0.012s
If error, copy and post it, include restock.log
http://bit.ly/2C35sLZ
Note: Android flash takes 2 minutes, initial boot takes 7 minutes.
Press any key to continue . . .
sending 'bootloader' (3915 KB)...
OKAY [ 0.125s]
writing 'bootloader'...
OKAY [ 1.377s]
finished. total time: 1.502s
rebooting into bootloader...
OKAY [ 0.000s]
finished. total time: 0.007s
archive does not contain 'boot.sig'
archive does not contain 'recovery.sig'
archive does not contain 'system.sig'
--------------------------------------------
Bootloader Version...: FLO-04.08
Baseband Version.....: none
Serial Number........: xxxxxxxxx
--------------------------------------------
checking product...
OKAY [ 0.016s]
checking version-bootloader...
OKAY [ 0.000s]
sending 'boot' (7422 KB)...
OKAY [ 0.234s]
writing 'boot'...
OKAY [ 1.000s]
sending 'recovery' (8166 KB)...
OKAY [ 0.266s]
writing 'recovery'...
OKAY [ 0.328s]
erasing 'system'...
OKAY [ 1.143s]
sending 'system' (843549 KB)...
OKAY [ 26.516s]
writing 'system'...
OKAY [ 39.986s]
erasing 'userdata'...
OKAY [ 23.750s]
formatting 'userdata' partition...
Creating filesystem with parameters:
Size: 28856791040
Block size: 4096
Blocks per group: 32768
Inodes per group: 8192
Inode size: 256
Journal blocks: 32768
Label:
Blocks: 7045115
Block groups: 215
Reserved block group size: 1024
Created filesystem with 11/1761280 inodes and 154578/7045115 blocks
sending 'userdata' (139085 KB)...
writing 'userdata'...
OKAY [ 12.434s]
erasing 'cache'...
OKAY [ 0.437s]
formatting 'cache' partition...
Creating filesystem with parameters:
Size: 587202560
Block size: 4096
Blocks per group: 32768
Inodes per group: 7168
Inode size: 256
Journal blocks: 2240
Label:
Blocks: 143360
Block groups: 5
Reserved block group size: 39
Created filesystem with 11/35840 inodes and 4616/143360 blocks
sending 'cache' (10984 KB)...
writing 'cache'...
OKAY [ 0.891s]
rebooting...
finished. total time: 107.057s
Press any key to exit...
RESTOCK 2
SCRIPTS
restock.bat - the main script: stock install, repair, repartition and factory reset
addons.bat - install TWRP custom recovery, mob30x-fix1, root/Magisk, ElementalX-N7-6.17 kernel
fstrim.bat - faster eMMC writes: dispatches TRIM command for all unused filesystem blocks
safe-unlock.bat - unlock without data loss
getlog.bat - diagnostics #1
relog.bat - diagnostics #2
ADDONS
These addons should be installed immediately after RESTOCK and before Android setup:
TWRP deb/flo custom recovery (it must be flashed before the other addon options)
MOB30X-FIX1 - improved Android 6.0.1 stock MOB30X installation, info: https://forum.xda-developers.com/showthread.php?t=4021757 In short, it adds WiFi 'Skip' setup option and removes old GApps to increase space on the system partition
root/Magisk - https://github.com/topjohnwu/Magisk
ElementalX-N7-6.17 custom kernel - I recommend to preset "doubletap2wake" and "battery life extender". For car use also preset "USB OTG + charge mode", info: https://forum.xda-developers.com/showthread.php?t=2389022
ERRORS
If you see errors, copy and report them. Run getlog.bat and include "getlog.log" in your post. If possible, also run relog.bat and attach "relog-xxxxxx.zip" to your post.
FSTRIM
For optimal eMMC performance run fstrim.bat from time to time.
SAFE UNLOCK
Unlock your device without data loss. MiFlash is described in the Unbricking Guide:
https://forum.xda-developers.com/showpost.php?p=75360854&postcount=199
Do not proceed unless you have read the unbricking guide and downloaded all components.
OPTIONS
Try mob30x-fix1 for improved Android 6.0.1 stock installation.
Next consider CROSS : 1-click installation of secure, up-to-date Android 7-to-11 custom ROMs, including TWRP, repartition, root, etc. as easily as RESTOCK.
NOTE
If Android is stuck on boot logo, with TWRP flash k23m-persist-fix2.zip
Did not even realize this was new! Thanks for making such a wonderfull tool! Currently using it to flash flo, and it works great!
Will install lineage after this tho
Code:
1. boot the Nexus in fastboot mode: when OFF press POWER + VOLUME DOWN
2. when in the bootloader menu, connect it to your PC
3. wait a few seconds, then...
Press any key to continue . . .
Verify...
eMMC test...
If it freezes here, the chip is faulty and needs replacement.
eMMC OK
Lock status...
GPT...
If error, copy and post it, include restock.log
[url]http://bit.ly/2C35sLZ[/url]
Note: Android flash takes 2 minutes, initial boot takes 7 minutes.
Press any key to continue . . .
sending 'bootloader' (3915 KB)...
OKAY [ 0.131s]
writing 'bootloader'...
OKAY [ 1.581s]
finished. total time: 1.719s
rebooting into bootloader...
OKAY [ 0.009s]
finished. total time: 0.014s
archive does not contain 'boot.sig'
archive does not contain 'recovery.sig'
archive does not contain 'system.sig'
--------------------------------------------
Bootloader Version...: FLO-04.08
Baseband Version.....: none
Serial Number........: 07206d7c
--------------------------------------------
checking product...
OKAY [ 0.003s]
checking version-bootloader...
OKAY [ 0.004s]
sending 'boot' (7422 KB)...
OKAY [ 0.239s]
writing 'boot'...
OKAY [ 0.397s]
sending 'recovery' (8166 KB)...
OKAY [ 0.265s]
writing 'recovery'...
OKAY [ 0.448s]
erasing 'system'...
OKAY [ 0.743s]
sending 'system' (843549 KB)...
OKAY [ 26.422s]
writing 'system'...
OKAY [ 51.719s]
erasing 'userdata'...
OKAY [ 9.570s]
formatting 'userdata' partition...
Creating filesystem with parameters:
Size: 13342060544
Block size: 4096
Blocks per group: 32768
Inodes per group: 8144
Inode size: 256
Journal blocks: 32768
Label:
Blocks: 3257339
Block groups: 100
Reserved block group size: 799
Created filesystem with 11/814400 inodes and 91881/3257339 blocks
sending 'userdata' (137198 KB)...
writing 'userdata'...
OKAY [ 12.298s]
erasing 'cache'...
OKAY [ 0.051s]
formatting 'cache' partition...
Creating filesystem with parameters:
Size: 587202560
Block size: 4096
Blocks per group: 32768
Inodes per group: 7168
Inode size: 256
Journal blocks: 2240
Label:
Blocks: 143360
Block groups: 5
Reserved block group size: 39
Created filesystem with 11/35840 inodes and 4616/143360 blocks
sending 'cache' (10984 KB)...
writing 'cache'...
OKAY [ 1.029s]
rebooting...
finished. total time: 103.239s
Press any key to exit...
Dang that was timely.
It's a big hammer for what could sometimes be a small problem but it works quickly and perfectly. The alternative is pulling hair out for hours while trying to find the easy fix.
Thanks for sharing.
wow my nexus 7 was in boot loop and i had an old NRT tool which wouldnt work at all.
computer wouldnt detect next 7 2013 thru usb cable
cannot mount usb-otg in TWRP
boot loop in custom rom
your tool fixed it so fast and easy.
THANKS SO MUCH FOR YOUR TOOL!!!
Thanks for this k23m although I hope to never have to use it. My Kingston equipped Nexus 7 is still going strong and it's my most used android device. If I run the emmc memory test and diagnostics would it tell me if the emmc is about to die and determine its overall wear and health?
Tmzdroid said:
Thanks for this k23m although I hope to never have to use it. My Kingston equipped Nexus 7 is still going strong and it's my most used android device. If I run the emmc memory test and diagnostics would it tell me if the emmc is about to die and determine its overall wear and health?
Click to expand...
Click to collapse
Hello Tmzdroid, your Kingston was from a newer production batch and probably is OK but maybe do not try any major OS/ROM changes as this most recent case demonstrates. The eMMC generation used in N7 has no "SMART" flash wear diagnostics like in SSD. This feature was introduced in eMMC v5+. Restock can identify Kingston if it has standard partitions and checks for the terminal, most common, read-only condition Kingstons suffer from. In short, the test can not indicate eMMC degradation level. The only forewarning you may get is a period of slow-downs prior to going read-only. If you feel it is happening, do fastboot format cache and if it takes longer than 2 seconds, it is almost the end and time to get your data out of the tablet, while you still can.
:highfive:
Thank you for this! It fixed my deb model <3
I'm getting "Incorrect device" trying to use Restock to recover from flo-deb_clamor_repartition. It's definitely flo, I am looking at the bootloader right now. fastboot format cache completes in 0.086 seconds. flo 32G, rev_e, bootloader FLO-04.08, no carrier, secure boot enabled, lock state unlocked.
edit: got going again with https://forum.xda-developers.com/showthread.php?t=2381582
AiRMaX-360 said:
Thank you for this! It fixed my deb model <3
Click to expand...
Click to collapse
Thank you for confirming that it works on deb. I have 3 flo's but no deb to test.
drinkypoo said:
I'm getting "Incorrect device" trying to use Restock to recover from flo-deb_clamor_repartition. It's definitely flo, I am looking at the bootloader right now. fastboot format cache completes in 0.086 seconds. flo 32G, rev_e, bootloader FLO-04.08, no carrier, secure boot enabled, lock state unlocked. edit: got going again with https://forum.xda-developers.com/showthread.php?t=2381582
Click to expand...
Click to collapse
Would you be able to post a log from the attached script? Unzip and run it in Restock's folder.
:fingers-crossed:
k23m said:
Would you be able to post a log from the attached script? Unzip and run it in Restock's folder.
:fingers-crossed:
Click to expand...
Click to collapse
Strangely, it won't run unless I run as administrator. I double-click it and nothing happens. If I run as administrator then it runs in c:\windows\system32 and doesn't list the contents of the directory you want... I even tried moving restock's folder into my user dir instead of under downloads just in case something about the path was causing problems. No idea WTF that is about. Perms look good. I went ahead and just ran the commands manually from a CMD shell in the proper directory, looks like they produced the output you were looking for... except the find command doesn't work there. Maybe it would work in command.com, dunno.
I'm not sure how much help this will be since I used other tools since trying to use restock, but here it is anyway.
drinkypoo said:
Strangely, it won't run unless I run as administrator. I double-click it and nothing happens. If I run as administrator then it runs in c:\windows\system32 and doesn't list the contents of the directory you want... I even tried moving restock's folder into my user dir instead of under downloads just in case something about the path was causing problems. No idea WTF that is about. Perms look good. I went ahead and just ran the commands manually from a CMD shell in the proper directory, looks like they produced the output you were looking for... except the find command doesn't work there. Maybe it would work in command.com, dunno. I'm not sure how much help this will be since I used other tools since trying to use restock, but here it is anyway.
Click to expand...
Click to collapse
It seems your Path env exceeds the limit:
Code:
Path=C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\Python27\;C:\Python27\Scripts;C:\ProgramData\Oracle\Java\javapath;C:\WinAVR-20100110\bin;C:\WinAVR-20100110\utils\bin;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\PuTTY;C:\Programs\Argyll_V1.7.0\bin;C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\;C:\Program Files (x86)\GitExtensions\;C:\Program Files\Git\cmd;C:\Windows;C:\ProgramData\ComposerSetup\bin;C:\Program Files\Calibre2\;C:\Program Files (x86)\sbt\bin;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Windows\system32;C:\Users\drink\AppData\Local\Android\Sdk\platform-tools;C:\Program Files (x86)\GNU Tools ARM Embedded\5.4 2016q3\bin;C:\Users\drink\AppData\Local\Android\Sdk\platform-tools;C:\Program Files (x86)\Nmap;C:\Programs\ffmpeg-20190208\bin;C:\Program Files (x86)\Atmel\Flip 3.4.7\bin;c:\programs\fastboot;C:\programs;"%~dp0data"
My path has only:
Code:
Path=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\
Please do:
Edit the path - Control Panel / System / Advanced System Settings / Advanced tab / Environment Variables button / in System Variables select Path / click Edit
copy original and save for reuse later
replace it with: C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\
save
reboot
run Restock
It should work now. As your N7 is already fixed, just close the window when it stops at "Note: Android flash takes 2 minutes, initial boot takes 7 minutes" and nothing will be flashed. Also, don't go ahead with "Restore original partitions? [y/n]" if it is offered.
If it still does not work, login to Windows with an admin account and then run Restock.
k23m said:
It seems your Path env exceeds the limit:
Click to expand...
Click to collapse
Sigh. Windows is garbage in so many ways.
I was just thinking I want to restore my Nexus back to 100% stock, and magically this recent thread appears. Worked perfectly. Thank you.
Strangely, only custom ROMs are working for me. I always get bootloop whenever I flash any of the razor Nexus Factory Images. I also tried the script you provided and finishes successfully, but when booting, it always end in bootloop with Google logo on it. I have access to fastboot and even can flash and boot to TWRP with no problemas. Any idea?
EDIT: Attached logs after re-running the script
bamsbamx said:
Strangely, only custom ROMs are working for me. I always get bootloop whenever I flash any of the razor Nexus Factory Images. I also tried the script you provided and finishes successfully, but when booting, it always end in bootloop with Google logo on it. I have access to fastboot and even can flash and boot to TWRP with no problemas. Any idea?
EDIT: Attached logs after re-running the script
Click to expand...
Click to collapse
It is a very interesting case. We need internal logs, please 'install' get-logs-sdcard.zip in TWRP, find 'logs.tgz' in the root of internal storage and post it here.
k23m said:
It is a very interesting case. We need internal logs, please 'install' get-logs-sdcard.zip in TWRP, find 'logs.tgz' in the root of internal storage and post it here.
Click to expand...
Click to collapse
Thanks for the quick reply, here I attach the logs... Seems like the /persist partition is empty, maybe thats the cause of the problem?
However, I can understand why that happened, maybe because I used the /system partition script for increasing its size...
EDIT: Somehow the XDA file uploader says invalid file for .tgz format, I recompressed the folder to a .zip file
bamsbamx said:
Thanks for the quick reply, here I attach the logs... Seems like the /persist partition is empty, maybe thats the cause of the problem?
However, I can understand why that happened, maybe because I used the /system partition script for increasing its size...
EDIT: Somehow the XDA file uploader says invalid file for .tgz format, I recompressed the folder to a .zip file
Click to expand...
Click to collapse
The 'persist' partition is not empty, you can see its contents in the log's 'ls_persist' file, but its SELinux contexts appear incorrect. Try this:
in TWRP backup your original 'persist' with the attached p4-backup-int.zip
go to my old post here, get those files and restore my 'persist' partition
boot stock ROM
:fingers-crossed:
k23m said:
The 'persist' partition is not empty, you can see its contents in the log's 'ls_persist' file, but its SELinux contexts appear incorrect. Try this:
in TWRP backup your original 'persist' with the attached p4-backup-int.zip
go to my old post here, get those files and restore my 'persist' partition
boot stock ROM
:fingers-crossed:
Click to expand...
Click to collapse
Still no luck. I have re-run the get-logs script and some file permissions have changed in le_persist (checked with a diff comparer), as well as new file called settings. Flashed factory image MOB30X and bootloop, then flash UnLegacy rom android 8.1.0 and boots with no problem. Cant understand what is happening... Maybe it is possible to use UART debugging to get some logs?
EDIT: Attached the new logs
bamsbamx said:
Still no luck. I have re-run the get-logs script and some file permissions have changed in le_persist (checked with a diff comparer), as well as new file called settings. Flashed factory image MOB30X and bootloop, then flash UnLegacy rom android 8.1.0 and boots with no problem. Cant understand what is happening... Maybe it is possible to use UART debugging to get some logs?
EDIT: Attached the new logs
Click to expand...
Click to collapse
This new log is much better. The timing was right and it had captured 'last_kmsg' with mob30x bootloop log, note:
Code:
[ 4.865234] init: Starting service 'logd'...
[ 4.873748] EXT4-fs error (device mmcblk0p23): ext4_mb_generate_buddy:741: group 1, 32282 clusters in bitmap, 32356 in gd
[ 4.873962] Aborting journal on device mmcblk0p23-8.
[ 4.874664] Kernel panic - not syncing: EXT4-fs (device mmcblk0p23): panic forced after error
...
[ 7.987304] Rebooting in 5 seconds..
[ 12.994476] Going down for restart now
[ 12.994628] in panic
It can't use mmcblk0p23 - the cache partition, and has to restart. New custom ROMs no longer use the cache partition and that's why they work. For comparison here is my 'last_kmsg' with mob30x...
Code:
[ 7.072235] EXT4-fs (mmcblk0p23): recovery complete
[ 7.077087] EXT4-fs (mmcblk0p23): mounted filesystem with ordered data mode. Opts: nomblk_io_submit,errors=remount-ro
[ 7.086883] fs_mgr: check_fs(): mount(/dev/block/platform/msm_sdcc.1/by-name/cache,/cache,ext4)=0: Success
[ 7.162567] fs_mgr: check_fs(): unmount(/cache) succeeded
[ 7.171722] fs_mgr: Running /system/bin/e2fsck on /dev/block/platform/msm_sdcc.1/by-name/cache
[ 7.264678] e2fsck: e2fsck 1.42.9 (28-Dec-2013)
[ 7.269744] e2fsck: /dev/block/platform/msm_sdcc.1/by-name/cache: clean, 23/35840 files, 4726/143360 blocks
[ 7.285522] EXT4-fs (mmcblk0p23): mounted filesystem with ordered data mode. Opts: barrier=1,data=ordered,nomblk_io_submit,errors=panic
[ 7.296874] fs_mgr: __mount(source=/dev/block/platform/msm_sdcc.1/by-name/cache,target=/cache,type=ext4)=0
...
[ 8.289031] init: Starting service 'logd'...
[ 8.302368] SELinux: Context u:object_r:cache_recovery_file:s0 is not valid (left unmapped).
[ 8.312286] SELinux: Context u:object_r:cache_private_backup_file:s0 is not valid (left unmapped).
[ 8.342254] init: (Loading properties from /system/build.prop took 0.01s.)
[ 8.348266] init: (Loading properties from /vendor/build.prop took 0.00s.)
[ 8.355133] init: (Loading properties from /factory/factory.prop took 0.00s.)
[ 8.369842] init: Starting service 'vold'...
[ 8.373321] logd.auditd: start
Run fastboot format cache and compare it to the 'sample output' from the first post.
There may be a partial eMMC hardware fault affecting the cache partition.
If you wish to investigate it with UART, please check my post on the subject.
:highfive:
k23m said:
This new log is much better. The timing was right and it had captured 'last_kmsg' with mob30x bootloop log, note:
Code:
[ 4.865234] init: Starting service 'logd'...
[ 4.873748] EXT4-fs error (device mmcblk0p23): ext4_mb_generate_buddy:741: group 1, 32282 clusters in bitmap, 32356 in gd
[ 4.873962] Aborting journal on device mmcblk0p23-8.
[ 4.874664] Kernel panic - not syncing: EXT4-fs (device mmcblk0p23): panic forced after error
...
[ 7.987304] Rebooting in 5 seconds..
[ 12.994476] Going down for restart now
[ 12.994628] in panic
It can't use mmcblk0p23 - the cache partition, and has to restart. New custom ROMs no longer use the cache partition and that's why they work. For comparison here is my 'last_kmsg' with mob30x...
Code:
[ 7.072235] EXT4-fs (mmcblk0p23): recovery complete
[ 7.077087] EXT4-fs (mmcblk0p23): mounted filesystem with ordered data mode. Opts: nomblk_io_submit,errors=remount-ro
[ 7.086883] fs_mgr: check_fs(): mount(/dev/block/platform/msm_sdcc.1/by-name/cache,/cache,ext4)=0: Success
[ 7.162567] fs_mgr: check_fs(): unmount(/cache) succeeded
[ 7.171722] fs_mgr: Running /system/bin/e2fsck on /dev/block/platform/msm_sdcc.1/by-name/cache
[ 7.264678] e2fsck: e2fsck 1.42.9 (28-Dec-2013)
[ 7.269744] e2fsck: /dev/block/platform/msm_sdcc.1/by-name/cache: clean, 23/35840 files, 4726/143360 blocks
[ 7.285522] EXT4-fs (mmcblk0p23): mounted filesystem with ordered data mode. Opts: barrier=1,data=ordered,nomblk_io_submit,errors=panic
[ 7.296874] fs_mgr: __mount(source=/dev/block/platform/msm_sdcc.1/by-name/cache,target=/cache,type=ext4)=0
...
[ 8.289031] init: Starting service 'logd'...
[ 8.302368] SELinux: Context u:object_r:cache_recovery_file:s0 is not valid (left unmapped).
[ 8.312286] SELinux: Context u:object_r:cache_private_backup_file:s0 is not valid (left unmapped).
[ 8.342254] init: (Loading properties from /system/build.prop took 0.01s.)
[ 8.348266] init: (Loading properties from /vendor/build.prop took 0.00s.)
[ 8.355133] init: (Loading properties from /factory/factory.prop took 0.00s.)
[ 8.369842] init: Starting service 'vold'...
[ 8.373321] logd.auditd: start
Run fastboot format cache and compare it to the 'sample output' from the first post.
There may be a partial eMMC hardware fault affecting the cache partition.
If you wish to investigate it with UART, please check my post on the subject.
:highfive:
Click to expand...
Click to collapse
Yeah, I had the idea of checking last_kmsg just after my previous post. Saw that mounting mmcblk0p30 was causing kernel panic. Ran TWRP Format Cache and err well... Bootloop was now in the boot animation (maybe I had to reflash factory image, which I didnt). Didnt see about mmcblk0p24, will format cache and post feedback. Thank you!
:highfive: