issues with fastboot

[apexofservice]

Just got a used xz1 compact. I've been rooting and flashing android phones for years, so I'm not a total noob. Nevertheless, I find myself a bit stuck on an issue I've never experienced before.

So, first step to me was to unlock the bootloader so that i can flash twrp and the unofficial lineage 16 from modpunk. So I do the usual thing of getting the code from the sony website, opening the dev-settings in the stock android and clicking "allow unlock", rebooting to fastboot mode and then:

$ fastboot oem unlock 0xCODEHERE

Well, so I didn't get what I expected. Instead of a success message, I got a message that said "command failed". But then, on a subsequent try, I got the message "already unlocked". Then, I tried a reboot, and I see a warning screen saying "device cannot be checked for for corruption, please lock bootloader". Then it enters the Xperia splash screen and never progresses. Well, that's not too big of an issue since I don't really want the stock ROM anyway. So I go ahead and try to flash twrp (modpunk's version for xz1 compact) and I get:

$ fastboot flash -v recovery twrp-3.3.1-0-lilac-pie-5.img 
fastboot: verbose: target didn't report max-download-size
Sending 'recovery' (34548 KB)                      FAILED (remote: 'unknown command')
fastboot: error: Command failed

So that's a bit discouraging. I also tried to see what I could find with "fastboot getvar all", and I was surprised that I couldn't even get any debugging info. The `devices` command seems normal, tho:

$ fastboot devices
XXXXXXXXX	fastboot
$ fastboot getvar all
getvar:all                                         FAILED (remote: 'GetVar Variable Not found')
Finished. Total time: 0.002s

Also related, I tried the sony flashtool, which I'm already familiar with because my old phone is a Z3 Compact (see, not my first rodeo). When I try to connect in fastboot mode with flashtool, the flashtool menu says "device connected in fastboot mode" followed immediately by "device disconnected". I notice that in the stderr from flashtool there's a message from libusb which is associated:

libusb_get_string_descriptor_ascii : I/O Errors

So, that's not encouraging. So, I wonder if the unlocking command ended up failing in a partially done way, leaving things broken. Let me know if you have ideas on what I might try next. One other note, I'm using the same laptop and usb ports that have worked in the past for flashing my z3 compact. The cable is a bit of an unknown though. I'm using the usb->usbc cable that came with the phone. But I've also just tried some of other usb cables I have around the house with an adapter for usbc.

A heads up, I'm on linux with no Windows machine available. I'm technically competent and I'd prefer detailed hypotheses to "try x". But I'm all ears. Anyone have ideas?

-----
Update:

I realized that there was a chance at least some of my issue was due to usb-c support in my kernel. So I built a 5.0 kernel and rebooted. The nice thing is that now `fastboot getvar all` is working. That's very encouraging. Here are the details:

(bootloader) hw-revision:20001
(bootloader) unlocked:yes
(bootloader) off-mode-charge:0
(bootloader) charger-screen-enabled:0
(bootloader) battery-soc-ok:yes
(bootloader) battery-voltage:4269
(bootloader) version-baseband:1308-8921_47.2.A.10.107
(bootloader) version-bootloader:1306-5035_X_Boot_MSM8998_LA2.0_P_114
(bootloader) erase-block-size: 0x1000
(bootloader) logical-block-size: 0x1000
(bootloader) variant:MSM UFS
(bootloader) partition-type:xblbak:raw
(bootloader) partition-size:xblbak: 0x3F5000
(bootloader) partition-type:xbl:raw
(bootloader) partition-size:xbl: 0x3F5000
(bootloader) partition-type:userdata:ext4
(bootloader) partition-size:userdata: 0x587D76000
(bootloader) partition-type:system:ext4
(bootloader) partition-size:system: 0x138800000
(bootloader) partition-type:vendor:raw
(bootloader) partition-size:vendor: 0x60000000
(bootloader) partition-type:oem:raw
(bootloader) partition-size:oem: 0x19000000
(bootloader) partition-type:rdimage:raw
(bootloader) partition-size:rdimage: 0x2000000
(bootloader) partition-type:fsmetadata:raw
(bootloader) partition-size:fsmetadata: 0x101000
(bootloader) partition-type:Qnovo:raw
(bootloader) partition-size:Qnovo: 0x1800000
(bootloader) partition-type:diag:raw
(bootloader) partition-size:diag: 0x2000000
(bootloader) partition-type:appslog:raw
(bootloader) partition-size:appslog: 0x1000000
(bootloader) partition-type:vbmeta:raw
(bootloader) partition-size:vbmeta: 0x10000
(bootloader) partition-type:frp:raw
(bootloader) partition-size:frp: 0x80000
(bootloader) partition-type:keystore:raw
(bootloader) partition-size:keystore: 0x80000
(bootloader) partition-type:misc:raw
(bootloader) partition-size:misc: 0x100000
(bootloader) partition-type:cache:ext4
(bootloader) partition-size:cache: 0x17C00000
(bootloader) partition-type:ssd:raw
(bootloader) partition-size:ssd: 0x2000
(bootloader) partition-type:fsc:raw
(bootloader) partition-size:fsc: 0x1000
(bootloader) partition-type:modemst2:raw
(bootloader) partition-size:modemst2: 0x200000
(bootloader) partition-type:modemst1:raw
(bootloader) partition-size:modemst1: 0x200000
(bootloader) partition-type:ddr:raw
(bootloader) partition-size:ddr: 0x100000
(bootloader) partition-type:FOTAKernel:raw
(bootloader) partition-size:FOTAKernel: 0x4000000
(bootloader) partition-type:logfs:raw
(bootloader) partition-size:logfs: 0x800000
(bootloader) partition-type:toolsfv:raw
(bootloader) partition-size:toolsfv: 0x100000
(bootloader) partition-type:limits:raw
(bootloader) partition-size:limits: 0x1000
(bootloader) partition-type:splash:raw
(bootloader) partition-size:splash: 0x20A4000
(bootloader) partition-type:dpo:raw
(bootloader) partition-size:dpo: 0x1000
(bootloader) partition-type:msadp:raw
(bootloader) partition-size:msadp: 0x40000
(bootloader) partition-type:apdp:raw
(bootloader) partition-size:apdp: 0x40000
(bootloader) partition-type:bluetooth:raw
(bootloader) partition-size:bluetooth: 0x100000
(bootloader) partition-type:boot:raw
(bootloader) partition-size:boot: 0x4000000
(bootloader) partition-type:dsp:raw
(bootloader) partition-size:dsp: 0x1000000
(bootloader) partition-type:modem:raw
(bootloader) partition-size:modem: 0x6E00000
(bootloader) partition-type:sec:raw
(bootloader) partition-size:sec: 0x4000
(bootloader) partition-type:fsg:raw
(bootloader) partition-size:fsg: 0x180000
(bootloader) partition-type:persist:raw
(bootloader) partition-size:persist: 0x2000000
(bootloader) partition-type:xflkeystorebak:raw
(bootloader) partition-size:xflkeystorebak: 0x20000
(bootloader) partition-type:xflkeystore:raw
(bootloader) partition-size:xflkeystore: 0x20000
(bootloader) partition-type:tzxflbak:raw
(bootloader) partition-size:tzxflbak: 0x80000
(bootloader) partition-type:tzxfl:raw
(bootloader) partition-size:tzxfl: 0x80000
(bootloader) partition-type:tzxflattestbak:raw
(bootloader) partition-size:tzxflattestbak: 0x80000
(bootloader) partition-type:tzxflattest:raw
(bootloader) partition-size:tzxflattest: 0x80000
(bootloader) partition-type:xflbak:raw
(bootloader) partition-size:xflbak: 0x1E00000
(bootloader) partition-type:xfl:raw
(bootloader) partition-size:xfl: 0x1E00000
(bootloader) partition-type:storsecbak:raw
(bootloader) partition-size:storsecbak: 0x20000
(bootloader) partition-type:storsec:raw
(bootloader) partition-size:storsec: 0x20000
(bootloader) partition-type:devcfgbak:raw
(bootloader) partition-size:devcfgbak: 0x20000
(bootloader) partition-type:devcfg:raw
(bootloader) partition-size:devcfg: 0x20000
(bootloader) partition-type:sti:raw
(bootloader) partition-size:sti: 0x200000
(bootloader) partition-type:cmnlib64bak:raw
(bootloader) partition-size:cmnlib64bak: 0x80000
(bootloader) partition-type:cmnlib64:raw
(bootloader) partition-size:cmnlib64: 0x80000
(bootloader) partition-type:cmnlibbak:raw
(bootloader) partition-size:cmnlibbak: 0x80000
(bootloader) partition-type:cmnlib:raw
(bootloader) partition-size:cmnlib: 0x80000
(bootloader) partition-type:keymasterbak:raw
(bootloader) partition-size:keymasterbak: 0x80000
(bootloader) partition-type:keymaster:raw
(bootloader) partition-size:keymaster: 0x80000
(bootloader) partition-type:devinfo:raw
(bootloader) partition-size:devinfo: 0x1000
(bootloader) partition-type:ablbak:raw
(bootloader) partition-size:ablbak: 0x180000
(bootloader) partition-type:abl:raw
(bootloader) partition-size:abl: 0x180000
(bootloader) partition-type:pmicbak:raw
(bootloader) partition-size:pmicbak: 0x80000
(bootloader) partition-type:pmic:raw
(bootloader) partition-size:pmic: 0x80000
(bootloader) partition-type:hypbak:raw
(bootloader) partition-size:hypbak: 0x80000
(bootloader) partition-type:hyp:raw
(bootloader) partition-size:hyp: 0x80000
(bootloader) partition-type:tzbak:raw
(bootloader) partition-size:tzbak: 0x200000
(bootloader) partition-type:tz:raw
(bootloader) partition-size:tz: 0x200000
(bootloader) partition-type:rpmbak:raw
(bootloader) partition-size:rpmbak: 0x80000
(bootloader) partition-type:rpm:raw
(bootloader) partition-size:rpm: 0x80000
(bootloader) partition-type:LTALabel:raw
(bootloader) partition-size:LTALabel: 0x1000000
(bootloader) partition-type:TA:raw
(bootloader) partition-size:TA: 0x200000
(bootloader) secure:no
(bootloader) serialno:XXXXXXXX
(bootloader) serial:1a322f75
(bootloader) product:G8441
(bootloader) max-download-size:536870912
(bootloader) kernel:uefi

