Database Develop

[Q] Why can't I encrypt my device?

Hello,
I've been trying to encrypt my device for a while now. It always just goes to the encrypting icon, then waits a second and boots into CM12.1 again. Now I've tried to use adb logcat, where I was able to find this when starting encryption, just after all the SIGKILLs:
E/Cryptfs ( 229): Cannot open real block device /dev/block/platform/msm_sdcc.1/by-name/userdata
E/Cryptfs ( 229): Unable to get crypt_ftr_info
E/Cryptfs ( 229): Cannot get size of block device /dev/block/platform/msm_sdcc.1/by-name/userdata
Click to expand...
Click to collapse
I'm using CM12.1 titan linked here. However, I'm fairly certain that this is not a ROM issue, I've had it on all ROMs. Any help would be greatly appriciated.
~ Robin

maybe it really is the encryption footer?
Robin.S said:
I've been trying to encrypt my device for a while now. It always just goes to the encrypting icon, then waits a second and boots into CM12.1 again. Now I've tried to use adb logcat
Click to expand...
Click to collapse
(I'm sorry but it won't let me post links yet, you'll have to fix them below to use, I stripped the schemes, put them between LINK uppercase, and italicized the link text)
I'm getting the same thing, I just tried with 20150505 nightly cm12.1, this seems to a be a known issue, but with very little real information as to the problem. I found LINK forum.cyanogenmod.org/topic/88973-moto-g-cm11-encryption-failed/ LINK this forum post going back to mid 2014, and LINK jira.cyanogenmod.org/browse/CYAN-4532 LINK the linked JIRA bug which seems to indicate that all the Moto G devices (falcon, peregrine, titan), possibly Moto X as well are affected, but nobody seems to know what causes this bug, only vague hints that it may be a "timing related issue" but no other clarifying information in the now more than a year since this bug was posted.
The obvious conclusion is that nobody is encrypting their devices, which I find bizarre. Once Motorola releases a 5.1 factory ROM for this device (which is supposedly imminent -- they've already released for G-2013 and X-2014 I believe), I'll flash it and test that one.
I used logcat -v long and saw the times, the process kills definitely come after the attempts to open the block device fails. I did a logcat -c in one shell and then a vdc cryptfs enablecrypto inplace <password> in another (this is what the encrypt UI initiates), and the after the resulting softboot (it keeps the adb shell alive, and system uptime continues, so this isn't a hard boot), a logcat shows the same sequence:
Code:
[ 05-06 20:06:03.897 230: 287 E/Cryptfs ]
Cannot open real block device /dev/block/platform/msm_sdcc.1/by-name/userdata
[ 05-06 20:06:03.897 230: 287 E/Cryptfs ]
Unable to get crypt_ftr_info
[ 05-06 20:06:03.898 230: 287 E/Cryptfs ]
Cannot get size of block device /dev/block/platform/msm_sdcc.1/by-name/userdata
and then the kills start.
At first, because of the apparent inability to get crypt footer (in the error message), I thought this was lack of the 16k footer mentioned in the aforementioned bug, but LINK review.cyanogenmod.org/#/c/86684/ LINK the patch to include it appears to be long incorporated in LINK github.com/CyanogenMod/android_device_motorola_titan/blob/cm-12.1/BoardConfig.mk LINK our board's version of this file.
However, as I write this, I notice that the size in BoardConfig.mk does not correspond to the one on the device:
Code:
$ readlink /dev/block/platform/*/*/userdata
/dev/block/mmcblk0p38
$ grep mmcblk0p38 /proc/partitions
259 6 5774208 mmcblk0p38
$ bc
((5930598400 / 1024) - 5774208) / 1024
16.9843750000
they appear to differ by slightly more than 16k (the size of the encryption footer). But yet /system corresponds exactly with the line from BoardConfig.mk:
Code:
$ readlink /dev/block/platform/*/*/system
/dev/block/mmcblk0p36
$ grep mmcblk0p36 /proc/partitions
259 4 1130496 mmcblk0p36
$ bc
1157627904 / 1024
1130496.0000000000
so now I'm thinking that really is the problem (the userdata partition needs to have its size extended by 16k). But then there is LINK forum.cyanogenmod.org/topic/104204-xt1039-cm12-nightly-20150123-encryption-of-data-partition-not-working-simply-warm-reboots/ LINK this forum post which claims that the same partition encrypts fine with the stock image.
I didn't factory reset when flashing cm12.1 (from a stock 5.x ROM), which I think recreates the partition (?) So, maybe the partition didn't get resized to the correct value. However if the stock ROM handles this case, I should think CM would too.
What about you? Did you factory reset (including /data) when you installed CM on your Titan? I saw no need to get rid of /data (although I did have to delete some things in /data/misc to get rotation working) when coming from stock ROM and wanted to avoid having to redo everything. Which worked fine... except for this

TF701T NvFlash Unbrick Solution(tested)

TF701T NvFlash Unbrick Solution(tested)
(continue of the threadhttps://forum.xda-developers.com/showthread.php?t=2655888)
Charge tab before unbricking.
Connect tab to PC.
If your tab not started already in APX mode, then run APX mode by pressing button combination Vol+ and Power.
Insall drivers from "usb_drivers" if needed.
If there is a problem with the installation of drivers, use Google to search- how to install unsigned drivers.
When device installed correctly run "tf701t_flash.bat".
If flash process interrupts with error like ...read\write error..., then probably EMMC memory chip is damaged and need to replace.
If flash process complete, then we ready to next step.
Prepare fat32 formatted microSD card.
Download from ASUS site update package.
https://www.asus.com/us/Tablets/The_New_ASUS_Transformer_PadTF701T/HelpDesk_BIOS/
It _MUST_ be Version V10.14.1.47, SKU(region)- of your choice.
The downloaded file will look like **_epaduser_10_14_1_47_UpdateLauncher.zip
There will be another archive inside that archive.
Extract it, and rename it to t4_sdupdate.zip
Put t4_sdupdate.zip in root of microSD card.
Insert microSD card in tab, then start tab in recovery mode by pressing Vol- and Power key combination.
Follow onscreen instructions to complete recovery process.
After all you tab must be restored to factory state JB Android.
Now you may update firmware version using OTA or sdcard.
NvFlash TF701T Unbrick
http://mega.nz/#!mk8k0Y5S!TQJVfcQudH9HIMnapiGZWccV3VvygnTjDWYLxJte4lo
mirror
http://smartjtagbox.com/owncloud/index.php/s/T8DKqDuhSZzffSp

What is this? A covert ad campaign for Mega? How about hosting the file somewhere that does not force you to download an app, open an account and all that cr***? I'd be really curious to see the code, but not like this.....
Sent from my TF700T using Tapatalk

berndblb said:
What is this? A covert ad campaign for Mega? How about hosting the file somewhere that does not force you to download an app, open an account and all that cr***? I'd be really curious to see the code, but not like this.....
Click to expand...
Click to collapse
Where did you see the ad or need to register, or requirement of install the program for downloading?
Just checking in IE and FF.
I see a big red button- "download", no ads, and no requirements.
Ok, for those who have problems with mega.nz added a mirror for download.

TF701t - Hard Reset Fails ...
Dear Community,
I wanted to hard reset my TF701t to delete my data and give it to another one.
But now it stucks in "deleting data" ... that endures a minute then a dead android is on the screen.
When I want to reboot it, the hard reset comes again and want to delete everything, but the dead android is coming back :/
I can't go in Recovery Mode (Volume-down + Power)
Connection to APX works but, see pic below ...
I don't know what I could try anymore ...
Hope somebody have an idea.
Best greetings,
Symbic
Bild -> url: ibb.co/iFP5JH
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}

Symbic said:
Dear Community,
I wanted to hard reset my TF701t to delete my data and give it to another one.
But now it stucks in "deleting data" ... that endures a minute then a dead android is on the screen.
When I want to reboot it, the hard reset comes again and want to delete everything, but the dead android is coming back :/
I can't go in Recovery Mode (Volume-down + Power)
Connection to APX works but, see pic below ...
I don't know what I could try anymore ...
Hope somebody have an idea.
Best greetings,
Symbic
Bild -> url: ibb.co/iFP5JH
Click to expand...
Click to collapse
Link to the picture is broken, so we cannot see what result you got...
What's your situation: Bootloader unlocked? Custom recovery? I guess not since you get the dead Android?

link to screenshot ok.
as i can see- problems begin after trying access to EMMC chip.
"Taking backup of EKS"
unfortunately with 90% certainty i can say that the EMMC chip damaged.

mr.bin said:
link to screenshot ok.
as i can see- problems begin after trying access to EMMC chip.
"Taking backup of EKS"
unfortunately with 90% certainty i can say that the EMMC chip damaged.
Click to expand...
Click to collapse
Can I do anything else to test the EMMC chip?

Symbic said:
Can I do anything else to test the EMMC chip?
Click to expand...
Click to collapse
In that state the EMMC chip can be tested with the special equipment like EasyJtag box.

Hello Mr Bin, registered an account just to say thank you...
You have no idea.. was helping a friend to update, but the guy who sold it(tf701) had bought it from different region and turned it to US, so we ended up hard bricking it.
Long story short, we hard bricked it.
Thank you for your hard work in making the fix, and a big THANK you for sharing it...
Perfect fix, its better than before because it got updated to .47 (we couldnt update, no OTA no manual, too old version for custom recoveries)
Again.. thanks :good::good:

Thanks.
But, after clicking to RCK, shows Android with blue procesing line and after few seconds android with open door and red triangle !. After few minutes bootloop....nothing more.
What can i doing again?

Wow! It's back!
Hi.
First of all: Thank you very much! I was sure my tablet was a goner... It is actually back. One tip I'd like to add: I had to try around a bit to get into APX mode. But essentially I just had to connect the tablet to my PC and then push "Volume up" and power at the same time - and ignore that the screen did not light up ...
Again: Thanks a lot!

Mr.Bin,
You have resurrected my TF701T! Thank you SOOOO MUCH! You are an actual genius! Thanks!

Help w installation
I have the same problems although i have not installed any custom OS but after few months of not using it didnt load up and ended in APX mode.
Tried this solution, installed the driver, started the .bat file and ended up here :
Nvflash 3.08.1704 started
Using blob 3.08.1704
chip uid from BR is: 0x600000015c3e10080c000000190301c0
rcm version 0X350001
Skipping BoardID read at miniloader level
System Information:
chip name: unknown
chip id: 0x35 major: 1 minor: 2
chip sku: 0x3
chip uid: 0x000000015c3e10080c000000190301c0
macrovision: disabled
hdcp: enabled
jtag: disabled
sbk burned: true
board id: 0
warranty fuse: 0
dk burned: true
boot device: emmc
operating mode: 6
device config strap: 0
device config fuse: 17
sdram config strap: 0
RCM communication completed
sending file: flash.bct
- 8192/8192 bytes sent
flash.bct sent successfully
BCT sent successfully
odm data: 0x82098000
downloading bootloader -- load address: 0x80108000 entry point: 0x80108000
sending file: bootloader.bin
data send failed NvError 0x120002
command failure/warning: bootloader download failed (bad data)
I would be very thankful for any information you could read from this. Just would like to know if i even have a chance of getting it back on.

So, I was running fine with CROMi-X KitKat, but wanted to upgrade to Marshmallow (to install sw not supported in KitKat), so decided to try KatKiss 6.0. It's been years since I've played with flashing ROMs, but I did a little reading to refresh my memory. Then I rebooted into recovery (ClockworkMod), backed everything up, then wiped everything, formatted /data, and tried flashing the KatKiss zip file. At that point, it just sat there forever at the ASUS logo screen:
I've tried several times to boot back into recovery by holding the Vol+ and Power buttons, but it either doesn't boot, or boots to the above screen. I've connected it to my Mac w/ the Android SDK Platform Tools, but adb doesn't see any device listed. [I've got an old Windows laptop (XP?)] I could use if it will do something the Mac can't.]
Any advice on how I can save this tablet?

This method can be apply to tft300t?

Hi! What a great thread! After lurking on this forum for many years, i've registered to expose my issue with an old tf701 that was given to me by a friend. He say me he installed esexplorer and deleted file to clean space. Next day he rebooted and never been able to boot system. Now tablet is in bootloop ending with blackscreen and backlight on. Im able to open in fastboot and talk with minimal adb and fastboot. RCK update ending with fallen robot, Wipe data/cache ending with fallen robot. APX mode also working and ive run mr.bin's Nvflash unbrick tool with this result:
Nvflash 3.08.1704 started
Using blob 3.08.1704
chip uid from BR is: 0x600000015c3e10060400000001058440
rcm version 0X350001
Skipping BoardID read at miniloader level
System Information:
chip name: unknown
chip id: 0x35 major: 1 minor: 2
chip sku: 0x3
chip uid: 0x000000015c3e10060400000001058440
macrovision: disabled
hdcp: enabled
jtag: disabled
sbk burned: true
board id: 0
warranty fuse: 0
dk burned: true
boot device: emmc
operating mode: 6
device config strap: 0
device config fuse: 17
sdram config strap: 1
RCM communication completed
sending file: flash.bct
- 8192/8192 bytes sent
flash.bct sent successfully
BCT sent successfully
odm data: 0x82098000
downloading bootloader -- load address: 0x80108000 entry point: 0x80108000
sending file: bootloader.bin
| 1463232/1463232 bytes sent
bootloader.bin sent successfully
waiting for bootloader to initialize
bootloader downloaded successfully
Taking backup of EKS
Receiving file: EKS_0400000001058440.bin, expected size: 4194304 bytes
/ 4194304/0 bytes received
file received successfully
Taking backup of PER
Receiving file: PER_0400000001058440.bin, expected size: 8388608 bytes
/ 8388608/0 bytes received
file received successfully
Taking backup of ABT
Receiving file: ABT_0400000001058440.bin, expected size: 4194304 bytes
/ 4194304/0 bytes received
file received successfully
Continuing create using flash.cfg
setting device: 2 3
deleting device partitions
creating partition: BCT
creating partition: PT
creating partition: EBT
creating partition: DFI
creating partition: BMP
creating partition: ABT
creating partition: GP1
creating partition: SOS
creating partition: DTB
creating partition: LNX
creating partition: APP
creating partition: CAC
creating partition: APD
creating partition: ADF
creating partition: MSC
creating partition: USP
creating partition: PER
creating partition: CRA
creating partition: MDA
creating partition: EKS
creating partition: UDA
creating partition: GPT
sending file: bootloader.bin
| 1463232/1463232 bytes sent
bootloader.bin sent successfully
sending file: xusb_sil_rel_fw
- 126464/126464 bytes sent
xusb_sil_rel_fw sent successfully
sending file: ABT_0400000001058440.bin
/ 4194304/4194304 bytes sent
ABT_0400000001058440.bin sent successfully
sending file: recovery.img
\ 7272704/7272704 bytes sent
recovery.img sent successfully
sending file: boot.img
- 6760704/6760704 bytes sent
boot.img sent successfully
sending file: PER_0400000001058440.bin
/ 8388608/8388608 bytes sent
PER_0400000001058440.bin sent successfully
sending file: EKS_0400000001058440.bin
/ 4194304/4194304 bytes sent
EKS_0400000001058440.bin sent successfully
failed executing command 26 NvError 0x120002
command failure/warning: sync failed (bad data)
bootloader status: Bct Write Failed (code: 22) message: nverror:0x40005 (0x14000
5) flags: 0
Click to expand...
Click to collapse
Advise would be great help. I dont know if mmc could be dead, it showing some successful tranfert but keep failing at same place. Thanks!

Hello. These commands for nvflash make a backup and installation of the system.
REED
@cls
@nvflash.exe --blob blob.bin --bl bootloader.bin --read 9 recovery.img --read 11 boot.img --read 12 system.img
@pause
WRITE
@cls
@nvflash.exe --blob blob.bin --bl bootloader.bin --download 9 recovery.img --download 11 boot.img --download 12 system.img
@pause
Thanks mr.bin for a great tool

Important information who uses nvflash!
3 files (ABTxxxxxxxxxxxxxxxx.bin, EKS_xxxxxxxxxxxxxxxx.bin, PER_xxxxxxxxxxxxxxxx.bin, which are created after running nvflash, must be flashed again. Otherwise, it will be impossible to unlock the tablet again and the serial number will be lost. Save in a safe place and then rename the files to EKS, ABT, PER.
To do this, create a second file with the bat extension. In a text editor, type these lines
Code:
nvflash --wait --blob blob.bin --bl bootloader.bin --download 7 ABT --download 21 EKS --download 18 PER --go
If these files are saved on the unlocked tablet, then after their firmware unlocking will be restored.
Also, using nvflash, you can resize partitions, flash a bootloader with file system markup, recovery.

There is no way to load an unlocked bootloader in this process ??

[GUIDE] Increase your Nexus 4's system partition for more space!

I got tired of installing amazing ROMs created by the talented folks here on XDA, but being held back on things like Google Apps because of the tiny /system partition we have on the Nexus 4. I looked around and found guides to increase the system space in the Nexus 5 and Nexus 7 2013, so I basically just adapted them to work on our beloved Nexus 4.
As always, do this at your OWN risk. I am not responsible for bricking your Nexus 4. I will simply list the process which I used to increase my Nexus 4's system partition (by taking a big ol' chunk from the cache partition). Remember, any sort of modification to your device of this caliber WILL void any warranty you might still have.
REQUIREMENTS:
parted (Uploaded to my Google Drive. If it downloads as a .txt, rename it to remove the extension and make it a plain file)
adb and fastboot, and preferably knowledge on how they work
Step 1: Install TWRP onto your Nexus 4 and reboot into it.
Step 2: Open up command prompt / terminal and check to see if your Nexus 4 is connected properly with "adb devices".
Step 3: Once you've confirmed that adb is fully working and your Nexus 4 is properly connected to your PC, download parted and use adb to push it to your Nexus 4 using the command:
Code:
adb push parted /
Step 4: Now enter the following command:
Code:
adb shell
and then the command:
Code:
chmod +x parted
This will enter adb shell and make the "parted" binary you pushed to your device earlier executable.
Step 5:
Now run the command
Code:
./parted /dev/block/mmcblk0 p
You should see a long list with a bunch of numbers and names in your terminal. These are the partitions on your device. parted will give you the partition number, the "start" and "end" of the partition, the size, and the name.
This is the partition layout on my device. It will probably be the same on your device, though the size of userdata may vary depending on whether you have the 8gb or 16gb Nexus 4.
Code:
~ # ./parted /dev/block/mmcblk0 p
Model: MMC 016G92 (sd/mmc)
Disk /dev/block/mmcblk0: 15.8GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 524kB 67.6MB 67.1MB fat16 modem
2 67.6MB 68.2MB 524kB sbl1
3 68.2MB 68.7MB 524kB sbl2
4 68.7MB 70.8MB 2097kB sbl3
5 70.8MB 71.3MB 524kB tz
6 71.3MB 94.4MB 23.1MB boot
7 94.4MB 117MB 23.1MB recovery
8 117MB 118MB 799kB m9kefs1
9 118MB 119MB 799kB m9kefs2
10 119MB 120MB 799kB m9kefs3
11 120MB 121MB 524kB rpm
12 121MB 121MB 524kB aboot
13 121MB 122MB 524kB sbl2b
14 122MB 124MB 2097kB sbl3b
15 124MB 124MB 524kB abootb
16 124MB 125MB 524kB rpmb
17 125MB 125MB 524kB tzb
18 125MB 126MB 524kB metadata
19 126MB 143MB 16.8MB misc
20 143MB 159MB 16.8MB ext4 persist
21 159MB 1040MB 881MB ext2 system
22 1040MB 1627MB 587MB ext4 cache
23 1627MB 15.8GB 14.1GB ext4 userdata
24 15.8GB 15.8GB 524kB DDR
25 15.8GB 15.8GB 507kB grow
Step 6:
Now run the following three commands:
Code:
umount /data
umount /sdcard
umount /cache
Step 7: So, on my Nexus 4, the system partition is number 21, and cache is 22. We're kinda lucky in the fact that system and cache are right next to each other, meaning we don't have to touch any other partition.
You'll want to run these two next commands. These commands will essentially "remove" the two partitions.
Code:
./parted /dev/block/mmcblk0 rm 21
./parted /dev/block/mmcblk0 rm 22
Step 8: Now it is time to recreate these two partitions, however, when recreating them, we will make system bigger and the cache smaller. From the partitions list we got in Step 5, we can see that system starts at 159 and ends at 1040, while cache starts at 1040 and ends at 1627. The following two commands will rebuild /system starting at 159, but ending at 1590, while rebuilding cache at 1590, and ending at 1627. We are essentially stealing a large chunk from cache, since we don't really need that anymore on newer ROMs.
Code:
./parted /dev/block/mmcblk0 mkpart primary 159 1590
./parted /dev/block/mmcblk0 mkpart primary 1590 1627
Step 9: Now run this command:
Code:
./parted /dev/block/mmcblk0 p
This will bring up the partitions list, or table, again. This time, however, we'll see the new partitions where system and cache were, however, they have no names! The following two commands will name the two partitions again.
Code:
./parted /dev/block/mmcblk0 name 21 system
./parted /dev/block/mmcblk0 name 22 cache
Step 10: Great! Now the partitions should be named again! Now, we still have to format the partitions as ext4 so that we can actually use them. The following two commands will do that for you.
Code:
mke2fs -b 4096 -T ext4 /dev/block/mmcblk0p21
mke2fs -b 4096 -T ext4 /dev/block/mmcblk0p22
Step 11: At this point, feel free to run the command from Step 5 to take one more look at the partition table and make sure everything looks good. Now run the command
Code:
mount -a
and then type in
Code:
exit
.
Step 12: Now we are pretty much done. We've extended the system partition from approx. 881mb to 1431mb, which is a nice large chunk of memory. In the future, we could always mess with the partitions more to add even more space by stealing from userdata, but until we reach that point, I think we are pretty well set for now!
Now...
You'll want to reboot TWRP, and flash a new ROM. You can now use a much bigger Google Apps package, without any worries.
Do note, however, that flashing a ROM will "resize" system to be smaller, but this isn't a huge deal. After flashing a ROM, while still in TWRP, you'll want to go to Wipe > Advanced Wipe > check "system" then head to "Repair or Change File System", > then tap on "Resize File System." If you encounter any errors while trying to resize, try remounting system or rebooting TWRP. Afterwards, you should be able to flash your Google Apps package. I'm not sure if you need to repeat these steps after flashing things other than ROMs, but repeating this process within TWRP should work just as well.
I hope I helped y'all out and feel free to post if this guide worked for you or if you have any other comments!
CREDITS:
@surfrock66 for his Nexus 5 guide here.
@rkhat for his Nexus 7 2013 guide here.

RESERVED

Worked Thanx

It worked here on my 8 Gb mako. Here are the original parted output:
Code:
Model: MMC 008G92 (sd/mmc)
Disk /dev/block/mmcblk0: 7818MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 524kB 67.6MB 67.1MB fat16 modem
2 67.6MB 68.2MB 524kB sbl1
3 68.2MB 68.7MB 524kB sbl2
4 68.7MB 70.8MB 2097kB sbl3
5 70.8MB 71.3MB 524kB tz
6 71.3MB 94.4MB 23.1MB boot
7 94.4MB 117MB 23.1MB recovery
8 117MB 118MB 799kB m9kefs1
9 118MB 119MB 799kB m9kefs2
10 119MB 120MB 799kB m9kefs3
11 120MB 121MB 524kB rpm
12 121MB 121MB 524kB aboot
13 121MB 122MB 524kB sbl2b
14 122MB 124MB 2097kB sbl3b
15 124MB 124MB 524kB abootb
16 124MB 125MB 524kB rpmb
17 125MB 125MB 524kB tzb
18 125MB 126MB 524kB metadata
19 126MB 143MB 16.8MB misc
20 143MB 159MB 16.8MB ext4 persist
21 159MB 1040MB 881MB ext2 system
22 1040MB 1627MB 587MB ext4 cache
23 1627MB 7817MB 6190MB ext4 userdata
24 7817MB 7818MB 524kB DDR
25 7818MB 7818MB 507kB grow
I'm using Nitrogen OS 8.1 with GZR Gapps

jfsobreira said:
It worked here on my 8 Gb mako. Here are the original parted output:
Code:
Model: MMC 008G92 (sd/mmc)
Disk /dev/block/mmcblk0: 7818MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 524kB 67.6MB 67.1MB fat16 modem
2 67.6MB 68.2MB 524kB sbl1
3 68.2MB 68.7MB 524kB sbl2
4 68.7MB 70.8MB 2097kB sbl3
5 70.8MB 71.3MB 524kB tz
6 71.3MB 94.4MB 23.1MB boot
7 94.4MB 117MB 23.1MB recovery
8 117MB 118MB 799kB m9kefs1
9 118MB 119MB 799kB m9kefs2
10 119MB 120MB 799kB m9kefs3
11 120MB 121MB 524kB rpm
12 121MB 121MB 524kB aboot
13 121MB 122MB 524kB sbl2b
14 122MB 124MB 2097kB sbl3b
15 124MB 124MB 524kB abootb
16 124MB 125MB 524kB rpmb
17 125MB 125MB 524kB tzb
18 125MB 126MB 524kB metadata
19 126MB 143MB 16.8MB misc
20 143MB 159MB 16.8MB ext4 persist
21 159MB 1040MB 881MB ext2 system
22 1040MB 1627MB 587MB ext4 cache
23 1627MB 7817MB 6190MB ext4 userdata
24 7817MB 7818MB 524kB DDR
25 7818MB 7818MB 507kB grow
I'm using Nitrogen OS 8.1 with GZR Gapps
Click to expand...
Click to collapse
Awesome! Thanks for letting me know. Glad it worked for you. :good:

thank you very much !

Thx !
Thx !

Great guide works perfectly.. has anyone tried to reverse the process and go back to stock to reflash a factory image?
I just tried it on my old Nexus 4, and after resettting the partitions, and reflashing the factory image, its just a permanent bootloop. I've cleared all the cache, tried a wipe from the stock recovery, tried flashing TWRP and wiping there.. nothing seems to work. Im not too worried, but it'd be nice if it could boot again.

Thanks for your guide. It worked like a charm for my Nexus 4.
Just a small addition: To resize the system partition automatically I placed a script in /system/addon.d:
Code:
#!/sbin/sh
#
# /system/addon.d/10-resize-system.sh
#
. /tmp/backuptool.functions
case "$1" in
backup)
# Stub
;;
restore)
# Stub
;;
pre-backup)
# Stub
;;
post-backup)
# Stub
;;
pre-restore)
/sbin/resize2fs /dev/block/platform/msm_sdcc.1/by-name/system
;;
post-restore)
# Stub
;;
esac

