[Solved] 1050F Bricked : how-to for bios not working!

[Solved] 1050F Bricked : how-to for bios not working! - Thinkpad Tablet General

Hi.
I have tried to flash again my 1050F under lollipop.
I don't know why but it failed.
So I tried to follow this procedure : http://forum.xda-developers.com/showpost.php?p=62237383&postcount=5
I have the following error in intel phone flash tool : error: wipe_block_device: wipe not supported on non-linux platforms
I don't know what to do?!
Thank you for your help!
All actions before works :
01/08/16 23:25:24.818 INFO : Phone Flash Tool V 4.4.4-1 Win32 External (build on Mon Apr 28 09:56:35 UTC 2014)
01/08/16 23:25:24.818 INFO : Using xFSTK version: 1.5.3
01/08/16 23:25:24.857 INFO : Using Android Debug Bridge version 1.0.31
01/08/16 23:25:24.857 INFO : OS version detected: Windows 8 (x64)
01/08/16 23:25:24.965 INFO : Adb and fastboot binaries OK
01/08/16 23:25:24.968 INFO : Phone Flash Tool initialized successfully
01/08/16 23:25:24.976 INFO : Loading Flash file ...
01/08/16 23:25:24.977 INFO : Ready to flash!
01/08/16 23:25:50.121 INFO : Loading Flash file (D:/lenovo bios error/YT2-1050F_S0198_150422_ROW/target_bin/flash-LtoKK-DVT-810.xml)
01/08/16 23:25:50.123 INFO : GP_Flag is set to 0x80000045
01/08/16 23:25:50.124 INFO : Ready to flash!
01/08/16 23:25:52.815 INFO : Port 8/1: Flashing OS
01/08/16 23:25:52.816 INFO : Port 8/1: fastboot -s Baytrail5D3EBC03 -S 500M flash system "D:/lenovo bios error/YT2-1050F_S0198_150422_ROW/target_bin/system.img"
01/08/16 23:28:40.787 INFO : Port 8/1: fastboot -s Baytrail5D3EBC03 -S 500M flash fastboot "D:/lenovo bios error/YT2-1050F_S0198_150422_ROW/target_bin/droidboot.img"
01/08/16 23:28:44.115 INFO : Port 8/1: fastboot -s Baytrail5D3EBC03 -S 500M flash boot "D:/lenovo bios error/YT2-1050F_S0198_150422_ROW/target_bin/boot.img"
01/08/16 23:28:47.369 INFO : Port 8/1: fastboot -s Baytrail5D3EBC03 -S 500M flash recovery "D:/lenovo bios error/YT2-1050F_S0198_150422_ROW/target_bin/recovery.img"
01/08/16 23:28:51.376 INFO : Port 8/1: fastboot -s Baytrail5D3EBC03 -S 500M erase data
01/08/16 23:28:59.612 INFO : Port 8/1: fastboot -s Baytrail5D3EBC03 -S 500M format data
01/08/16 23:28:59.859 WARNING: Port 8/1: Failed to execute ""C:/Program Files (x86)/Intel/Phone Flash Tool/fastboot.exe" -s Baytrail5D3EBC03 -S 500M format data":
Creating filesystem with parameters:
Size: 12256768000
Block size: 4096
Blocks per group: 32768
Inodes per group: 8144
Inode size: 256
Journal blocks: 32768
Label:
Blocks: 2992375
Block groups: 92
Reserved block group size: 735
Created filesystem with 11/749248 inodes and 87153/2992375 blocks
formatting 'data' partition...
error: wipe_block_device: wipe not supported on non-linux platforms
sending 'data' (0 KB)...
FAILED ()
finished. total time: 0.137s
01/08/16 23:29:01.863 WARNING: Port 8/1: Retry to execute fastboot -s Baytrail5D3EBC03 -S 500M format data
01/08/16 23:29:02.045 WARNING: Port 8/1: Failed to execute ""C:/Program Files (x86)/Intel/Phone Flash Tool/fastboot.exe" -s Baytrail5D3EBC03 -S 500M format data":
Creating filesystem with parameters:
Size: 12256768000
Block size: 4096
Blocks per group: 32768
Inodes per group: 8144
Inode size: 256
Journal blocks: 32768
Label:
Blocks: 2992375
Block groups: 92
Reserved block group size: 735
Created filesystem with 11/749248 inodes and 87153/2992375 blocks
formatting 'data' partition...
error: wipe_block_device: wipe not supported on non-linux platforms
sending 'data' (0 KB)...
FAILED ()
finished. total time: 0.141s
01/08/16 23:29:04.045 ERROR : Port 8/1: Flash failure

1. first of all STOP from what you are doing! you should be thankful that 'format data' did not worked as one of the next operations would have HARD-BRICKED your tab! you were two steps away from flashing a WRONG bios and nothing would have saved you but a service repair!
2. go here and flash your Lollipop stock rom (no need to downgrade the bios just follow the steps in there)
ps. i have also gave you this link (with the instructions for flashing lollipop stock rom for the 1050f device) in another thread as a reply to a request you made (hours before you opened this new thread) yet i see you have ignored it completely. feel free to ignore this one as well and if you want i can give you the steps required for hard-bricking your tab so you don't need to try-hard (if that is what you really want).
oh boy...
@workdowg maybe you should delete all together those files as it seems they are confusing for some people (or they are not good for confused people?)

First of all, thank ionioni for your help.
I have read all the threads and I have tried to flash only lollipop firmware with the link you gave me.
I don't know why but the flash have not worked as expected... and I have seen the BIOS at reboot.... So I read the how-to, tried to open this thread.
I have understand with your advice I must stop that and I tried to flash again the file you gave me : firmware YT2-1050F_USR_S100031_1506111400_WW52_ROW-(L)
and.... Tadam... the flash work this time!!! I am so grateful... I thought the only solution would be the support service of lenovo...
I am actually upgrading the OTA firmwares of my tablet.... and it works perfectly.
Don't be offended, I try to follow your advices, and as you see, system partition, format data for android system is some voodoo for me

saupiquet said:
First of all, thank ionioni for your help.
I have read all the threads and I have tried to flash only lollipop firmware with the link you gave me.
I don't know why but the flash have not worked as expected... and I have seen the BIOS at reboot.... So I read the how-to, tried to open this thread.
I have understand with your advice I must stop that and I tried to flash again the file you gave me : firmware YT2-1050F_USR_S100031_1506111400_WW52_ROW-(L)
and.... Tadam... the flash work this time!!! I am so grateful... I thought the only solution would be the support service of lenovo...
I am actually upgrading the OTA firmwares of my tablet.... and it works perfectly.
Don't be offended, I try to follow your advices, and as you see, system partition, format data for android system is some voodoo for me
Click to expand...
Click to collapse
i wasn't understanding why would you skip over a safe way of flashing a stock rom and move to a dangerous one (and again you were just about to HARD-BRICK by flashing a WRONG bios, luckily for you that the script you used stopped because of the error when 'format data' command was executed). if you followed all the steps in the guide is quite unlikely that it didn't work (not to say that trying the same a second time it did ?!?)

Hello!
I have similar problem with my tablet, after trying to upgrade the other days my lollipop. In the process, my tablet turned black, and staid so for about 10 min before shutting it down by force. When I've turned it back on, after the logo, the screen was still turning black and couldn't do anything, so I've decided to flash it, with what I had from my friend ionioni. I'll attach my log.
Thanks for all your help!

murrder i got the same log exactly as you. did you find any solution. It happened to me after i started to ota update for lollipop on my rooted yoga 2 .. Plz help. cant get to any where now.
---------- Post added at 12:42 PM ---------- Previous post was at 12:22 PM ----------
murrder said:
Hello!
I have similar problem with my tablet, after trying to upgrade the other days my lollipop. In the process, my tablet turned black, and staid so for about 10 min before shutting it down by force. When I've turned it back on, after the logo, the screen was still turning black and couldn't do anything, so I've decided to flash it, with what I had from my friend ionioni. I'll attach my log.
Thanks for all your help!
Click to expand...
Click to collapse
ok i figured it out. I downloaded intel flastool LITE 5.5.1.0 and downloaded Lollipop firmware posted in one of these forums. I had to change force fastboot sparsing to 1700 mb in options of flash tool and flashed the firmware. It worked!
https://docs.google.com/uc?id=0B1LaMEhefCBgYzNTOUxJZmtWQ0E&export=download
this is where i downloaded lollipop firmware from..
Hope it helps you.

Related

[Q] Factory reset issues

I'm having some issues factory resetting my wife's Nexus 7.
The device has been running 4.4.0 for a while and was fine until it started boot lopping (gets to the lockscreen, sits there for a few seconds then eventually locks up and reboot).
It's completely stock (though I had it unlocked and rooted at some point).
I can get to bootloader mode but recovery shows "no command". I am sometimes able to bypass the error and get to recovery, full wipe did nothing.
I was able to get connected using Fastboot and tried wiping the device and returning it to stock using a factory image.
Everything appears to run correctly but when the device restarts nothing has been wiped and the rebooting issue remains.
I've tried to load a temp custom recovery (twrp) and it does load into it. I then tried to use the wipe feature within twrp but then again nothing really gets wiped.
At this point I'm not entirely sure what else to try to wipe it and reload.
I can only fastmode - adb doesn't work unless i flash the temp custom recovery which doesn't seem to help me do anything.