So that seems like I did succeed at the unlocking. Now, I still can't seem to flash twrp:

$ fastboot  -v flash recovery twrp-3.3.1-0-lilac-pie-5.img 
fastboot: verbose: target reported max download size of 536870912 bytes
Sending 'recovery' (34548 KB)                      FAILED (Status read failed (No such device))
fastboot: error: Command failed

But things look normalish otherwise (max download size actually reported). And I still get libusb I/O error messages from flashtool when I tried to connect the device in fastboot mode while running flashtool. So, now my question has really morphed into help with this specific error. Why would it say "no such device"?

---
One more note: tailing /var/log/kern.log while doing the above (trying to flash recovery with fastboot), I can see that the device does reconnect. So I'm assuming that the "no such device" message is due to the disconnection. It's not clear to me if my troubles are due to kernel version, libusb version, cables/cable-types or something else. Looking forward to any advice.

 

[apexofservice]

Update (a second state acheived)

I managed to get the phone into some other mode (I guess what was called "flash mode" in other xperia devices). The indicator here is that the led is green instead of blue (fastboot). Well, it still seems to be some sort of fastboot mode, although quite a bit is different. For one thing, the device doesn't send its serial. In /var/log/kern.log I see:

Sep 22 21:53:11 kernel: [25251.575770] usb 1-1: Product: Android
Sep 22 21:53:11 kernel: [25251.575772] usb 1-1: Manufacturer: Sony
Sep 22 21:56:50 kernel: [25470.553359] usb 1-1: USB disconnect, device number 40
Sep 22 21:56:57kernel: [25477.008071] usb 1-1: new high-speed USB device number 41 using xhci_hcd
Sep 22 21:56:57 kernel: [25477.158020] usb 1-1: New USB device found, idVendor=0fce, idProduct=b00b, bcdDevice= 4.04
Sep 22 21:56:57 kernel: [25477.158025] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0

Then, fastboot itself says that the serial is a bunch of question marks:

$ fastboot devices
????????????	fastboot

Most interesting, now I get farther along the 'flash' command, instead of failing on 'Sending' with no such device, I see that the sending is "OKAY", but then the command to write fails as "unauthenticated".