If it doesn't work for you
Thanks for this great guide!
Decided to breath some new life into an old N4 in my family and now it's going (very) strong again with LineageOS 15.1. Still had to clear a bit over 100 MB with .gapps-config from Stock-OpenGapps, but that's no biggie. I always liked to start with the big package and then remove everything that I don't need from it.
Second issue gave me some headaches at first.
"Resize File System" in TWRP apparently worked and Gapps-Install went through (~100 MB free at the end), but boot would fail and crash back to recovery.
(I'm using the daily LOS-nightlies by Milaq and Stock-Package from OpenGapps, maybe it's no problem with other ROMs and/or Gapps-Packages.)
Turns out the fix in TWRP wasn't really working, nevermind what partition size it shows for /system afterwards. It's somehow corrupted and still has the original size -> most of the gapps stuff get's written to nirvana, thus the failing boot.
I found the solution over in the Nexus5-Thread:
JekaPinsk said:
Hello guys!
Try this:
1) Install ROM
2) Backup ROM
3) Enable "Use 'rm -rf' instead of formatting" in TWRP settings
4) Format /system
4.1) Unmount /system and use 'resize2fs -f /dev/block/mmcblk0p21' in terminal (TWRP)
5) Reboot TWRP
5.1) Uncheck "Use 'rm -rf' instead of formatting" in TWRP settings
6) Restore backup
7) Install Stock OpenGapps
8) Done!
The idea behind it is that ROM installation somehow corrupt /system partition thus any write operations above normal data region silently fail.
Click to expand...
Click to collapse
at step 4.1 I already changed the partition number to 21 for Nexus4. In the original post it says mmcblk0p25, because on the Nexus 5 that's /system.
Now it works.
In theory this procedure should also work for updating the ROM without losing data, but haven't tested it yet. (Maybe throw in a wipe of /system as step 0...?)
To be clear: This isn't the fault of the guide to resize system-partition.
Problem is (at least certain) ROMs resetting size of file system to original and then TWRP failing to fix that doing it the easy way as described in OP (-> bug in TWRP?).
EDIT:
Above procedure also works for an update without data loss. Only difference was I did a normal wipe of /system first, "step 0" so to say.
No idea if all this is still necessary with TWRP 3.2.3-0, I'm not willing to risk a full wipe at this point. ^^