When you softboot a recovery, are you able to mount any filesystems (/cache, /system, /data)?
e.g. using adb check to see what is mounted
Code:
C:\bleh> adb shell cat /proc/mounts
do any of them (/cache, /system, /data) that are already mounted indicate that they are mounted read-only?
for each filesystem (in /cache, /system, /data) that are not mounted, try mounting them "by hand"
e.g. /data partition
Code:
C:\bleh> adb shell mount /data
do any of these mount attempts fail? If not, repeat
Code:
C:\bleh> adb shell cat /proc/mounts
did any of them mount read-only (instead of rw as they should have)?
Now go and unmount them all
Code:
C:\bleh> adb shell umount /sdcard
C:\bleh> adb shell umount /data
C:\bleh> adb shell umount /system
C:\bleh> adb shell umount /data
Now go through each of these filesystems and check them manually with "e2fsck" (TWRP has this, I don't know about CWM). You will be checking the block devices mmcblk0p{3,4,{9|10}}.
NOTE:
Grouper /data partition -> mmcblk0p9
Tilapia /data partition -> mmcblk0p10
These checks do not alter anything (-n option):
Code:
C:\bleh> adb shell e2fsck -f -n /dev/block/mmcblk0p3
C:\bleh> adb shell e2fsck -f -n /dev/block/mmcblk0p4
C:\bleh> adb shell e2fsck -f -n /dev/block/mmcblk0p9 [b][color=red]( Grouper Only! )[/color][/b]
C:\bleh> adb shell e2fsck -f -n /dev/block/mmcblk0p10 [b][color=red]( Tilapia Only! )[/color][/b]
Any errors for any of these other than complaints about lost+found being missing?
All of the above are just sanity checks to see if the typical ext4 filesystems used by Android are being created correctly during the fastboot flashing operations you performed. This is not a solution; I will respond based on what you report.
You may also want to capture a kernel log of the soft-booted recovery, e.g.
Code:
C:\bleh> adb shell dmesg > soft-booted-recovery-kernel-log.txt
Post the above kernel log to pastebin or somewhere instead of putting it in this thread.
OK, your turn.

Here it is, log file attached.
>adb shell cat /proc/mounts
rootfs / rootfs rw 0 0
tmpfs /dev tmpfs rw,seclabel,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,seclabel,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,seclabel,relatime 0 0
selinuxfs /sys/fs/selinux selinuxfs rw,relatime 0 0
/dev/block/mmcblk0p4 /cache ext4 rw,seclabel,relatime,user_xattr,acl,barrier=1,d
ata=ordered 0 0
>adb shell mount /data
>adb shell cat /proc/mounts
rootfs / rootfs rw 0 0
tmpfs /dev tmpfs rw,seclabel,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,seclabel,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,seclabel,relatime 0 0
selinuxfs /sys/fs/selinux selinuxfs rw,relatime 0 0
/dev/block/mmcblk0p4 /cache ext4 rw,seclabel,relatime,user_xattr,acl,barrier=1,d
ata=ordered 0 0
/dev/block/mmcblk0p9 /data ext4 rw,seclabel,relatime,user_xattr,acl,barrier=1,da
ta=ordered 0 0
>adb shell umount /sdcard
umount: can't umount /sdcard: Invalid argument
>adb shell umount /data
>adb shell umount /system
umount: can't umount /system: Invalid argument
>adb shell e2fsck -f -n /dev/blo
ck/mmcblk0p9
e2fsck 1.41.14 (22-Dec-2010)
Warning: skipping journal recovery because doing a read-only filesystem check.
Pass 1: Checking inodes, blocks, and sizes
Inodes that were part of a corrupted orphan linked list found. Fix? no
Inode 213776 was part of the orphaned inode list. IGNORED.
Inode 214478 was part of the orphaned inode list. IGNORED.
Inode 245302 was part of the orphaned inode list. IGNORED.
Inode 245303 was part of the orphaned inode list. IGNORED.
Inode 245305 was part of the orphaned inode list. IGNORED.
Inode 245311 was part of the orphaned inode list. IGNORED.
Inode 245343 was part of the orphaned inode list. IGNORED.
Inode 245344 was part of the orphaned inode list. IGNORED.
Deleted inode 277997 has zero dtime. Fix? no
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: -852836 -(884198--884199) +1228639 +(1256263--1256268
) -(1285498--1285501) -(1285514--1285515) +(1285529--1285530) -1293833 -1293860
+(1293862--1293872) +(1293885--1293886) -1937108
Fix? no
Free blocks count wrong for group #10 (8976, counted=9160).
Fix? no
Free blocks count wrong for group #13 (2049, counted=3073).
Fix? no
Free blocks count wrong for group #35 (16707, counted=16481).
Fix? no
Free blocks count wrong for group #37 (6352, counted=6355).
Fix? no
Free blocks count wrong for group #38 (6105, counted=6119).
Fix? no
Free blocks count wrong for group #41 (7987, counted=9016).
Fix? no
Free blocks count wrong for group #61 (2838, counted=2814).
Fix? no
Free blocks count wrong (1129965, counted=1163188).
Fix? no
Inode bitmap differences: -213776 -214478 -(245302--245303) -245305 -245311 -(2
45343--245344) -277997
Fix? no
Free inodes count wrong for group #26 (5659, counted=5658).
Fix? no
Free inodes count wrong for group #61 (539, counted=536).
Fix? no
Free inodes count wrong (854105, counted=859572).
Fix? no
/dev/block/mmcblk0p9: ********** WARNING: Filesystem still has errors **********
/dev/block/mmcblk0p9: 28903/883008 files (3.6% non-contiguous), 2395923/3525888
blocks

samw52000 said:
Here it is, log file attached.
...
Click to expand...
Click to collapse
I'll look at your kernel log in a little bit, but here's what sticks out.
1) Your userdata filesystem (mmcblk0p9) is corrupted - mildly. That shouldn't happen (although when it is bad you get pages and pages and pages of error output).
2) Your cache filesystem was mounted rw, but that doesn't necessarily mean that it was clean. You never ran a "e2fsck" check on either mmcblk0p3 or mmcblk0p4 (system and cache, respectively). Either that or they were clean and you didn't show the output. Which was it?
You should run the e2fsck checks on those as well and report back.
The recommendation that I will make for flashing the factory image is as follows:
1) Skip the bootloader flashing if you already have the matching bootloader version installed
2) Using fastboot, erase and format all three partitions cache, system, userdata:
Code:
fastboot erase cache
fastboot erase system
fastboot erase userdata **
fastboot format cache
fastboot format system
fastboot format userdata
** note this destroys all your data (but it sounds like you have either backed up your device or have moved beyond caring about this). I don't believe there is any reason for doing a fastboot erase of the boot partition (although I suppose if the bootloader understands "TRIM" behaviors, it would be possible that a "fastboot erase boot" operation changes the availability of pages in that partition for use in the wear-leveling free pool during subsequent writing operations. In the interest of safety, I would never allow the 4 sequential letters "boot" to appear in a "fastboot erase" command - to avoid accidentally doing something horrific like "fastboot erase bootloader". Better to simply skip erasing of the boot partition ("fastboot erase boot") than to run the risk of making a typing error and accidentally nuke the bootloader. (I don't even understand why the unlocked bootloader should allow erasure of the bootloader partition.)
3) Repeat the steps in my previous posts to check that the filesystems are being created cleanly by the fastboot format operation:
(3a) Soft-boot into a custom recovery and
Code:
umount /cache
umount /system
umount /data
e2fsck -f -n /dev/block/mmcblk0p3 [color=grey]# (system)[/color]
e2fsck -f -n /dev/block/mmcblk0p4 [color=grey]# (cache)[/color]
e2fsck -f -n /dev/block/mmcblk0p9 [color=grey]# (userdata [b][color=red]Grouper Only![/color][/b])[/color]
e2fsck -f -n /dev/block/mmcblk0p10 [color=grey]# (userdata [b][color=red]Tilapia Only![/color][/b])[/color]
They should all be clean, other than a complaint about lost+found being missing.
4) Now, perform the flashing of the factory boot.img & system.img - NOTHING ELSE. The important point here is to NOT FLASH "userdata.img" from the factory image.
Code:
fastboot flash system system.img
fastboot flash boot boot.img
5) Repeat the steps in my previous posts to check that the /system filesystem is clean, e.g.
Code:
umount /system
e2fsck -f -n /dev/block/mmcblk0p3
.
If everything is clean, go ahead and try booting the tablet into the normal OS
[Edit] I looked through your (recovery) kernel boot log.
I didn't see anything terribly unusual, except some indications of EXT4 filesystem repair. That shouldn't be happening, but could have been caused by:
- a kernel crash or maybe bootlooping
- you hard-crashing the device by holding the power button down > 15 seconds.
The good news is that I don't see anything unusual happening where the kernel reads the device partitioning information
---------- Post added at 10:53 AM ---------- Previous post was at 10:25 AM ----------
PS
I the post above - after step 3a - you can manually check to be sure that everything has really been erased from those three partitions by mounting each of /cache, /data, and /system, and then running a "df" command. The usage should be pretty close to 0% for all 3 of them.
BTW, I was a little sloppy above about giving the recovery terminal commands without prefixing them with "adb shell". I assumed that you know that you can just
Code:
adb shell
... (linux commands)
exit
with the custom recovery (soft-)booted, and then you will be sort of "logged in" to the device. You can tell the difference because of the command prompt you get. "Logged in" to the android device's recovery, it will be a "#" character. If you are on the PC you'll have the DOS/cygwin prompt, .e.g "C:\some-path-or-other>". You might already know that, but I thought I should mention it.