$ fastboot  flash recovery recovery.img 
Sending 'recovery' (34548 KB)                      OKAY [  1.314s]
Writing 'recovery'                                 FAILED (remote: 'Command not authenticated')
fastboot: error: Command failed

Also, now `getvar all` has different info:

fastboot getvar all
(bootloader) version:0.4-SONY-0.31
(bootloader) max-download-size:104857600
(bootloader) Version-sony:0.31
(bootloader) Loader-version:XFL-MSM8998-N-47
(bootloader) serialno:YYYYYYYY
(bootloader) version-bootloader:1306-5035_X_Boot_MSM8998_LA2.0_P_114
(bootloader) version-baseband:1308-8921_47.2.A.10.107
(bootloader) product:G8441
(bootloader) Phone-id:0000:XXXXXXXX
(bootloader) Rooting-status:ROOTED
(bootloader) Device-id:EDF6B4C3
(bootloader) Platform-id:2005E0E1
(bootloader) Frp-partition:frp
(bootloader) secure:no
(bootloader) Sector-size:4096
(bootloader) Ufs-info:SKhynix,H28U62301AMR,D003
(bootloader) Keystore-counter:1
(bootloader) Sake-root:D159
(bootloader) Default-security:eek:N
(bootloader) S1-root:S1_Root_e69c
(bootloader) Security-state:162509AE6B4B54D487F2496DDC4D4B6C6747A73B
(bootloader) USB-version:0x0200
(bootloader) slot-count:0
(bootloader) slot-suffixes:<empty>
(bootloader) current-slot:<empty>
all: 
Finished. Total time: 0.107s

Also, in this mode, instead of just hanging if I retry the `oem unlock` command, it promptly replies that it's already unlocked.

$ fastboot oem unlock 0xBADHEAD
                                                   FAILED (remote: 'Bootloader already unlocked')
fastboot: error: Command failed

These seem like important clues. I'm looking for any tips parsing them

 

[bookworth]

Rooting is not worth it anymore.
With any flashing there is the risk to damage the memory chips (because, you know, manufacturing defects, wearing out, etc). With old device the risk is even higher - and you won't have warranty anymore.

What I am saying is that you may have a (now) defective device.

 

[apexofservice]

Rooting is not worth it anymore.
With any flashing there is the risk to damage the memory chips (because, you know, manufacturing defects, wearing out, etc). With old device the risk is even higher - and you won't have warranty anymore.

What I am saying is that you may have a (now) defective device.

Sure. It's possible that the device is defective. The purpose of this thread is to determine that. Do you have any experience which is relevant?

This is not about "rooting" in the traditional sense of owning uid 0 in Android. This is about installing a system which I'm comfortable using.

 

[bookworth]

Sure. It's possible that the device is defective. The purpose of this thread is to determine that. Do you have any experience which is relevant?

This is not about "rooting" in the traditional sense of owning uid 0 in Android. This is about installing a system which I'm comfortable using.

I think you can obviously see that the device is old and both the offial and unofficial support has faded. It is just like flashing a Nokia E6 from 2011 today - noone cares. I know because I just did the Nokia thing.

 

[j4nn]

@apexofservice, for flashing twrp image you need fastboot mode - blue led light (vol+ held while connecting to usb).
The other mode - green led light - is flash mode (Sony Service Mode) - there you can flash only sony signed stock firmware (like with newflasher all those .sin files).
I guess you troubles are most likely caused by some old version of 'fastboot' utility in your linux distro - are you using the version you've installed for modding your previous sony phone?
Or did you follow the sony unlocking guide and really installed the recommended fastboot utility version (as part of some android devel pack)?
To rule out flash error, you may try to just boot twrp without flashing it:

fastboot reboot bootloader
fastboot boot twrp.img

I wonder why so many people just unlock the phone without reading first?
You might have noticed, there is a drm keys backup method and do that first before unlocking...

 

[apexofservice]

@apexofservice, for flashing twrp image you need fastboot mode - blue led light (vol+ held while connecting to usb).
The other mode - green led light - is flash mode (Sony Service Mode) - there you can flash only sony signed stock firmware (like with newflasher all those .sin files).
I guess you troubles are most likely caused by some old version of 'fastboot' utility in your linux distro - are you using the version you've installed for modding your previous sony phone?
Or did you follow the sony unlocking guide and really installed the recommended fastboot utility version (as part of some android devel pack)?
To rule out flash error, you may try to just boot twrp without flashing it:

fastboot reboot bootloader
fastboot boot twrp.img

I wonder why so many people just unlock the phone without reading first?
You might have noticed, there is a drm keys backup method and do that first before unlocking...

@j4nn: thanks so much for picking up the conversation. I realized what you said about green vs blue led and fastboot vs Sony Service mode sometime after my last post. But I didn't want to keep updating and just talking to myself so I held off. Still it's interesting that sony service mode is clearly based at least partially on the fastboot protocol.

In terms of which fastboot binary, I started by using the one I had installed from previous work with my z3c, that one is:

fastboot version 28.0.1-4986621

It was new enough not to have the -i $vendor_id option which is quoted in a bunch of guides for xperia stuff, and that's one of the things which lead me to try upgrading fastboot. Nowadays, it turns out, you can get the platform-tools without downloading the Sdk. So that download was quite convenient and I downloaded this version:

$ ./platform-tools/fastboot --version
fastboot version 29.0.4-5871666

I believe that's the latest fastboot, but let me know if it's not and if I should try to find something more recent. Actually, regarding fastboot, I ended up turning up the source code repo and found the README quite fascinating. I actually started using pyUSB to make a python version of fastboot, but that's a bit of an aside. In any case, I guess I could just compile fastboot from source. However, I suspect that the fastboot version isn't actually my issue.

Regarding booting from twrp using fastboot: Alas, that fails too. And, interestingly (perhaps), it fails in a similar way to the flash command. The phone seems to restart during or after the data send part:

./fastboot boot twrp-3.3.1-0-lilac-pie-5.img 
Sending 'boot.img' (34548 KB)                      FAILED (Write to device failed (Cannot send after transport endpoint shutdown))
fastboot: error: Command failed

So then, given that the Green LED is Sony Mode, I thought maybe I should try to use FlashTool to try to reflash a working ROM/boot/kernel. So, I downloaded a stock ROM (same major version, Android 9 in my case), and then used the bundle command to prepare an FTF package.

Unfortunately, the version of FlashTool that I have doesnt' seem to be able to recognize the "flash mode" (green LED) that this phone provides. After preparing the firmware for flashing, it just says "phone connected with usb debugging disabled" when I connect it with Green LED. So, I figured that I needed to upgrade FlashTool. I found the lastest FlashTool and then tried to run it. But the jvm that comes with it seems to have been linked dynamically against a newer GLIBC than the one I have on this distro, so I started compiling a newer GLIBC into /opt but haven't gotten any farther before it was time to go work and set this aside for a while.
In terms of why I went straight to bootloader unlock instead of doing the firmware exploit to backup the TA keys, the main reason is as follows. The first is that I went through that exercise twice with my Z3C (I had two Z3Cs over the last 4 years), and it never ended up being useful. I never wanted to go back to stock, I never ended up caring about the DRM keys on the TA partition. So, I didn't really want to go through a bunch of hoops just to backup some keys that at this point it's clear that I'm not going to be using---I just wanted to get to the business of getting lineage up.

Please do post any further ideas or suggestions. I'd love any advice. Thanks in advance!

 

[j4nn]

@apexofservice, instead of flashtool, just use newflasher to try to flash stock fw.
In linux you can ignore the pre-built binaries and just compile from source.
You may ignore even the prepared makefile and just use
gcc -o newflasher newflasher.c -lz -lexpat -ggdb
in order to use your system libs instead of those bundled.
Just do not use -O2 as that seams to cause flashtool segfault if compiled with -O2 with some recent gcc versions (there is probably a bug somewhere), -O0 resolves the segfault if it happens.

 

[j4nn]

@apexofservice, xz1c sony flash mode init script contains this

    # Increase min_free_kbytes to reduce risk of getting out of memory when doing USB read.
    # The value 56766 was created by adding 12*4096 to the default value of 7614. I.e. we
    # add 12 4MB buffers and this seems to be big enough for our use case.
    write /proc/sys/vm/min_free_kbytes 56766

Maybe it is related also to your linux setup?
Could you test