i need this...can't even install the smallest gapps package after oreo.... word!! thanks!

Really wanted to thank-you for this!
Two questions:
1. When you printed the partitions, system (21) was ext2. When you recreated it after resizing, you created it as ext4. Was that intentional?
2. You also made the claim that modern ROMs don't need such a big cache partition (your new one was 37MB, I wasn't so brave). Can you justify that claim or provide some technical details? It's not that I don't believe you (I trusted you enough to do this on my device!), just merely curious as to why/how this would be.
Thanks!

X:\xxx\xxx\xxx\xxx\adb>adb push parted /
487 KB/s (346680 bytes in 0.695s)
X:\xxx\xxx\xxx\xxx\adb>adb shell
~ # chmod +x parted
chmod +x parted
~ # ./parted /dev/block/mmcblk0 p
./parted /dev/block/mmcblk0 p
Error: Can't have overlapping partitions.
~ # 
Please Help!!!!!!!!!!!!!!!!!!!

caliban2 said:
Thanks for this great guide!
Decided to breath some new life into an old N4 in my family and now it's going (very) strong again with LineageOS 15.1. Still had to clear a bit over 100 MB with .gapps-config from Stock-OpenGapps, but that's no biggie. I always liked to start with the big package and then remove everything that I don't need from it.
Second issue gave me some headaches at first.
"Resize File System" in TWRP apparently worked and Gapps-Install went through (~100 MB free at the end), but boot would fail and crash back to recovery.
(I'm using the daily LOS-nightlies by Milaq and Stock-Package from OpenGapps, maybe it's no problem with other ROMs and/or Gapps-Packages.)
Turns out the fix in TWRP wasn't really working, nevermind what partition size it shows for /system afterwards. It's somehow corrupted and still has the original size -> most of the gapps stuff get's written to nirvana, thus the failing boot.
I found the solution over in the Nexus5-Thread:
at step 4.1 I already changed the partition number to 21 for Nexus4. In the original post it says mmcblk0p25, because on the Nexus 5 that's /system.
Now it works.
In theory this procedure should also work for updating the ROM without losing data, but haven't tested it yet. (Maybe throw in a wipe of /system as step 0...?)
To be clear: This isn't the fault of the guide to resize system-partition.
Problem is (at least certain) ROMs resetting size of file system to original and then TWRP failing to fix that doing it the easy way as described in OP (-> bug in TWRP?).
EDIT:
Above procedure also works for an update without data loss. Only difference was I did a normal wipe of /system first, "step 0" so to say.
No idea if all this is still necessary with TWRP 3.2.3-0, I'm not willing to risk a full wipe at this point. ^^
Click to expand...
Click to collapse
I'm using TWRP 3.2.3-0 and it has this bug, too. After I followed your steps I was able to install Nitrogen OS and Open Gapps Micro in my phone without erros.
Thanks!