Man I truly appreciate the help!!!
Ok so this is what I've done:
>adb shell umount /cache
>adb shell umount /system
umount: can't umount /system: Invalid argument
>adb shell umount /data
>adb shell e2fsck -f -n /dev/block/mmcblk0p3
e2fsck 1.41.14 (22-Dec-2010)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/block/mmcblk0p3: 1309/41664 files (2.1% non-contiguous), 158713/166400 blocks
>adb shell e2fsck -f -n /dev/block/mmcblk0p4
e2fsck 1.41.14 (22-Dec-2010)
Warning: skipping journal recovery because doing a read-only filesystem check.
Pass 1: Checking inodes, blocks, and sizes
Deleted inode 16 has zero dtime. Fix? no
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Inode bitmap differences: -16
Fix? no
Free inodes count wrong (28336, counted=28335).
Fix? no
/dev/block/mmcblk0p4: ********** WARNING: Filesystem still has errors **********
/dev/block/mmcblk0p4: 16/28352 files (0.0% non-contiguous), 3666/113408 blocks
>adb shell e2fsck -f -n /dev/block/mmcblk0p9
e2fsck 1.41.14 (22-Dec-2010)
e2fsck: Device or resource busy while trying to open /dev/block/mmcblk0p9
Filesystem mounted or opened exclusively by another program?
>fastboot erase cache
******** Did you mean to fastboot format this partition?
erasing 'cache'...
OKAY [ 0.016s]
finished. total time: 0.016s
>fastboot erase system
******** Did you mean to fastboot format this partition?
erasing 'system'...
OKAY [ 0.016s]
finished. total time: 0.016s
>fastboot erase userdata
******** Did you mean to fastboot format this partition?
erasing 'userdata'...
OKAY [ 0.031s]
finished. total time: 0.031s
>fastboot format cache
erasing 'cache'...
OKAY [ 0.031s]
formatting 'cache' partition...
Creating filesystem with parameters:
Size: 464519168
Block size: 4096
Blocks per group: 32768
Inodes per group: 7088
Inode size: 256
Journal blocks: 1772
Label:
Blocks: 113408
Block groups: 4
Reserved block group size: 31
Created filesystem with 11/28352 inodes and 3654/113408 blocks
sending 'cache' (9052 KB)...
writing 'cache'...
OKAY [ 1.625s]
finished. total time: 1.657s
>fastboot format system
erasing 'system'...
OKAY [ 0.031s]
formatting 'system' partition...
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
sending 'system' (12416 KB)...
writing 'system'...
OKAY [ 2.173s]
finished. total time: 2.204s
>fastboot format userdata
erasing 'userdata'...
OKAY [ 0.031s]
formatting 'userdata' partition...
Creating filesystem with parameters:
Size: 14442037248
Block size: 4096
Blocks per group: 32768
Inodes per group: 8176
Inode size: 256
Journal blocks: 32768
Label:
Blocks: 3525888
Block groups: 108
Reserved block group size: 863
Created filesystem with 11/883008 inodes and 96825/3525888 blocks
sending 'userdata' (137526 KB)...
writing 'userdata'...
OKAY [ 26.130s]
finished. total time: 26.161s
Then I ran this again:
>adb shell umount /cache
>adb shell umount /system
umount: can't umount /system: Invalid argument
>adb shell umount /data
>adb shell e2fsck -f -n /dev/block/mmcblk0p3
e2fsck 1.41.14 (22-Dec-2010)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/block/mmcblk0p3: 1309/41664 files (2.1% non-contiguous), 158713/166400 bloc
ks
>adb shell e2fsck -f -n /dev/block/mmcblk0p4
e2fsck 1.41.14 (22-Dec-2010)
Warning: skipping journal recovery because doing a read-only filesystem check.
Pass 1: Checking inodes, blocks, and sizes
Deleted inode 16 has zero dtime. Fix? no
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Inode bitmap differences: -16
Fix? no
Free inodes count wrong (28336, counted=28335).
Fix? no
/dev/block/mmcblk0p4: ********** WARNING: Filesystem still has errors **********
/dev/block/mmcblk0p4: 16/28352 files (0.0% non-contiguous), 3666/113408 blocks
>adb shell e2fsck -f -n /dev/block/mmcblk0p9
e2fsck 1.41.14 (22-Dec-2010)
e2fsck: Device or resource busy while trying to open /dev/block/mmcblk0p9
Filesystem mounted or opened exclusively by another program?
>fastboot flash system "c:\users\...\data\Factory_Images\nakasi-kot49h-factory-5e9db5e1\image-nakasi-kot49h\system.img"
erasing 'system'...
OKAY [ 0.016s]
sending 'system' (625382 KB)...
OKAY [ 75.438s]
writing 'system'...
OKAY [ 27.602s]
finished. total time: 103.055s
>fastboot boot "c:\users\...\data\Factory_Images\nakasi-kot49h-factory-5e9db5e1\image-nakasi-kot49h\boot.img"
downloading 'boot.img'...
OKAY [ 0.609s]
booting...
OKAY [ 0.031s]
finished. total time: 0.641s
Device automatically restarted here - same thing happened, my wallpaper was still up as if nothing had happened.
C:\Users\Sam Wagner\Desktop\Nexus 7 Toolkit\data>adb shell umount /system
umount: can't umount /system: Invalid argument
>adb shell e2fsck -f -n /dev/block/mmcblk0p3
e2fsck 1.41.14 (22-Dec-2010)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/block/mmcblk0p3: 1309/41664 files (2.1% non-contiguous), 158713/166400 blocks
Now the tablet will still boot to the lock screen and shows the wallpaper that's been set before... Sticks there for a few seconds then restarts.
I'm just not understanding why it would tell me that it's deleted stuff but isn't doing any of it.
Also like I mentioned before the stock recovery shows "no command" every time I tried to load into it - I've managed to get past this to the second where you can select the full factory wipe but as everything else it didn't wipe anything.