echo 56766 > /proc/sys/vm/min_free_kbytes

before testing fastboot or newflasher?

 

[apexofservice]

Last update for now. I upgraded glibc and got to try out the lastest FlashTool. It's very cool that they've got XperiFirm integrated now. However, my situation is unchanged. When I go ServiceMode (Green LED), FlashTool says "Device connected with usb debugging disabled". When I connect with fastboot mode (Blue LED), i see a libusb error in stderr which says "libusb_get_string_descriptor_ascii : I/O Errors".

So, I guess I've tried all the tools now, and the device really is responding surprisingly to commands, it seems. I think I'm down to USB ports/cables. Unless people have other ideas.

 

[apexofservice]

Just saw your posts. Thanks for the quick reply.

@apexofservice, xz1c sony flash mode init script contains this

    # Increase min_free_kbytes to reduce risk of getting out of memory when doing USB read.
    # The value 56766 was created by adding 12*4096 to the default value of 7614. I.e. we
    # add 12 4MB buffers and this seems to be big enough for our use case.
    write /proc/sys/vm/min_free_kbytes 56766

Maybe it is related also to your linux setup?
Could you test

echo 56766 > /proc/sys/vm/min_free_kbytes

before testing fastboot or newflasher?

FWIW, my system currently has 67584, so technically 56766 is a *decrease*. In any case, I tried it. Unfortunately, same output as previous:

./platform-tools/fastboot flash recovery twrp-3.3.1-0-lilac-pie-5.img 
Sending 'recovery' (34548 KB)                      FAILED (remote: 'unknown command')
fastboot: error: Command failed

Btw, where are you reading the source of that sony init script from?

 

[apexofservice]

@apexofservice, instead of flashtool, just use newflasher to try to flash stock fw.
In linux you can ignore the pre-built binaries and just compile from source.
You may ignore even the prepared makefile and just use
gcc -o newflasher newflasher.c -lz -lexpat -ggdb
in order to use your system libs instead of those bundled.
Just do not use -O2 as that seams to cause flashtool segfault if compiled with -O2 with some recent gcc versions (there is probably a bug somewhere), -O0 resolves the segfault if it happens.

Cool, I actually did try newflasher already. I had compiled it from source (I had to change the source minimally because it has a hard-coded device id). After I changed that (to 0x0dde), I built it with `make`. I recompiled using your suggested `gcc` invocation and alas, same error as what I saw last time I tried it.

$ ./newflasher 
--------------------------------------------------------
            newflasher v18 by Munjeni @ 2017/2019           
--------------------------------------------------------

Determining available free space:

  Available space to caller    = 114642 MB
  Total space on current drive = 471964 MB
  Free space on drive          = 138685 MB
found device with vid:0x0fce pid:0x0dde.

Optional step! Type 'y' and press ENTER if you want dump trim area, or type 'n' and press ENTER to skip.
Do in mind this doesn't dump drm key since sake authentifiction is need for that!
n
 - Error, no DATA reply!

End. You can disconnect your device when you close newflasher

I read in the fastboot README that that DATA reply is what's supposed to happen when the device reports that it's ready to read after and OKAY.