I believe that resize2fs step can be packaged as a flashable zip so we can batch flashing without manual intervention to it (i.e. manually resize fs on system after each rom flash) .

ivanich said:
I believe that resize2fs step can be packaged as a flashable zip so we can batch flashing without manual intervention to it (i.e. manually resize fs on system after each rom flash) .
Click to expand...
Click to collapse
Maybe then more users would dare to use this solution and could calmly install gapps on Pie.
You have a lot of experience. What do you suggest?

Hi all. I only discovered this thread after independently figuring out the partitioning scheme (plain GPT) and process.
Sadly, even after this effort, it seems L-OS upgrades won't work unless L-OS devs modify their upgrade script to make use of resize2fs. Here's what happens as of package 2018-09-11:
L-OS runs backup procedure for all addons found in the existing /system/addon.d/
The above creates files (I guess) in /tmp
The /system is unmounted
The partition is overwritten with the image in the upgrade package
The script in addon.d/ are then run to restore the addons from /tmp
The problem is, the partition image in the upgrade package is for the old partition size, and therefore step 5 fails when the free space runs out. It seems the install or restore scripts don't detect this failure, and just exit without reporting an error, with 0B free space on /system.
I'm guessing the problem can be "solved" by formatting the system partition and installing LOS and all addons from scratch, but that's ridiculous. has anyone tried to raise this issue with devs? I'm about to report this in L-OS's JIRA, as I haven't seen any relevant report there.
EDIT: If anyone wants to track: https://jira.lineageos.org/browse/BUGBASH-2306