I guess I would like to see some unambiguous evidence that there really are still files present after erasing the partitions and doing the format (but before flashing the boot.img and system.img files).
That is
fastboot erase cache
fastboot erase system
fastboot erase userdata
fastboot format cache
fastboot format system
fastboot format user data
fastboot boot your-custom-recovery-image.img
(... custom recovery boot completes... )
adb shell mount /system
adb shell mount /data (will fail if already mounted)
adb shell mount /cache (will fail if already mounted )
(... and finally ...)
adb shell df /system /data /cache
or if you please you could do
adb shell ls -ld /data/*
adb shell ls -ld /system/*
adb shell ls -ld /cache/*
both /data and /system should be empty; /cache might have a few files from activity in the custom recovery.
Or at least that's the way it *should* behave.
PS The "no command" message displayed by the stock recovery is normal.

Tried that and it appears that the format commands do process but they don't appear to be deleting anything again.
>fastboot erase cache
******** Did you mean to fastboot format this partition?
erasing 'cache'...
OKAY [ 0.016s]
finished. total time: 0.016s
>fastboot erase system
******** Did you mean to fastboot format this partition?
erasing 'system'...
OKAY [ 0.016s]
finished. total time: 0.016s
>fastboot erase userdata
******** Did you mean to fastboot format this partition?
erasing 'userdata'...
OKAY [ 0.031s]
finished. total time: 0.031s
>fastboot erase cache
******** Did you mean to fastboot format this partition?
erasing 'cache'...
OKAY [ 0.016s]
finished. total time: 0.016s
>fastboot erase system
******** Did you mean to fastboot format this partition?
erasing 'system'...
OKAY [ -0.000s]
finished. total time: 0.016s
>adb shell mount /system
>adb shell mount /data
mount: mounting /dev/block/mmcblk0p9 on /data failed: Device or resource busy
>adb shell mount /cache
mount: mounting /dev/block/mmcblk0p4 on /cache failed: Device or resource busy
>adb shell df /system /data /cache
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/block/mmcblk0p3 655104 624356 30748 95% /system
/dev/block/mmcblk0p9 13881856 9229124 4652732 66% /data
/dev/block/mmcblk0p4 446488 7524 438964 2% /cache
When I ls the data partition I'm still seeing all the files and apps installed.
I'm not sure if there is a way to use the adb shell to format the partition (or maybe a recursive rm -f).
I'm also not entirely sure if it would actually do anything since it's not doing it in fastboot.
Like you mentioned at this point I'm not concerned about any of the data on the device as I do have backups. I just want to have it completely wiped and start from scratch.
Would having rooted the device at any point (and unlocked the bootloader) have anything to do with it?
I was running on Stock rooted for a while but then when my wife started to have problems with the device boot looping I ended up going back to stock (using the flash stock + unroot feature) and the "soft-bricked/bootloop" option).
I recall being able to side load 4.4.2 and everything seemed to work for a little while but it's doing the same thing now which makes me wonder if anything was actually fixed when I reloaded it last.
I did a complete wipe when I migrated to 4.4.0 which worked.

Same problem
Quite a few others have same "Read Only" problem I think.
I have tried everything. Seems to obey... but reverts to previous condition.
I reckon it is a hardware problem.
I've ordered a 2nd user motherboard for mine.
samw52000 said:
Tried that and it appears that the format commands do process but they don't appear to be deleting anything again.
>fastboot erase cache
******** Did you mean to fastboot format this partition?
erasing 'cache'...
OKAY [ 0.016s]
finished. total time: 0.016s
>fastboot erase system
******** Did you mean to fastboot format this partition?
erasing 'system'...
OKAY [ 0.016s]
finished. total time: 0.016s
>fastboot erase userdata
******** Did you mean to fastboot format this partition?
erasing 'userdata'...
OKAY [ 0.031s]
finished. total time: 0.031s
>fastboot erase cache
******** Did you mean to fastboot format this partition?
erasing 'cache'...
OKAY [ 0.016s]
finished. total time: 0.016s
>fastboot erase system
******** Did you mean to fastboot format this partition?
erasing 'system'...
OKAY [ -0.000s]
finished. total time: 0.016s
>adb shell mount /system
>adb shell mount /data
mount: mounting /dev/block/mmcblk0p9 on /data failed: Device or resource busy
>adb shell mount /cache
mount: mounting /dev/block/mmcblk0p4 on /cache failed: Device or resource busy
>adb shell df /system /data /cache
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/block/mmcblk0p3 655104 624356 30748 95% /system
/dev/block/mmcblk0p9 13881856 9229124 4652732 66% /data
/dev/block/mmcblk0p4 446488 7524 438964 2% /cache
When I ls the data partition I'm still seeing all the files and apps installed.
I'm not sure if there is a way to use the adb shell to format the partition (or maybe a recursive rm -f).
I'm also not entirely sure if it would actually do anything since it's not doing it in fastboot.
Like you mentioned at this point I'm not concerned about any of the data on the device as I do have backups. I just want to have it completely wiped and start from scratch.
Would having rooted the device at any point (and unlocked the bootloader) have anything to do with it?
I was running on Stock rooted for a while but then when my wife started to have problems with the device boot looping I ended up going back to stock (using the flash stock + unroot feature) and the "soft-bricked/bootloop" option).
I recall being able to side load 4.4.2 and everything seemed to work for a little while but it's doing the same thing now which makes me wonder if anything was actually fixed when I reloaded it last.
I did a complete wipe when I migrated to 4.4.0 which worked.
Click to expand...
Click to collapse

samw52000 said:
Tried that and it appears that the format commands do process but they don't appear to be deleting anything again.
>adb shell df /system /data /cache
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/block/mmcblk0p3 655104 624356 30748 95% /system
/dev/block/mmcblk0p9 13881856 9229124 4652732 66% /data
/dev/block/mmcblk0p4 446488 7524 438964 2% /cache
When I ls the data partition I'm still seeing all the files and apps installed.
Click to expand...
Click to collapse
Ugh. Well, you gave it a try. But that does seem to strongly implicate the hardware.
samw52000 said:
I'm not sure if there is a way to use the adb shell to format the partition (or maybe a recursive rm -f).
I'm also not entirely sure if it would actually do anything since it's not doing it in fastboot.
Click to expand...
Click to collapse
There is the utility mke2fs in the recovery. But yeah, If the bootloader can't write it seems highly unlikely that the linux kernel would be able to.
The only other moon-shot-odds thing I can think of (which is admittedly extremely far fetched) is that somehow the "persistent state" managed by the bootloader has some kind of read-only toggle in it (something like a software test mode?) that got flipped, and erasing all partitions in the device plus the bootloader before immediately re-flashing the bootloader** could change something. The worst case conclusion of this kind of activity would be a harder bricking, but it sounds like the hardware is written off already. More likely, the fastboot operations would act just the same (read-only but no errors thrown), and you would never really change *anything* on the tablet. (The only way to tell if it succeeded might be to flash a different bootloader version than the one presently on the tablet as it display's it's version number on the fastboot splash screen) As I said though, this is a pretty wild idea, and frankly the chances that the entire eMMC flash chip went read-only in totality is a far simpler explanation.
Sux that your wife's personal info is going to enter a wastestream of undetermined disposition. Puts someone with a legitimate warranty claim concerning hardware in the awkward position: "destroy the memory chip now and lose my warranty - or throw my personal information into the wind in order to claim my warranty?".
Sorry.
** I'm not recommending that anybody willy-nilly erases and reflash their bootloader; it is just too dangerous. It should be regarded as last-ditch move of desperation - which is where the OP is now. Perhaps the erasure of all partitions at once allows the eMMC chip to rotate flash pages out of (and thus other pages in the device into) the bootloader partition as part of device-wide wear leveling?
But because I brought it up, I should oblige myself to state the following safety measures when bootloader flashing is performed manually:
- phone/tablet battery is fully charged (& even better if the fastboot/adb PC is a laptop w/ a working battery)
- verify the length and MD5/SHA-1 signatures of all flashable image files before beginning
- make absolutely certain that no power loss or rebooting of the device will occur between the time the "fastboot erase bootloader " command and the "fastboot flash bootloader bootloader-image-file.img" commands are performed. (The most obvious way to insure this is to perform them back-to-back, the flash performed straight away after the erase).
- the behaviors of the new bootloader don't take effect until a hardware reset, so the moment of truth after flashing a new bootloader is the command:
fastboot reboot-bootloader
.

Has anyone ever successfully resolved this? I am having the exact same issue as the OP and have tried everything I can think of. It seems like the partitions and bootloader are somehow write-protected; preventing data from being wiped or new data flashed.
Help!
Sent from my iPhone using Tapatalk

I haven't yet... Pretty much wrote the device off but will try the last recommendation as a last try soon just not hoping for much!

still no luck... last ditch was to wipe the bootloader and reload. Same thing happens.
I tried to even let the device drain completely to see if this would somehow help clear the storage... i guess i would have to wait many years for that to really happen
o well, I ordered a 2013 16GB model... hopefully it won't be an issue with that one.
The old one will likely go up on ebay for parts (less the memory modules that I'll likely remove).

Generating singleimage.bin

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

unlocking Bootloader without erasing userdata?

Hello,
i have a Nexus 7 2013 edition.
I updated the device and something went really wrong.
I want to unlock the Bootloader to flash it, but it don't work, because everytime i try to unlock it, the tablet wants to erase userdata. This is were the Nexus stucks.
When i try to unlock the device, this happens:
Code:
C:\Program Files (x86)\Minimal ADB and Fastboot>fastboot oem unlock
...
(bootloader) Unlocking bootloader...
(bootloader) erasing userdata...
I tried to erase the partition without and with "-u" and "-w" but everything failed (i aborted because it went forever)
Code:
C:\Program Files (x86)\Minimal ADB and Fastboot>fastboot erase userdata
******** Did you mean to fastboot format this ext4 partition?
erasing 'userdata'...
FAILED (status read failed (Too many links))
finished. total time: 392.412s
C:\Program Files (x86)\Minimal ADB and Fastboot>fastboot erase userdata -u
******** Did you mean to fastboot format this ext4 partition?
erasing 'userdata'...
FAILED (status read failed (Too many links))
finished. total time: 187.879s
C:\Program Files (x86)\Minimal ADB and Fastboot>fastboot erase userdata -w
******** Did you mean to fastboot format this ext4 partition?
wiping userdata...
Creating filesystem with parameters:
Size: 28521246720
Block size: 4096
Blocks per group: 32768
Inodes per group: 8176
Inode size: 256
Journal blocks: 32768
Label:
Blocks: 6963195
Block groups: 213
Reserved block group size: 1024
Created filesystem with 11/1741488 inodes and 153337/6963195 blocks
target didn't report max-download-size
wiping cache...
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
erasing 'userdata'...
FAILED (status read failed (Too many links))
finished. total time: 203.907s
Can someone tell me how i can unlock the bootloader without erasing the userdata partition?
Or can i use another tool instead of adb+fastboot?
Can someone help me?

Code:
fastboot oem unlock
This will always erase userdata, there is nothing you can do about it.
You don't need to manually erase the userdata again afterwards.

akoppes said:
Code:
fastboot oem unlock
This will always erase userdata, there is nothing you can do about it.
You don't need to manually erase the userdata again afterwards.
Click to expand...
Click to collapse
Ok, but the userdata cannot be erased because everytime i try to unlock the bootloader the system crashes while erasing userdata.
Is there anything i can do to repair the device, because i'm out of options.

Google for Nexus 2013 stock images and download them from Google . As they are signed images you can flash them with fastboot. After flashing boot into android, then power down. Now you should be able to unlock the boot loader using fastboot oem unlock.
It seems the userdata partition is messed up, and the above procedure should be easiest to fix that.
Gesendet von iPad mit Tapatalk

Corrupt partition /data

Okay so I recently updated my s4(att) from cyanogen 12 to cyanogen 13 (latest nightly). I went to settings/security and chose encrypt phone. After about 30 minutes of encrypting it reboot and got stuck in a bootloop. I thought no problem Ill just reflash. I go to reflash my backup and it says error mounting /data. I try formating data, factory reset, and installing the rom from scratch. It seems my data partition corrupt. So I figure fastboot. Yet upon loading fastboot I cant get adb to see my device. I think I got the right drivers installed. But nothing. Any help would be greatly appreciated.
Edit: fixed.
Solution:
I found this and was able to shell in via adb and format the partition.
f you wish to wipe the /data partition completely (including media like photos), follow the below instructions:
Boot into recovery.
Run adb shell in a terminal (Linux) or Command Prompt ("CMD", Windows). After a few seconds, you should see a line containing ~ #.
WARNING. Triple-check the command that you are entering here. White space and capitalization are important. Make any mistake here and you may accidentally wipe your whole flash memory including recovery images.
NOTE: if you want to encrypt your partition later, you have to leave 16KiB unallocated space on the end of the partition.
In the adb shell, run the command mke2fs -t ext4 /dev/block/mmcblk0p12. Substitute /dev/block/mmcblk0p12 and ext4 according to the recovery filesystem table (for /data). Output when running the command:
~ # mke2fs -t ext4 /dev/block/mmcblk0p12
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
755904 inodes, 3022848 blocks
151142 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=3095396352
93 block groups
32768 blocks per group, 32768 fragments per group
8128 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 34 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
(Optional) Install new firmware (E.g. CM 10.1).
Reboot.
(Optional) In order to encrypt the partition while clearing your whole data partition, run vdc cryptfs enablecrypto wipe PIN_OR_PASSWORD (before Android 5.0) or vdc cryptfs enablecrypto wipe password PASSWORD_IN_HEX (since Android 5.0, see this post for details).
Reconfigure device, choose language, enter name, install apps, etc.
source: android .stackexchange. com/questions/33398/cannot-factory-reset-after-encrypting
(sorry cant post links yet)
of course always check your formatting the correct partition first

[GUIDE] UnBrick your OnePlus X on a Linux machine

DISCLAIMER: This guide describes procedures with tools that are designed to write directly to the storage of your device. This has the potential to lead to data loss or bricking your device. If you follow this guide carefully, none of these things should happen. That being said, you are still responsible for your own actions and how you handle the tools mentioned in this guide. Caution is advised.
When do i need this?The following procedure can be used to get your device back into a booting state if all else fails. Usually you'd want to use this tool to get a working recovery running on your device and then go from there. If your bootloader is locked you can use this tool to flash the stock recovery again and unlock the bootloader as ususal.
If that is not sufficient, you can also reflash all of firmware, bootloader and stock recovery.
This guide is not needed if:- The device still boots into stock recovery or TWRP
Flashing the official OxygenOS can fix many issues and you can unlock your bootloader as needed.
- The bootloader is unlocked. Use fastboot flash recovery <twrp image>
Check it with fastboot oem device-info
Use TWRP v3.0.2-0 with the OxygenOS 2 bootloader and the latest TWRP with the OxygenOS 3 bootloader.
- The ROM still boots and is rooted. Flash a stock recovery in a root shell:
adb root && adb shell
dd of=/dev/block/platform/msm_sdcc.1/by-name/recovery if=/sdcard/OxygenOS_recovery.img
OxygenOS 2 Lollipop recovery - OxygenOS 3 Marshmallow recovery
On custom ROMs, you can usually enable root access for ADB in developer settings, even if you didn't root them youself.
If any link is dead, search for it on https://web.archive.org
Spoiler: Verify downloaded files
The OxygenOS recovery links download from OnePlus's official amazon cloud storage. To verify, compare with the OxygenOS download link from the official page. OnePlus no longer links to these files and provides no checksums, you can use these to verify your download:
Code:
de38f20e72da38d48899f14d022cc1b1cd6bff0f4a506adb7bcf0153e73b1934 OPX_recovery.img
2810feb0d87686ea0529d8718600fdf3181cf0c93f0b9e29e5f13004af0e2d84 OPX_MM_recovery.img
e2fb0f0fef7d644cf3e6c1c0699381074fd4a83f64be319b75b9942443a95c90 OnePlusXOxygen_14_OTA_019_all_201611071506_03f73e21449d4d31.zip
fd58d703cf677dc5148ab5dd0f4af6c3df13faeb51166719e17aa192a86a6c0a OPX_UnBrick_Mini_By_Naman_Bhalla.zip
Don't continue unless you actually checked if your bootloader is still unlocked. Sometime it is re-locked on accident if some things go wrong.
Recovery and ROM only boot with a compatible bootloader. If you're not sure, try one then the other.
There are two major versions of the OnePlus X bootloader, one from OxygenOS 2 (Lollipop) and one from OxygenOS 3 (Marshmallow), released ca. September 2016, all newer ROMs should be compatible.
Trying to boot into a ROM or recovery that is incompatible with the installed bootloader will get you stuck on the bootlogo screen. On the OxygenOS 2 bootloader the "Powered by Android" part will disappear.
A locked OxygenOS 2 bootloader will boot any compatible software.
A locked OxygenOS 3 bootloader will only boot software signed by OnePlus. When trying to boot an unsigned ROM or recovery the device will vibrate, splash the bootlogo for a second and reboot, resulting in an endless loop.
If all else fails: Flashing through EDL
You may know the legendary Mega Unbrick Guide for A Hard Bricked OnePlus X by Naman Bhalla but it only works on Windows.
It uses EDL, a hidden Qualcomm interface that allows direct read/write access to the devices flash storage to restore firmware, bootloader and stock recovery.
EDL is a powerful tool. A device in EDL mode will follow all instructions given to it without checking whether it would be a good idea to do so. If the instructions tell your device to overwrite userdata, IMEI or MAC address it will do so. Only flash files that are meant for your device. Don't edit any file unless you know what it does.
Preparation:You need to be at least somewhat familiar with the command line to do this.
- Install git from your distribution
- Download and compile the open source flashing tool QDL. Follow the section "Get the Linux flashing tool" from these instructions.
- Temporarily add QDL to your $PATH with export PATH="$(pwd):$PATH"
QDL must be able to communicate with your device. You can install the appropriate udev rules right now or try it without them first.
- Open a text editor sudo nano /etc/udev/rules.d/51-edl.rules
- Copy these rules and paste them. Ctrl+S to save, Ctrl+X to exit
- The rules should apply the next time you connect your device
- If flashing does not work check the file contents: cat /etc/udev/rules.d/51-edl.rules
- If you can't read the file: sudo chmod a+r /etc/udev/rules.d/51-edl.rules
- If the new rules still don't load for some reason: sudo udevadm control --reload
- Download the "UnBrick tool mini" as uploaded by Naman Bhalla. (direct link)
- Create a clean working directory and extract the zip file.
Customize what to flash:By default, the UnBrick tool mini will flash OxygenOS 2 bootloader, firmware and stock recovery. From there you can flash the latest OxygenOS and unlock your bootloader again for a clean start.
Flashing OxygenOS will always install a compatible bootloader and firmware and OxygenOS will automatically upgrade the recovery during the boot process.
If this is what you want just skip to the next step.
The UnBrick tool will flash config.bin and persist.img and reset these partitions.
Resetting config will re-lock the bootloader.
Resetting persist will require it to be repopulated again. OxygenOS can do this but most Custom ROMs will have broken sensors.
If you don't want to flash certain files, rename them or move them to another directory.
If you only want to flash certain partitions like the recovery, create a new directory, e.g. flash_recovery-only. Download the recovery version you need:
OxygenOS 2 Lollipop recovery - OxygenOS 3 Marshmallow recovery
Copy it to the new directory and rename it to recovery.img to match the filename the UnBrick tool uses.
Additionaly, copy these files from the UnBrick tool:
gpt_main0.bin
gpt_backup0.bin
patch0.xml
prog_emmc_firehose_8974.mbn
rawprogram0.xml
Main procedure:
cd to the directory with the files from the UnBrick tool. Go to your custom directory if you created one in the previous step.
Run qdl prog_emmc_firehose_8974.mbn rawprogram0.xml patch0.xml
QDL will wait for your device to connect.
If QDL asks for permissions go back to "Preparation" and install the udev rules.
With the OnePlus X powered off hold VolUp and connect it to the PC. Otherwise, connect it to the PC first and hold Power+VolUp until it connects in EDL mode.
To verify the connection you can check lsusb or sudo dmesg -w
Devices in EDL mode show up with idVendor=05c6 and idProduct=9008, usually as Product: QHSUSB__BULK
lsusb example: ID 05c6:9008 Qualcomm, Inc. Gobi Wireless Modem (QDL mode)
To filter the output: lsusb -d 05c6:9008
QDL should print several lines of output, reporting what is flashed etc.
Once it's done, QDL will kick your device out of EDL mode. If everything is alright your phone should vibrate and boot to the charging screen. You should be able to boot to recovery now.
Congratulations on unbricking your device on a Linux machine, enjoy.
Changelog:
2019-12-12 - Original post
??? - undocumented edits
2020-05-24 - Fix possible execution of QDL without patch0.xml which would break the partition table
2022-09-05 - Fix unnessesarily confusing instructions

Thanks

I have a new TWRP on my OPX, but I don't really know what to change in the rawprogram0.xml file.

emilianoheyns said:
I have a new TWRP on my OPX, but I don't really know what to change in the rawprogram0.xml file.
Click to expand...
Click to collapse
I'm not sure if i correctly understood your situation so i am going to assume the folloing:
- You are running a Linux based operating system on your desktop computer
- You have downloaded all necessary files as mentioned in the guide and successfully compiled qdl
- You want to use modern (newer than 2016) ROMs and the current OnePlus firmware and bootloader, i.e. from OxygenOS 3.1.4
- On your OnePlus X, you have "the old bootloader" installed, that is firmware prior to OxygenOS 3 (based on Marshmallow), i.e. firmware from OxygenOS 2.2.1 or similar
- Additionally, you accidentaly flashed TWRP version 3.0.2-1 or newer to your OnePlus X and rebooted into a soft-bricked state
If these assumptions are correct, i suggest as the easiest solution to reflash a compatible TWRP and update your firmware using that version of TWRP. If you can use your recovery, it is almost always the easiest method to make any remaining modifications in the recovery.
The procedure is as follows:
- From https://dl.twrp.me/onyx/, download TWRP version 3.0.2-0 and 3.3.1-0
- Reflash an old version of TWRP that is compatible, i.e. anything version 3.0.2-0 and below.
Once you flashed TWRP in one way or another, continue with the following steps to update your bootloader:
- Reboot to that version of TWRP to see if you succeeded
- In TWRP, install either one of the following to update your firmware:
- The official OxygenOS 3.1.4 zip downloaded from OnePlus via https://www.oneplus.com/support/softwareupgrade- Only the firmware by following this guide: https://forum.xda-developers.com/oneplus-x/general/guide-update-bootloader-firmware-to-t347891766- Copy to your device: twrp-3.3.1-0-onyx.img and the installation zip you chose in the previous step
- Flash the zip in TWRP. Once TWRP is done flashing, immediately flash a version of TWRP 3.0.2-1 or later to recovery
- In TWRP, choose Reboot > Recovery. If your OnePlus X reboots to TWRP, everything went good and you can go on to flash roms and anything else like you're used to. Just note that very old ROMs (like from 2016 and before) will no longer boot on your device, but you can revert your Firmware by flashing the follwing zip: https://forum.xda-developers.com/oneplus-x/general/zip-recovery-flashable-firmware-radio-t3381420
Just remember that immediately after flashing this zip in TWRP, you have to flash TWRP version 3.0.2-0 or older again.
Now, there are some differnt cases that affect how TWRP initially needs to be flashed:
1. Your OnePlus X bootloader is not locked
(tested by running "fastboot oem device-info" on your desktop while your phone is connected in fastboot mode)
If your bootloader is still unlocked you can avoid the hassle of using qdl and simply resort to "fastboot flash recovery <recovery image file>" to fix your device.
2. Your ROM still boots and that ROM is rooted.
In this situation you can still avoid going through the hassle of using qdl.
All you need to do is to get a root shell running. There are several ways to achieve this:
- In a Terminal Emulator on the device run the command "su"
- On a desktop with your phone connected with adb enabled:
- Run either "adb root" and then "adb shell"
- Or run "adb shell" and within that shell, run "su"
Once you got the shell running you can flash your recovery with
"dd of=/dev/block/bootdevice/by-name/recovery if=/sdcard/twrp-3.0.2-0-onyx.img"
To get the image to your device if downloaded on your desktop you can use "adb push twrp-3.0.2-0-onyx.img /sdcard/"
3. Your ROM does not boot or is not rooted.
This is the case where you absolutely need qdl and the situation i assume you are in.
Once you downloaded and unpacked the package from Naman Bhalla, you should see a directory containing the rawprogram0.xml and prog_emmc_firehose_8974.mbn files and a lot of others. You can take just the rawprogram0.xml and the prog_emmc_firehose_8974.mbn file and copy them to your working directory for the next steps.
Now, open rawprogram0.xml in a text editor. Search for the string "recovery". You will see a line starting with "<program" and ending in "/>". In your case, only the line containing " label="recovery" " and " filename="recovery.img" " is relevant. Remove all other lines starting with "<program" and save. Optionally, rename the file to "program-onyx-recovery.xml" or something you will recognize. This might be useful if you plan to keep the file and use it again in the future.
Now, optionally change filename="recovery.img" to the file name of your TWRP file or just rename your downloaded TWRP file to "recovery.img".
To flash, make sure that the following files are in your working directory:
- prog_emmc_firehose_8974.mbn
- rawprogram0.xml (but your customized version)
- recovery.img (whatever recovery you want to flash)
If that is settled, run qdl as explained in my initial guide in the original post to flash the recovery file.
Edit 2022-09-04: This whole paragraph only applies to the OxygenOS 2 bootloader. A locked OxygenOS 3 bootloader will only boot a signed ROM or a signed recovery. However, the device storage can always be dumped through EDL and the final point about encryption always applies.
Some final remarks on locked bootloader on the OnePlus X:
For the future, remember to just keep your bootloader unlocked. It can save you a lot of hassle.
And if you feel uncomfortable about walking around with an unlocked bootloader:
Re-locking the bootloader while TWRP is installed doesn't give any security benefit at all (for obvious reasons). Even if your Recevery would not be open to any local attacker, a locked bootloader doesn't give you much of a benefit on the OnePlus X.
Yes, the generic attac surface of simply using "fastboot flash" is gone, but remember how easy it is to find the UnBrick tool for the OnePlus X we used in this guide. Any attacker can use it as well to flash a malicious recovery onto your device, even if your bootloader is locked - and your OnePlus will boot it.
This is because the OnePlus X does not support Android Verified Boot. This is a security feature on newer Android devices that prevents booting unsigned software if the bootloader is locked. This can prevent flashing malicious firmware, OS or revovery onto a device. But since it also prevents booting TWRP you'd likely be walking around with an unlocked bootloader anyway even if your device were to support this security feature.
Funnily enough, this leads to the conclusion that running your OnePlus X with stock OxygenOS, Recovery and locked bootloader is about as insecure as running TWRP and having an unlocked bootloader if we are talking about an attacker with physical access to the device who also knows about this tool. And since such a tool exists for pretty much every android device as it is originally used to flash these devices in their factories and can be publicly found for most devices, it can be assumed that any attacker has access to this tool.
So remember, the only protection you can have on a OnePlus X is encrypting your data with a strong passcode and hoping that your data stays private even if you might lose your device.

I have no problems with having an unlocked bootloader -- I thought this device had one already. Yesterday it was running TWRP3.0.2-1 and LOS Marshmellow, I just screwed it up trying to upgrade it to an unofficial LOS16. It would first bootloop constantly, then I tried QDL, and now it doesn't even seem to turn on; I can hold the power button for a full minute but the screen remains black, and there's no vibration as I'm used to. It does show up in QDL mode; I tried the procedure as per point 3, using twrp-3.0.2-1 as the recovery image. QDL says:
Code:
HELLO version: 0x2 compatible: 0x1 max_len: 1024 mode: 0
READ image: 13 offset: 0x0 length: 0x50
READ image: 13 offset: 0x50 length: 0x1000
READ image: 13 offset: 0x1050 length: 0x1000
READ image: 13 offset: 0x2050 length: 0x1000
READ image: 13 offset: 0x3050 length: 0x1000
READ image: 13 offset: 0x4050 length: 0x1000
READ image: 13 offset: 0x5050 length: 0x1000
READ image: 13 offset: 0x6050 length: 0x1000
READ image: 13 offset: 0x7050 length: 0x1000
READ image: 13 offset: 0x8050 length: 0x1000
READ image: 13 offset: 0x9050 length: 0x1000
READ image: 13 offset: 0xa050 length: 0x1000
READ image: 13 offset: 0xb050 length: 0x1000
READ image: 13 offset: 0xc050 length: 0x1000
READ image: 13 offset: 0xd050 length: 0x1000
READ image: 13 offset: 0xe050 length: 0x1000
READ image: 13 offset: 0xf050 length: 0x1000
READ image: 13 offset: 0x10050 length: 0x1000
READ image: 13 offset: 0x11050 length: 0x1000
READ image: 13 offset: 0x12050 length: 0x1000
READ image: 13 offset: 0x13050 length: 0x1000
READ image: 13 offset: 0x14050 length: 0x890
END OF IMAGE image: 13 status: 0
DONE status: 0
qdl: failed to read: Connection timed out
LOG: Host's payload to target size is too large
LOG: [email protected] [email protected]
LOG: [email protected] [email protected]
LOG: [email protected] [email protected]
LOG: start 1409024, num 31680
LOG: Finished sector address 1440704
[PROGRAM] flashed "recovery" successfully at 3960kB/s
no boot partition found
but the OPX still won't boot.

Is your bootloader actually unlocked?
The OnePlus X ships with a locked bootloader that prevents flashing files to the device using fastboot.
The usual steps to modify the OnePlus X and installing custom ROMs are:
- Unlock the bootloader by running "fastboot oem unlock" on a desktop PC while the phone is connected in fastboot mode.
- Flash TWRP by running "fastboot flash recovery TWRP.img" on a desktop PC while the phone is connected in fastboot mode.
Pressing the volume up button while turning on the device normally puts it into fastboot mode and "Fasboot Mode" will be displayed in the middle of the screen along with the oneplus logo.
Unlocking only works with the original OnePlus recovery and if the option "Allow OEM unlocking" is checked in the developer settings. Unlocking requires wiping all userdata.
Did you never do this yourself with your OnePlus X? Did you get this device as a used phone from someone else who already unlocked the bootloader?
What do you mean by "bootloop constantly"? Could you not boot the recovery?
Are you saying you already ran QDL with the unmodified files from the UnBrick tool?
If you really had TWRP 3.0.2-1 running before all your problems started, then doing so initially soft-bricked your device to begin with, as i outlined in footnote [1] of my original post.
I am not sure of the precise timeline and order of your descriptions. I currently assume that you're saying:
1. Had a working device with ROM: "LineageOS 13.0" Recovery: "TWRP version 3.0.2-1" Firmware: Unknown
2. Flashed some "lineage-16.0-unofficial.zip" in TWRP
3. When rebooting, "bootloops" appeared [How did that look? What was affected - just ROM or recovery as well?]
4. Run QDL with the unmodified files from the UnBrick tool that is linked in my original post
5. Phone does not react to button presses except when putting into EDL mode
6. Run QDL with recovery only as described in Point 3 of my follow up post, with the image file of TWRP version 3.0.2-1, QDL repoted success
7. Still not booting [What exactly does this mean? Still no reaction to button presses? Dees the phone vibrate and bring up the OnePlus logo?]

I've followed the mentioned steps and Im still stuck on linux logo..
I desesperately need help, bought a bricked second hand Oneplus X which I know nothing of in terms of past actions but previous owner

BolitaBolita said:
I've followed the mentioned steps and Im still stuck on linux logo..
I desesperately need help, bought a bricked second hand Oneplus X which I know nothing of in terms of past actions but previous owner
Click to expand...
Click to collapse
If you did not modify any files from the unbrick tool by Naman Bhalla and qdl ran through sucessfully, it should have flashed a compatible combination of bootloader and stock recovery so you should be able to reboot to that one.
If this is not the case, you can also go with flashing just a TWRP image. Since there are really just two possible versions of the bootloader (at least in regards to booting compatibility) this should succeed after the second try at most. If not, it means that some other stuff might be broken as well.
As i wrote in my OP, for the OnePlus X any TWRP v3.0.2-0 or older is compatible with the "old bootloader" (Lollipop) and any TWRP v3.0.2-1 or newer is compatible with the "new bootloader" (Marshmallow).
What you basically want to achieve is to just get any recovery booting (be it Stock, TWRP, orangefox or any other useful recovery). From that point, it is fairly easy to get anywhere else on the OnePlus X.
As for other things that can break:
Most of the partitions in your device can be restored to an intact state by flashing an official OxygenOS zip (https://www.oneplus.com/support/softwareupgrade). There are some other ways but this is the safe and easy method.
Only a few partitions cannot be restored once tampered, since they are unique to the specific device. If this happens to be the case, then it can be fairly hard to fix. If the previous owner had unlocked the devices bootloader and flashed some stuff on it, you should ask them whether they might have some TWRP backups around, namely of the partitions "Persist" and "EFS".

SebiderSushi said:
If you did not modify any files from the unbrick tool by Naman Bhalla and qdl ran through sucessfully, it should have flashed a compatible combination of bootloader and stock recovery so you should be able to reboot to that one.
If this is not the case, you can also go with flashing just a TWRP image. Since there are really just two possible versions of the bootloader (at least in regards to booting compatibility) this should succeed after the second try at most. If not, it means that some other stuff might be broken as well.
As i wrote in my OP, for the OnePlus X any TWRP v3.0.2-0 or older is compatible with the "old bootloader" (Lollipop) and any TWRP v3.0.2-1 or newer is compatible with the "new bootloader" (Marshmallow).
What you basically want to achieve is to just get any recovery booting (be it Stock, TWRP, orangefox or any other useful recovery). From that point, it is fairly easy to get anywhere else on the OnePlus X.
As for other things that can break:
Most of the partitions in your device can be restored to an intact state by flashing an official OxygenOS zip (https://www.oneplus.com/support/softwareupgrade). There are some other ways but this is the safe and easy method.
Only a few partitions cannot be restored once tampered, since they are unique to the specific device. If this happens to be the case, then it can be fairly hard to fix. If the previous owner had unlocked the devices bootloader and flashed some stuff on it, you should ask them whether they might have some TWRP backups around, namely of the partitions "Persist" and "EFS".
Click to expand...
Click to collapse
Thank you for your reply SebiderSushi.
The only option I have in terms of recovery booting is the Oneplus original one since I bought the phone bricked (can't access dev options and can't connect through ADB for oem unlock).
I've managed to unlock the bootloader and tried to flash the official OsOxygen zip. The update stopped halfway and the phone bricked once again.
I've tried the Naman Bhalla unbrick tool with the MSMdownloadtool 2.1 (previously attempted 2.0). The process runs successfully, until its marked in green 'download complete'. Phone still bricked.
I'm currently attempting with QFIL through this thread https://www.droidsavvy.com/unbrick-qualcomm-mobiles/
Drivers correctly installed, port 9008 is detected and QFIL is currently. I'm using the files from the unbrick tool by Naman Bhalla for this. The output is the following:
Process Index:0
Programmer Path:C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\prog_emmc_firehose_8974.mbn
Image Search Path:C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla
Please select the XML file
Start Download
Program Path:C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\prog_emmc_firehose_8974.mbn
COM Port number:3
Sahara Connecting ...
Sahara Version:0
Start Sending Programmer
Download Fail:System.Exception: Unable to download Flash Programmer using Sahara Protocol
at QC.QMSLPhone.Phone.QPHONEMS_SaharaArmPrgDownload(String sFileName)
at QC.SwDownloadDLL.SwDownload.QPHONEMSSaharaDownloadArmPrg(UInt64& version, String armPrgPath)
Download Fail:Sahara FailSahara Fail
Finish Download
Start Download
Program Path:C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\prog_emmc_firehose_8974.mbn
COM Port number:3
Sahara Connecting ...
Sahara Version:0
Start Sending Programmer
Download Fail:System.Exception: Unable to download Flash Programmer using Sahara Protocol
at QC.QMSLPhone.Phone.QPHONEMS_SaharaArmPrgDownload(String sFileName)
at QC.SwDownloadDLL.SwDownload.QPHONEMSSaharaDownloadArmPrg(UInt64& version, String armPrgPath)
Download Fail:Sahara FailSahara Fail
Finish Download
Start Download
Program Path:C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\prog_emmc_firehose_8974.mbn
COM Port number:3
Sahara Connecting ...
Sahara Version:0
Start Sending Programmer
Download Fail:System.Exception: Unable to download Flash Programmer using Sahara Protocol
at QC.QMSLPhone.Phone.QPHONEMS_SaharaArmPrgDownload(String sFileName)
at QC.SwDownloadDLL.SwDownload.QPHONEMSSaharaDownloadArmPrg(UInt64& version, String armPrgPath)
Download Fail:Sahara FailSahara Fail
Finish Download
Start Download
Program Path:C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\prog_emmc_firehose_8974.mbn
COM Port number:3
Sahara Connecting ...
Sahara Version:0
Start Sending Programmer
Download Fail:System.Exception: Unable to download Flash Programmer using Sahara Protocol
at QC.QMSLPhone.Phone.QPHONEMS_SaharaArmPrgDownload(String sFileName)
at QC.SwDownloadDLL.SwDownload.QPHONEMSSaharaDownloadArmPrg(UInt64& version, String armPrgPath)
Download Fail:Sahara FailSahara Fail
Finish Download
Start Download
Program Path:C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\prog_emmc_firehose_8974.mbn
COM Port number:3
Sahara Connecting ...
Sahara Version:2
Start Sending Programmer
Sending Programmer Finished
Switch To FireHose
Max Payload Size to Target:49152 Bytes
Device Type:eMMC
Platform:8x26
Disable Ack Raw Data Every N Packets
Ack Raw Data:False
Skip Write:False
Always Validate:False
Use Verbose:False
COM Port number:3
Sending NOP
FireHose NOP sent successfully
Sending Configuration
Device Type:eMMC
Platform:8x26
Request payload size 0xc000 is not the same as support payload size, change to 0x20000
Set TxBuffer 0x20000, RxBuffer 0x4000
Firehose configure packet sent successfully!
Total Bytes To Program 0x62AE4A0
Download Image
PROGRAM: Partition 0, Sector: 0, Length: 33 Sectors, Sector Size: 512 Bytes
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\gpt_backup0.bin
PROGRAM: Written Bytes 0x4200 (64)
Program Size: 0.02 MB
PROGRAM: Partition 0, Sector: 0, Length: 34 Sectors, Sector Size: 512 Bytes
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\gpt_main0.bin
PROGRAM: Written Bytes 0x4400 (64)
Program Size: 0.02 MB
PROGRAM: Partition 0, Sector: 1609554, Length: 1024 Sectors, Sector Size: 512 Bytes
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\config.bin
PROGRAM: Written Bytes 0x80000 (64)
Program Size: 0.50 MB
PROGRAM: Replace the partition sectors number 0x8000 to file size in sector 0x254
PROGRAM: Partition 0, Sector: 1460242, Length: 596 Sectors, Sector Size: 512 Bytes
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\logo.bin
PROGRAM: Written Bytes 0x4a800 (64)
Program Size: 0.29 MB
PROGRAM: Replace the partition sectors number 0x8000 to file size in sector 0x74f0
PROGRAM: Partition 0, Sector: 1409024, Length: 29936 Sectors, Sector Size: 512 Bytes
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\recovery.img
PROGRAM: Written Bytes 0xe9e000 (64)
Program Size: 14.62 MB
PROGRAM: Replace the partition sectors number 0x10000 to file size in sector 0x26a3
PROGRAM: Partition 0, Sector: 294912, Length: 9891 Sectors, Sector Size: 512 Bytes
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\persist.img
PROGRAM: Written Bytes 0x4d4600 (64)
Program Size: 4.83 MB
PROGRAM: Partition 0, Sector: 259048, Length: 20480 Sectors, Sector Size: 512 Bytes
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\static_nvbk.bin
PROGRAM: Written Bytes 0xa00000 (64)
Program Size: 10.00 MB
PROGRAM: Partition 0, Sector: 238568, Length: 20480 Sectors, Sector Size: 512 Bytes
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\dynamic_nvbk.bin
PROGRAM: Written Bytes 0xa00000 (64)
Program Size: 10.00 MB
PROGRAM: Replace the partition sectors number 0x3e8 to file size in sector 0x28d
PROGRAM: Partition 0, Sector: 229376, Length: 653 Sectors, Sector Size: 512 Bytes
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\tz.mbn
PROGRAM: Written Bytes 0x51a00 (64)
Program Size: 0.32 MB
PROGRAM: Replace the partition sectors number 0x3e8 to file size in sector 0x174
PROGRAM: Partition 0, Sector: 182272, Length: 372 Sectors, Sector Size: 512 Bytes
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\rpm.mbn
PROGRAM: Written Bytes 0x2e800 (64)
Program Size: 0.18 MB
PROGRAM: Replace the partition sectors number 0x800 to file size in sector 0x380
PROGRAM: Partition 0, Sector: 180224, Length: 896 Sectors, Sector Size: 512 Bytes
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\emmc_appsboot.mbn
PROGRAM: Written Bytes 0x70000 (64)
Program Size: 0.44 MB
PROGRAM: Replace the partition sectors number 0x40 to file size in sector 0x17
PROGRAM: Partition 0, Sector: 148480, Length: 23 Sectors, Sector Size: 512 Bytes
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\sdi.mbn
PROGRAM: Written Bytes 0x2e00 (64)
Program Size: 0.01 MB
PROGRAM: Replace the partition sectors number 0x400 to file size in sector 0x22d
PROGRAM: Partition 0, Sector: 147456, Length: 557 Sectors, Sector Size: 512 Bytes
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\sbl1.mbn
PROGRAM: Written Bytes 0x45a00 (64)
Program Size: 0.27 MB
PROGRAM: Replace the partition sectors number 0x20000 to file size in sector 0x1c983
PROGRAM: Partition 0, Sector: 16384, Length: 117123 Sectors, Sector Size: 512 Bytes
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\NON-HLOS.bin
PROGRAM: Written Bytes 0x3930600 (64)
Program Size: 57.19 MB
Total Size: 98.68 MB
Total Size: 28 Seconds
Throughput: 3.52 MB/Seconds
PATCH: Partition 0, Sector: 9, Offset 40 Bytes, Size: 8 Bytes, Value: NUM_DISK_SECTORS-34.
PATCH: Partition 0, Sector: 0, Offset 40 Bytes, Size: 8 Bytes, Value: NUM_DISK_SECTORS-34.
PATCH: Partition 0, Sector: 1, Offset 48 Bytes, Size: 8 Bytes, Value: NUM_DISK_SECTORS-34.
PATCH: Partition 0, Sector: 0, Offset 48 Bytes, Size: 8 Bytes, Value: NUM_DISK_SECTORS-34.
PATCH: Partition 0, Sector: 1, Offset 32 Bytes, Size: 8 Bytes, Value: NUM_DISK_SECTORS-1.
PATCH: Partition 0, Sector: 0, Offset 24 Bytes, Size: 8 Bytes, Value: NUM_DISK_SECTORS-1.
PATCH: Partition 0, Sector: 0, Offset 72 Bytes, Size: 8 Bytes, Value: NUM_DISK_SECTORS-33.
PATCH: Partition 0, Sector: 1, Offset 88 Bytes, Size: 4 Bytes, Value: CRC32(2,4096)
PATCH: Partition 0, Sector: 0, Offset 88 Bytes, Size: 4 Bytes, Value: CRC32(NUM_DISK_SECTORS-33.,4096)
PATCH: Partition 0, Sector: 1, Offset 16 Bytes, Size: 4 Bytes, Value: 0
PATCH: Partition 0, Sector: 1, Offset 16 Bytes, Size: 4 Bytes, Value: CRC32(1,92)
PATCH: Partition 0, Sector: 0, Offset 16 Bytes, Size: 4 Bytes, Value: 0
PATCH: Partition 0, Sector: 0, Offset 16 Bytes, Size: 4 Bytes, Value: CRC32(NUM_DISK_SECTORS-1.,92)
Total download file size: 98.68066MB
Throughput: 3.524309M/s
Reset Phone
Waiting for reset done...
Download Fail:FireHose Fail Fail to find QDLoader port after switch
Finish Download

BolitaBolita said:
The only option I have in terms of recovery booting is the Oneplus original one since I bought the phone bricked (can't access dev options and can't connect through ADB for oem unlock).
Click to expand...
Click to collapse
Now what exactly do you even mean when you say "Bricked"?
If you can boot into recovery, then your device is usually not bricked, but even if, it is usually not in a state where using a flashing tool and risking to **** up the device for good has any real advantage over solving whatever problem in the recovery.
As long as your device doesn't have any hardware errors (broken storage) then the official OnePlus Recovery should almost always be able to install the official OxygenOS.
Under what terms did you even buy this device? How did the previous owner describe the state of the device and its defects if they mentioned them?
BolitaBolita said:
File: C:\Users\simao\Desktop\AAA\OPX_UnBrick_Mini_By_Naman_Bhalla\config.bin
Click to expand...
Click to collapse
You are using windows, so how did you even end up in this thread?

Sorry for the delay -- I thought I had set up notifications and didn't want to push on the point until you had time, but I did not receive a notification for this.
SebiderSushi said:
Is your bootloader actually unlocked?
The OnePlus X ships with a locked bootloader that prevents flashing files to the device using fastboot.
The usual steps to modify the OnePlus X and installing custom ROMs are:
- Unlock the bootloader by running "fastboot oem unlock" on a desktop PC while the phone is connected in fastboot mode.
- Flash TWRP by running "fastboot flash recovery TWRP.img" on a desktop PC while the phone is connected in fastboot mode.
Click to expand...
Click to collapse
I had a LineageOS running on the OPX before I screwed up an upgrade of LOS. I had TWRP on the phone. The bootloader must be unlocked then yes?
SebiderSushi said:
Pressing the volume up button while turning on the device normally puts it into fastboot mode and "Fasboot Mode" will be displayed in the middle of the screen along with the oneplus logo.
Click to expand...
Click to collapse
broadly, that is what I had done before, but right now I don't even get the fastboot logo.
SebiderSushi said:
Unlocking only works with the original OnePlus recovery and if the option "Allow OEM unlocking" is checked in the developer settings. Unlocking requires wiping all userdata.
Click to expand...
Click to collapse
Right, but I had passed that station before, as it was running LOS.
SebiderSushi said:
Did you never do this yourself with your OnePlus X? Did you get this device as a used phone from someone else who already unlocked the bootloader?
Click to expand...
Click to collapse
No, I did all this myself, but screwed up the update to a non-official LOS.
SebiderSushi said:
What do you mean by "bootloop constantly"? Could you not boot the recovery?
Click to expand...
Click to collapse
I could not, no, but now I'm not even getting the fastboot logo
SebiderSushi said:
Are you saying you already ran QDL with the unmodified files from the UnBrick tool?
Click to expand...
Click to collapse
Correct, yes.
SebiderSushi said:
I am not sure of the precise timeline and order of your descriptions. I currently assume that you're saying:
1. Had a working device with ROM: "LineageOS 13.0" Recovery: "TWRP version 3.0.2-1" Firmware: Unknown
2. Flashed some "lineage-16.0-unofficial.zip" in TWRP
3. When rebooting, "bootloops" appeared [How did that look? What was affected - just ROM or recovery as well?]
Click to expand...
Click to collapse
Initially I could get to recovery, I tried to upgrade to the latest TWRP for the OPX, when I tried to restart that to recovery, it would just vibrate and reboot continuously
SebiderSushi said:
7. Still not booting [What exactly does this mean? Still no reaction to button presses? Dees the phone vibrate and bring up the OnePlus logo?]
Click to expand...
Click to collapse
Currently, the screen stays black, and I can hold volume up or power for 20 seconds with no reaction (no vibrate, no logo)

First off, i'm extremely sorry for my delay! I also happened to notice your message just today.
Right now i got around and tried reproducing your scenario on my own OnePlus X.
As you said that you ran the unmodified setup from the unbrick tool according to my guide, i did as well - and ran into the same issue you were describing.
After some fiddling around, i realized that you must supply the patch0.xml file as well for a complete flash on the OnePlus X when you also modify the GPT (partition table), which the unmodified rawprogram0.xml does. This is not the case if you only install a recovery or other individual partitions so it slipped my mind. I deeply apologize for not testing the command line for the unmodified UnBrick tool package well enough while writing my Guide.
If nothing else is wrong, running
"/path/to/qdl_source_code/qdl prog_emmc_firehose_8974.mbn rawprogram0.xml patch0.xml"
with the unmodified UnBrick tool will fix the device back to a booting state with the stock recovery and Lollipop Bootloader installed on the device., it did so in my case.
Alternatively, if you don't want to reflash all partitions from the package, you can also just try running
"/path/to/qdl_source_code/qdl prog_emmc_firehose_8974.mbn patch0.xml"
Short of any good documentation, i guessed that the problem appeared because the unmodified rawprogram0.xml also writes the GPT table in its last two program elements. If you look in patch0.xml, you can see that it takes care of the GPT in some way. Once i removed the two program items regarding the GPT, rawprogram0.xml could be applied without needing to flash patch0.xml together with it.
So i assume that it is safe to individually flash any partition listed it rawprogram0.xml apart from the GPT. If your GPT is not in a valid state, there's not much booting going on, since your device won't be able to even read your bootloader from the disk without a partition table.
emilianoheyns said:
I had a LineageOS running on the OPX before I screwed up an upgrade of LOS. I had TWRP on the phone. The bootloader must be unlocked then yes?
Click to expand...
Click to collapse
While this implies that you very likely once had an unlocked bootloader to allow installation of TWRP to your device, it is not necessarily the case. For one, it is possible to re-lock the bootloader on the OnePlus X and still boot and use custom recoveries and software. Only flashing images via fastboot becomes impossible again if you relock the bootloader. This is because the OnePlus X is a fairly old device (remember it came out with android 5.1). Such old devices don't support features like Android Verified Boot yet. This is the standard on modern android devices and it implies that a locked bootloader should only load and boot untampered system partitions as signed by the device vendor.
Edit 2022-09-04: I was wrong about this. This only applies to the OxygenOS 2 bootloader. Trying to boot an unsigned ROM or recovery with an unlocked OxygenOS 3 bootloader causes the exact symptoms that were described; The bootloader repeatedly tries booting in an infinite loop. Probably the LOS fash that went wrong caused the bootloader to re-lock, which is why rebooting to recovery didn't work afterwards as well as booting the ROM.
Also, qdl (or any othe software using the Qualcomm Emergency Download Mode) can also install custom Recoveries or ROMs to the devices without unlocking the bootloader and flashing stuff through fastboot.

After that, you can also boot back into fastboot mode and the run
fastboot oem device-info
from your computer to check if your devices bootloader is currently unlocked or not. If it is not, this is a perfect chance to unlock it, since you already got the official recovery installed and probably no user data to take care of anyway.

Hi, thanks for getting back to me. The problem I'm facing currently is that the OPX currently seems unresponsive -- the screen stays black, and no vibration, seemingly regardless of what button combination I use or how long I keep it on the charger. Any idea what key combo is most likely to bring it up in a state that QDL would see it?
I have fetched a fresh copy of OPX_UnBrick_Mini_By_Naman_Bhalla; I'm sorry to have to ask again, but I should then copy over prog_emmc_firehose_8974.mbn, rawprogram0.xml and patch0.xml unchanged, and run `/path/to/qdl_source_code/qdl prog_emmc_firehose_8974.mbn rawprogram0.xml patch0.xml`? I think I'd prefer to get it back to a booting state to then figure out what I can safely flash on it.
---------- Post added at 04:35 PM ---------- Previous post was at 04:30 PM ----------
I should note, if I connect the charger, the red charging light comes on for a second, maybe two, end then goes out again. It does not come back on unless I plug in again, even if I let it charge overnight.

In my case the usual route to enter EDL mode worked fine - that is, disconnect your OnePlus X from any power source for a few seconds, then press and hold the Volume Up button and after a few seconds reconnect it to your PC where you run qdl, then release the button and execute qdl.
If you want to flash the default confuguration of the unbrick tool you must open your terminal window in the folder you extracted from the download (or cd to it). This is because the files that are flashed to the device are in this folder as you caj see and they are being referenced with relative paths / their filenames from within "rawprogram0.xml".

SebiderSushi said:
In my case the usual route to enter EDL mode worked fine - that is, disconnect your OnePlus X from any power source for a few seconds, then press and hold the Volume Up button and after a few seconds reconnect it to your PC where you run qdl, then release the button and execute qdl.
Click to expand...
Click to collapse
Ah well, it must have died somewhere along the way then. When I do that, even after having it on the charger, nothing shows up in dmesg. Thanks in any case!

I wouldn't give up just yet. The actual rule for entering EDL mode on the OnePlus X is:
- The device must be powered off at the beginning
- The Volume Up button must be in pressed state when connecting it to the computer
Edit 2022-09-04: I was wrong about this. It is also possible to hold Power+Vol Up while connected to the PC until the device shows up in dmesg -w
Everything else, like waiting few seconds here and there is mostly safeties to ensure each state is entered or recognized cleanly.
I mostly had my phone running fresh from the last flashing process, which means that qdl had turned it off cleanly for me. So i definitely had good conditions to enter EDL mode.
I don't know what's going on with your notification LED since i didn't notice this on my device or payed any attention to it - but it might indicate that your phone could be in a not cleanly powered off state.
You can still try pressing the power button for a longer time (maybe about 10 to 30 seconds) to see if that switches off your device the right way before you retry entering EDL mode.
Or do any other experiments pressing buttons or try with different cables.
When was the last time you could successfully connect your device in any mode and which mode was it?

The symptoms you described about black screen, no vibrations or any reaction to button presses were also present on my device as well so this is i'd guess it's just normal for the state.

If you get it back to a booting state you should be able to install the official OxygenOS right from the stock recovery, or flash a compatible TWRP image using qdl or fastboot and copy any remaining data that you want to keep.

@SebiderSushi, could you please take a look at >this post< and hint if anything else can be done using edl on linux?

Database Users

welcome