In fact, it was pretty easy to add the line `printf("%s\n", tmp_reply);" to the source code right after the line which is printing
"no DATA reply" and then I recompile and see:

 - Error, no DATA reply!
FAILunknown command

So that's the same "unknown command" message that I'm seeing from the fastboot tool too. Shucks.

 

[j4nn]

@apexofservice, your change of "hardcoded" device id does not make sense. The original device id in newflasher is all right.
Changing it to 0x0dde means you are trying to use newflasher in fastboot mode (i.e. idVendor=0fce, idProduct=0dde) which is indicated by blue led light. That will not work.
You need to use flash mode (green led light: idVendor=0fce, idProduct=b00b) with newflasher - no change in source needed.

 

[j4nn]

In terms of why I went straight to bootloader unlock instead of doing the firmware exploit to backup the TA keys, the main reason is as follows. The first is that I went through that exercise twice with my Z3C (I had two Z3Cs over the last 4 years), and it never ended up being useful. I never wanted to go back to stock, I never ended up caring about the DRM keys on the TA partition. So, I didn't really want to go through a bunch of hoops just to backup some keys that at this point it's clear that I'm not going to be using---I just wanted to get to the business of getting lineage up.

You should know that even LOS16 is depending on stock heavily - my (a bit outdated) source build tree contains 467MB of stock fw proprietary binary blobs. Those blobs might still contain functions that depend on drm, like for example stock camera.

Another discussion about this topic with interesting links is in this thread:

@Didgesteve, that "no one else seems to have noticed" - a rather big assumption of yours. There are many users complaining about xzp/xz1/xz1c camera quality in general.
But just with regard to oreo vs pie, read the xzp thread from here: post#27, particularly post#30 contains very interesting internal stuff.
I would like to believe sony stopped conditioning camera with keeping bootloader locked with pie but somehow I am not sure about that at all considering all the circumstances and my linked camera quality comparison test.
Thanks for your advice, luckily I do not need janjan's kernels as I've implemented the TA backup exploit, so both my phones can have drm keys restored (in fact one of them is still locked on purpose).
I (and anybody who saved TA-unlocked.img together with TA-locked.img) can switch easily between "drm keys restored" and "drm keys lost" states for testing/comparisons.

 

[apexofservice]

@apexofservice, for flashing twrp image you need fastboot mode - blue led light (vol+ held while connecting to usb).
The other mode - green led light - is flash mode (Sony Service Mode) - there you can flash only sony signed stock firmware (like with newflasher all those .sin files).
I guess you troubles are most likely caused by some old version of 'fastboot' utility in your linux distro - are you using the version you've installed for modding your previous sony phone?
Or did you follow the sony unlocking guide and really installed the recommended fastboot utility version (as part of some android devel pack)?
To rule out flash error, you may try to just boot twrp without flashing it:

fastboot reboot bootloader
fastboot boot twrp.img

I wonder why so many people just unlock the phone without reading first?
You might have noticed, there is a drm keys backup method and do that first before unlocking...

Good news here is that I managed to finally properly use newflasher to flash a stock ROM (android 9) and boot into it. Hooray. Bad news is that I still get the same behavior as reported above when I try to flash twrp. As above, I can't even boot into it with `fastboot boot twrp.img`. Since I'm really not interested in using the stock ROM, I'd love advice on what I may need to try next in order to get a custom recovery working (and eventually, obviously, a custom ROM).

 

[R3xXDA]

Had very similar issues - could only get to fastboot devices. Nothing else worked. Then I read that connecting through USB hub could work. Now fastboot getvar all works as well, managed to unlock the bootloader and flash TWRP...

 

[hockeymikey]

Rooting is not worth it anymore.
With any flashing there is the risk to damage the memory chips (because, you know, manufacturing defects, wearing out, etc). With old device the risk is even higher - and you won't have warranty anymore.
What I am saying is that you may have a (now) defective device.

Go take this garbage elsewhere, rooting and custom roms are very much worth it unless you like a crappy bloated stock rom. The devices are not defective nor is there any risk really as long as you're able to read. Way to waste the OP's time too and mine.

Good news here is that I managed to finally properly use newflasher to flash a stock ROM (android 9) and boot into it. Hooray. Bad news is that I still get the same behavior as reported above when I try to flash twrp. As above, I can't even boot into it with `fastboot boot twrp.img`. Since I'm really not interested in using the stock ROM, I'd love advice on what I may need to try next in order to get a custom recovery working (and eventually, obviously, a custom ROM).

Still having issues or did you figure it out?

 

[ernstlustig]

Same for me after flashing the firmware. Issue solved.

I got the latest TWRP here: https://forum.xda-developers.com/xp...t/recovery-twrp-3-1-1-stock-security-t3706704
Then I activated flash mode. (Phone off, volume down, then connect USB. The green LED is lit, otherwise black screen.)

fastboot reboot-bootloader
fastboot boot twrp-3.xxx.img

I Copied the TWRP image to the phone, then I used TWRP to install the TWRP image. (There is an option to install ZIP, which is default, or image.)

 

[hom3rsimpson]

Had very similar issues - could only get to fastboot devices. Nothing else worked. Then I read that connecting through USB hub could work. Now fastboot getvar all works as well, managed to unlock the bootloader and flash TWRP...

Using a USB hub was also the fix for me on an Xperia XA2 when flashing AOSP 9.0.