myxal said:
Hi all. I only discovered this thread after independently figuring out the partitioning scheme (plain GPT) and process.
Sadly, even after this effort, it seems L-OS upgrades won't work unless L-OS devs modify their upgrade script to make use of resize2fs. Here's what happens as of package 2018-09-11:
L-OS runs backup procedure for all addons found in the existing /system/addon.d/
The above creates files (I guess) in /tmp
The /system is unmounted
The partition is overwritten with the image in the upgrade package
The script in addon.d/ are then run to restore the addons from /tmp
The problem is, the partition image in the upgrade package is for the old partition size, and therefore step 5 fails when the free space runs out. It seems the install or restore scripts don't detect this failure, and just exit without reporting an error, with 0B free space on /system.
I'm guessing the problem can be "solved" by formatting the system partition and installing LOS and all addons from scratch, but that's ridiculous. has anyone tried to raise this issue with devs? I'm about to report this in L-OS's JIRA, as I haven't seen any relevant report there.
EDIT: If anyone wants to track: https://jira.lineageos.org/browse/BUGBASH-2306
Click to expand...
Click to collapse
You may be able to fix that on your own by adding an add-on.d named 00-resize-system (so that's it's ran first) that just does "resize2fs /dev/block/.../system", with maybe an unmount before and a mount after. This way, LOS can just flash the full image when upgrading and the system is resized before the other addons.d scripts run.

Fif_ said:
You may be able to fix that on your own by adding an add-on.d named 00-resize-system (so that's it's ran first) that just does "resize2fs /dev/block/.../system", with maybe an unmount before and a mount after. This way, LOS can just flash the full image when upgrading and the system is resized before the other addons.d scripts run.
Click to expand...
Click to collapse
Thanks for the tip, will give that a try. Any idea where I could find an "authoritative" docs/guide to those scripts? Just looked at the one supplied by open g-apps, and I don't really see the difference between the various commands that the script is supposed to handle (which is executed when?). Also what list_file() is supposed to provide.
backup
restore
pre-backup
pre-restore
post-backup
post-restore

myxal said:
Thanks for the tip, will give that a try. Any idea where I could find an "authoritative" docs/guide to those scripts? Just looked at the one supplied by open g-apps, and I don't really see the difference between the various commands that the script is supposed to handle (which is executed when?). Also what list_file() is supposed to provide.
backup
restore
pre-backup
pre-restore
post-backup
post-restore
Click to expand...
Click to collapse
You want to put the resize2fs call in the pre-restore section.
It should look like this:
Code:
pre-restore)
unmount /system
resize2fs /dev/block/platform/.../system
mount /system
;;
This includes unmounting and remounting /system which I think are needed, but YMMV. You'll need to fill in the full path to system under /dev.
There is no authoritative resource for backup scripts that I know of, but the gapps script is a good example.
P.S.: If you make it work, please post the script for others...

flash recovery partition from android system/userland

I'm having trouble with fastboot (see my thread here: https://forum.xda-developers.com/xperia-xz1-compact/help/issues-fastboot-t3971227, maybe you can help). However, I can seem to flash sony signed software in sony-service mode using newflasher. That's nice, but I haven't used stock android in years. I am very used to lineageos without gapps---nice and clean. So, for me, until I get rid of stock and get a clean flash of lineage, I'm really not happy.
Given my state of affairs, I'm wondering about flashing one of the exploitable sony stocks and to get root, then flashing the recovery partition with twrp from userland. Then, potentially, i could boot to that recovery and maybe (idk) flash a new system ROM. Does anyone have any tips or suggestions?

It should work as you outlined.
Still having BL unlocked and not usable fastboot seems like a major disadvantage to me.
Did you try with different PC to see if it is not due to usb chipset or something?
Preferably using usb 2.0 only chipset?
Maybe trying that from different OSes too - linux vs win?

Thanks for the reply. I got the exploitable firmware downloaded and flashed as well as your renosploit kit. Hasn't found a root shell yet although I'm hopeful it will eventually (I haven't read the details but I understand that the underlying vuln is a race condition).
One question: I suppose that given that tmp root status, it should be possible to copy a su binary over and make root permanent, that would make experimentation easier, I think. And if whatever I try fails the first time I wouldn't want to have to wait for the race condition exploit every time I wanted to reboot. Am I on the right track? If so, I suppose I need to either compile or download a su binary and possibly a supersu.apk in order to manage it. Are those already available for the xz1 compact?

@apexofservice, planting su binary is possible into /oem for example, it would switch the user to root, but without any better permissions, due to selinux, so it is useless.
But since you have your BL unlocked, you do not need that. As soon as you have twrp, you can flash magisk to have root on runtime easily. Or just enter twrp to have root in recovery.

j4nn said:
@apexofservice, planting su binary is possible into /oem for example, it would switch the user to root, but without any better permissions, due to selinux, so it is useless.
But since you have your BL unlocked, you do not need that. As soon as you have twrp, you can flash magisk to have root on runtime easily. Or just enter twrp to have root in recovery.
Click to expand...
Click to collapse
Got it. Thank you for this detail. So you think my best bet is to just use the root shell to `dd` the twrp image directly to some /dev? And then I would just `adb reboot recovery` and in theory I'm good to go.

Cool. I got a root shell with your exploit kit. I've got two questions at this point.
1) If my bootloader unlock had fully succeeded, would I have expected to find all 0x0 in the TA partition? In fact, there is data in there, so I went ahead and downloaded it. I skimmed the data with xxd and there are some sections of 0x0 as well though.
2) Second question, I've read that xperia's don't have a proper "recovery" partition the way some other boards do. So is FOTAkernel actually where I want to write twrp.img? Also, it would seem that this info is actually encoded somewhere in the fastboot client since on a working fastboot, you can just say "flash recovery" and it knows what part of the disk to write to. Any info about partition layouts on lilac and xperia's in general would be greatly appreciated.

apexofservice said:
Cool. I got a root shell with your exploit kit. I've got two questions at this point.
1) If my bootloader unlock had fully succeeded, would I have expected to find all 0x0 in the TA partition? In fact, there is data in there, so I went ahead and downloaded it. I skimmed the data with xxd and there are some sections of 0x0 as well though.
2) Second question, I've read that xperia's don't have a proper "recovery" partition the way some other boards do. So is FOTAkernel actually where I want to write twrp.img? Also, it would seem that this info is actually encoded somewhere in the fastboot client since on a working fastboot, you can just say "flash recovery" and it knows what part of the disk to write to. Any info about partition layouts on lilac and xperia's in general would be greatly appreciated.
Click to expand...
Click to collapse
1 - The TA partition contains significant amounts of other information as well. So it won't be empty.
The standard way of dealing with it is to not mess with it at all.
2 - The FOTAkernel is the recovery.
2a - The partition layout can be found from the stock firmware image in the "partition-image-LUNZ_X-FLASH-ALL-C93B.sin" file where "Z" is the LUN number. Once you extract the SIN file, you're left with an EFI partition header.
I've attached a CSV file that contains the layout as specified in the "partition-image-LUN0_X-FLASH-ALL-C93B.sin" file.
The layout for LUNs 1 and 2 both contain a single 4MB partition for "xbl" and "xblbak" respectively, so they're not as interesting.

@pbarrette, thanks! I tried the naive approach:
Code:
d if=twrp-3.2.1-0-lilac-10-patchlevel-2018-05-05.img of=/dev/block/bootdevice/by-name/FOTAKernel <
60128+0 records in
60128+0 records out
30785536 bytes transferred in 2.100 secs (14659779 bytes/sec)
G8441:/data/local/tmp # sync
G8441:/data/local/tmp # sync
G8441:/data/local/tmp # reboot recovery
Alas, it just rebooted back to system. It did seem to take a bit longer, so it's possible that it tried to boot from FOTAKernel and failed then fell back to system. I've just got a new root shell so I can look in startup logs from dmesg to see if there's anything of interest.
Also, I'm probably missing something really obvious. Thanks for any insight!
Reading dmesg now, this seems quite relevant (I recall booting to recovery on my z3 compact by touching a file in /cache/recovery). I'll post it here but I'm still reading the dmesg.
Code:
[ 7.406109] bs_roots: recovery filesystem table
[ 7.406120] bs_roots: =========================
[ 7.406125] bs_roots: 0 /data ext4 /dev/block/bootdevice/by-name/userdata
[ 7.406130] bs_roots: 1 /oem ext4 /dev/block/bootdevice/by-name/oem
[ 7.406134] bs_roots: 2 /cache ext4 /dev/block/bootdevice/by-name/cache
[ 7.406139] bs_roots: 3 /rca ext4 /dev/block/bootdevice/by-name/appslog
[ 7.406143] bs_roots: 4 /idd ext4 /dev/block/bootdevice/by-name/diag
[ 7.406148] bs_roots: 5 /storage/sdcard1 vfat /devices/soc/c0a4900.sdhci/mmc_host*
[ 7.406153] bs_roots: 6 none swap /dev/block/zram0
[ 7.406157] bs_roots: 7 /persistent emmc /dev/block/bootdevice/by-name/frp
[ 7.406162] bs_roots: 8 /misc emmc /dev/block/bootdevice/by-name/misc
[ 7.406167] bs_roots: 9 /firmware vfat /dev/block/bootdevice/by-name/modem
[ 7.406172] bs_roots: 10 /bt_firmware vfat /dev/block/bootdevice/by-name/bluetooth
[ 7.406177] bs_roots: 11 /dsp ext4 /dev/block/bootdevice/by-name/dsp
[ 7.406182] bs_roots: 12 /persist ext4 /dev/block/bootdevice/by-name/persist
[ 7.406187] bs_roots: 13 /boot/modem_fs1 emmc /dev/block/bootdevice/by-name/modemst1
[ 7.406191] bs_roots: 14 /boot/modem_fs2 emmc /dev/block/bootdevice/by-name/modemst2
[ 7.406195] bs_roots: 15 auto auto /devices/soc/a800000.ssusb/a800000.dwc3/xhci-hcd.0.auto/usb*
[ 7.406199] bs_roots: 16 /qns ext4 /dev/block/bootdevice/by-name/Qnovo
[ 7.406203] bs_roots: 17 /tmp ramdisk ramdisk
[ 7.406206] bs_roots:
[ 7.408585] MR: Mounting /cache ourselves
[ 7.412318] EXT4-fs (sda53): recovery complete
[ 7.412666] EXT4-fs (sda53): mounted filesystem with ordered data mode. Opts:
[ 7.413213] MR: fopen() failed -/cache/recovery/command (No such file or directory)
[ 7.413219] MR: Unmounting /cache
[ 7.413959] MR: Fail to get command from /cache/recovery/command, trying /misc
[ 7.414272] MR: Unknown wipe command
[ 7.414280] MR: Buffer is empty from /dev/block/bootdevice/by-name/misc with command 0
[ 7.417568] MR: TA_MASTER_RESET value = 0
[ 7.418475] init: Service 'exec 3 (/sbin/mr)' (pid 605) exited with status 0 waiting took 0.022997 se
conds
[ 7.418513] init: starting service 'exec 4 (/sbin/ffu)'...
[ 7.418846] init: SVC_EXEC pid 609 (uid 0 gid 0+0 context u:r:recovery:s0) started; waiting...
[ 7.419833] init: Service 'exec 4 (/sbin/ffu)' (pid 609) exited with status 255 waiting took 0.001316
seconds
------
One more update, I did a sanity check that that dd command is actually overwriting FOTAkernel. It doesn't look like it's working:
Code:
G8441:/data/local/tmp # dd if=/dev/block/bootdevice/by-name/FOTAKernel of=FOTAKernel-extracted.img
131072+0 records in
131072+0 records out
67108864 bytes transferred in 0.812 secs (82646384 bytes/sec)
G8441:/data/local/tmp # chown shell:shell FOTAKernel-extracted.img
G8441:/data/local/tmp # dd if=twrp-3.2.1-0-lilac-10-patchlevel-2018-05-05.img of=/dev/block/bootdevice/by-name/FOTAKernel
60128+0 records in
60128+0 records out
30785536 bytes transferred in 2.037 secs (15113174 bytes/sec)
G8441:/data/local/tmp # sync
G8441:/data/local/tmp # sync
=/dev/block/bootdevice/by-name/FOTAKernel of=FOTAKernel-extracted-2.img <
131072+0 records in
131072+0 records out
67108864 bytes transferred in 0.846 secs (79324898 bytes/sec)
And there's no `diff` on the device, so I pulled the files back to a laptop then:
Code:
$ diff FOTAKernel-extracted-2.img FOTAKernel-extracted.img
$ diff FOTAKernel-extracted.img twrp-3.2.1-0-lilac-10-patchlevel-2018-05-05.img
Binary files FOTAKernel-extracted.img and twrp-3.2.1-0-lilac-10-patchlevel-2018-05-05.img differ

@j4nn @pbarrette doing some more reading, I found some interesting details about booting to recovery stored on FOTAKernel here:
https://twrp.me/sony/sonyxperiaxz.html
https://twrp.me/sony/sonyxperiaz3compact.html
Looks like you really need a kernel that has the ramdisk extraction setup. So I'm guessing that once I figure out why dd isn''t working as I expected (see above) that I need to overwrite the main stock kernel with an alternative.

Yes, a dd extraction of the partition will be different than the TWRP image.
That's because the TWRP image is only ~35MB, while "dd" is extracting the entire 64MB partition.
So, if you do a visual diff on the files, you should see that what's actually different is the fact that the partition extraction is filled with zeros after the end of the TWRP image.
You're doing a "reboot recovery", but have you tried:
1 - Turn the phone off
2 - Press and hold [Vol-Down].
3 - Press and hold [Power].
4 - Release [Power] at power on.
5 - Release [Vol-Down] when you see an actual boot screen (after the bootloader unlocked screen).
I don't remember the "reboot recovery" command ever working right for me.
Edit to add: That's also a really old version of TWRP that you seem to be using.

pbarrette said:
Yes, a dd extraction of the partition will be different than the TWRP image.
That's because the TWRP image is only ~35MB, while "dd" is extracting the entire 64MB partition.
So, if you do a visual diff on the files, you should see that what's actually different is the fact that the partition extraction is filled with zeros after the end of the TWRP image.
You're doing a "reboot recovery", but have you tried:
1 - Turn the phone off
2 - Press and hold [Vol-Down].
3 - Press and hold [Power].
4 - Release [Power] at power on.
5 - Release [Vol-Down] when you see an actual boot screen (after the bootloader unlocked screen).
I don't remember the "reboot recovery" command ever working right for me.
Edit to add: That's also a really old version of TWRP that you seem to be using.
Click to expand...
Click to collapse
Hot damn. Thanks, I'm booted to twrp!
Note: i was using the older version for android 8 since I'm currently on the android 8 exploitable rom!

apexofservice said:
@j4nn @pbarrette doing some more reading, I found some interesting details about booting to recovery stored on FOTAKernel here:
https://twrp.me/sony/sonyxperiaxz.html
https://twrp.me/sony/sonyxperiaz3compact.html
Looks like you really need a kernel that has the ramdisk extraction setup. So I'm guessing that once I figure out why dd isn''t working as I expected (see above) that I need to overwrite the main stock kernel with an alternative.
Click to expand...
Click to collapse
XZ1 compact never needed the recovery with this extraction stuff. But according to
https://twrp.me/sony/sonyxperiaxzpremium.html
XZ Premium (which is also yoshino platform, the same as xz1c is) seems to need that - but I am not sure if it is still valid.
It might got fixed even in xzp case with some bootloader update to have it working the same as with other yoshino phones.
Sorry for my late answer, it's good you already have it working.
But I still wonder about that usb problem with fastboot - have you tried a different pc with different usb controller, preferably usb 2.0 type (not 3.0 one)?

j4nn said:
XZ1 compact never needed the recovery with this extraction stuff. But according to
https://twrp.me/sony/sonyxperiaxzpremium.html
XZ Premium (which is also yoshino platform, the same as xz1c is) seems to need that - but I am not sure if it is still valid.
It might got fixed even in xzp case with some bootloader update to have it working the same as with other yoshino phones.
Sorry for my late answer, it's good you already have it working.
But I still wonder about that usb problem with fastboot - have you tried a different pc with different usb controller, preferably usb 2.0 type (not 3.0 one)?
Click to expand...
Click to collapse
I haven't yet. Well, I have sorta. When I first ran into issues, I tried it with a different laptop, got the same result. Now that laptop was also a thinkpad (although a newer model) and was also running debian linux. I don't have any computers with Windows. I was going to reboot this laptop with usb3.0 kernel mod blacklisted and only using hci but I didn't get around to it yet (especially once I got twrp flashed and working, then I mainly wanted to get started actually using the phone i bought ). However, if it were a usb thing, wouldn't we expect that newflasher would fail too? Still, it is very curious about the fastboot thing, however, so I'm willing to keep playing with it.

@apexofservice, I am not sure if blacklisting usb3 drivers would help. Sometime there may be present multiple usb ports, some connected to usb 3.0 host controller, others just usb 2.0 controller.
Even if newflasher works, it is not that simple, that fastboot should work too.
Fastboot (including it's usb support) is implemented in UEFI bootloader, the ABL component of it (Android Boot Loader).
So usb stack is implemented by UEFI fw.
While newflasher uses flash mode, which is running XFL - a linux (bare bone android) kernel, running the lilo/loader userspace application. So there is in my opinion quite good usb stack implemented by linux kernel.
So it can easily be some incompatibility within UEFI usb stack implementation used with fastboot.

Data partition can’t format

I have a Chinese version of k20 pro, and a friend gave it to me because it could not be repaired. Bootloader has been unlocked and can enter fastboot and twrp recovery at present. But recovery shows
"primary block device ‘/dev/block/bootdevice/by-name/userdata’ for mount point ‘/data’ is not present!
Failed to mount ‘/data’(invalid argument)”
I tried format data and change file system in twrp, but it didn't work. I also tried fastboot flash userdata, and he displayed
"failed (remoteartition not found).
I also downloaded the official system and used fastboot to execute "flash_all.sh". Halfway through the execution, it displayed
"error:cannot load'./images/ system.img' :value too large for defined data type. flash system error”
Is there a way to solve it? I'm not in China, so I can't send it back to official repairs.
(I don’t have a windows pc to use it now) The previous fastboot operation was done using raspberry pi 4

xperiazu21 said:
I have a Chinese version of k20 pro, and a friend gave it to me because it could not be repaired. Bootloader has been unlocked and can enter fastboot and twrp recovery at present. But recovery shows
"primary block device ‘/dev/block/bootdevice/by-name/userdata’ for mount point ‘/data’ is not present!
Failed to mount ‘/data’(invalid argument)”
I tried format data and change file system in twrp, but it didn't work. I also tried fastboot flash userdata, and he displayed
"failed (remoteartition not found).
I also downloaded the official system and used fastboot to execute "flash_all.sh". Halfway through the execution, it displayed
"error:cannot load'./images/ system.img' :value too large for defined data type. flash system error”
Is there a way to solve it? I'm not in China, so I can't send it back to official repairs?.
(I don’t have a windows pc to use it now) The previous fastboot operation was done using raspberry pi 4?
Click to expand...
Click to collapse
what happens if
Fastboot erase userdata

[email protected] said:
what happens if
Fastboot erase userdata
Click to expand...
Click to collapse
Thanks in advance for your reply! After I tried it, he showed
"failed(remote: check device console.).“
If I erase other partitions, such as cache, it can be finished.
I also tried to extract userdata.img to flash from the official fastboot. Use fastboot flash userdata userdata.img, it displays
"failed(remote;partition not found)"

Try flashing from mi flash tool... From an windows pc. Do not choose lock option.
---------- Post added at 07:25 PM ---------- Previous post was at 06:55 PM ----------
Try this also
The data partition is sda31 for this device so
Go to recovery.. Terminal... Type Belo command
mke2fs -T ext4 /dev/block/sda31
tune2fs –L userdata /dev/sda31
Then reboot
Flash a fastboot image... System etc
If fastboot failed to flash system.img take the image to sdcard install image from recovery.
Tell me what happens.

[email protected] said:
Try flashing from mi flash tool... From an windows pc. Do not choose lock option.
---------- Post added at 07:25 PM ---------- Previous post was at 06:55 PM ----------
Try this also
The data partition is sda31 for this device so
Go to recovery.. Terminal... Type Belo command
mke2fs -T ext4 /dev/block/sda31
tune2fs –L userdata /dev/sda31
Then reboot
Flash a fastboot image... System etc
If fastboot failed to flash system.img take the image to sdcard install image from recovery.
Tell me what happens.
Click to expand...
Click to collapse
I will find windows pc to try miflash during the holiday!
I tried the command in the terminal, it showed
"the file /dev/block/sda31 does not exist and no size was specified".
I changed the recovery to orange fix, and used the file browser to view /dev/block, but I didn't see sda31:crying:

Show me the output of below command in orange fox terminal
fdisk -l
And also
fdisk /dev/sda
p

[email protected] said:
Show me the output of below command in orange fox terminal
fdisk -l
And also
fdisk /dev/sda
p
Click to expand...
Click to collapse
I tried the fdisk -l and fdisk /dev/sda commands, and the message in the picture was displayed.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
(Sorry I can't save the screenshot to the usb device)
-------Update-------
I tried to replace the recovery with wzsx150's twrp
and execute command “parted /dev/block/sda”
The GPT table seems to be damaged, can it be repaired?

Y.. After the last ss inside parted..
Type p enter
Show me the ss..
You have to recreate partition table tru parted

[email protected] said:
Y.. After the last ss inside parted..
Type p enter
Show me the ss..
You have to recreate partition table tru parted
Click to expand...
Click to collapse
I'm sorry for my bad English:crying:
I don't know what you mean very much, what should I do now?

Parted /dev/block/sda
Inside parted cmd prompt type
(parted) print
Show me the screen shot
Use orange fox latest recovery... F disk will work there

[email protected] said:
Show me the output of below command in orange fox terminal
fdisk -l
And also
fdisk /dev/sda
p
Click to expand...
Click to collapse
[email protected] said:
Parted /dev/block/sda
Inside parted cmd prompt type
(parted) print
Show me the screen shot
Use orange fox latest recovery... F disk will work there
Click to expand...
Click to collapse
Thank you for your detailed explanation！
I downloaded the latest version of orange fix recovery and executed parted command. The message is still the same as before.

Use fdisk in latest orange fox.
Check details first. Get partition table

[email protected] said:
Use fdisk in latest orange fox.
Check details first. Get partition table
Click to expand...
Click to collapse
I typed "fdisk /dev/block/sda”, and then typed “p” in the command, showing all the partitions.
The end sector of the userdata partition seems to be a problem?

Ok... See partition no 31 which is data partition has start and end address wrong. Thats the issue.
Just re create this partition... It will start working then.
Type fdisk /dev/sda
Type d to proceed to delete a partition
Type 31 to select the 31st partition and press enter
This will delete data partition.
Then create it

[email protected] said:
Ok... See partition no 31 which is data partition has start and end address wrong. Thats the issue.
Just re create this partition... It will start working then.
Type fdisk /dev/sda
Type d to proceed to delete a partition
Type 31 to select the 31st partition and press enter
This will delete data partition.
Then create it
Click to expand...
Click to collapse
I cannot use the /dev/sda path, I can only use the /dev/block/sda path
How should I delete partition 31? It has only 4 actions and no delete option

My mistake...
/dev/block/sda
This guide will help u
https://tldp.org/HOWTO/Partition/fdisk_partitioning.html
Btw hw r u taking screen shot of orange fox?
/ $ su
:/ # busybox fdisk /dev/block/sda
Note: sector size is 4096 (not 512)
Found valid GPT with protective MBR; using GPT
Command (m for help): p
Disk /dev/block/sda: 237158400 sectors, 704M
Logical sector size: 4096
Disk identifier (GUID): 6ca8833f-cde5-e7e6-50f2-77495c5b84a2
Partition table holds up to 32 entries
First usable sector is 6, last usable sector is 29644794
Number Start (sector) End (sector) Size Name
1 6 7 8192 switch
2 8 15 32768 ssd
3 16 23 32768 dbg
4 24 31 32768 bk01
5 32 63 128K bk02
6 64 127 256K bk03
7 128 255 512K bk04
8 256 383 512K keystore
9 384 511 512K frp
10 512 1023 2048K bk05
11 1024 2047 4096K misc
12 2048 3071 4096K vm-data
13 3072 4095 4096K bk06
14 4096 6143 8192K logfs
15 6144 8191 8192K bk07
16 8192 12287 16.0M oops
17 12288 16383 16.0M devinfo
18 16384 20479 16.0M oem_misc1
19 20480 24575 16.0M metadata
20 24576 32603 31.3M bk08
21 32604 40959 32.6M splash
22 40960 49151 32.0M bk09
23 49152 65535 64.0M persist
24 65536 81919 64.0M persistbak
25 81920 98303 64.0M logdump
26 98304 131071 128M minidump
27 131072 163839 128M rawdump
28 163840 180223 64.0M recovery
29 180224 245759 256M cache
30 245760 507903 1024M cust
31 507904 29644794 111G userdata
Command (m for help):
Given partition table for a correct device. Taken in my own device.

[email protected] said:
My mistake...
/dev/block/sda
This guide will help u
https://tldp.org/HOWTO/Partition/fdisk_partitioning.html
Btw hw r u taking screen shot of orange fox?
Click to expand...
Click to collapse
Use the volume down and power button, the photo will be stored in /tmp, copy the image to usb_otg.
Thank you very much, you saved this phone, I flashed it to miui eu rom, it works well!
In the end, I did not use fdisk to modify, but gdisk.
fdisk seems to be unable to perform too many operations on the gpt format. Using gdisk is similar to fdisk.
Thank you again, and google translate XD.

Now you help two person in future...
And then tell them to help two and so on recursively.
Also let me know gdisk binary details.. Where u got it...?

[email protected] said:
Now you help two person in future...
And then tell them to help two and so on recursively.
Also let me know gdisk binary details.. Where u got it...?
Click to expand...
Click to collapse
When I was searching for how to use fdisk to delete partitions, I found this discussion. There are partition tools like gdisk and fdisk available for download
https://forum.xda-developers.com/mi-9t/help/mi-9t-hard-brick-miui11-test-t3975347/page6/

i have bootloader unlocked but cant install fastboot rom via mi flash
i have k2o pro device
i have try to install fastboot rom manually but i got error coundnt read sparse file or now i stuck on erase boot
any help!!!!
bootloader unlock
cant it be a hardware promblem