Ok, 20 is a great enough number to say that it is a persistent error, which I faced me too.
Finally, I resolved to develop this script - it is delivered like a patch, but it also works like a script - please read the description before using it.
If also this script and the trick of starting a single fastboot transaction before the smartphone reaches the fastboot mode in such a way the transaction happens after the waiting for device message fail, then we are in front of an issue that I never faced before.
head -n12 flash-config.sh
will show you the operations that flash.sh is going to do. The one which cannot complete in your case is this one:
fastboot flash userdata sailfish.img001
Start it while the smartphone is connected to the USB but not yet arrived to the fastboot mode which is presented with the blue led on the right top of the phone (in X10 II, at least).
In my case, before everything, I run the script with 2 as parameter for setting the USB v2.0 mode, then I manually flash the partitions but you can try the flash.sh again. If all above works, then you have to do also these ones unless you successfully used flash.sh:
fastboot flash oem_a *_v12b_seine.img
fastboot flash oem_b *_v12b_seine.img
Keep in mind that your Android version should be 11 or a 10. If it is a 12 or 13, then you need to downgrade your smartphone before initiating the flashing procedure. About Android version and the downgrading procedure you will find more information here:
This guide also contains a section about USB problems in flashing the smartphone.
You may fail to achieve your goal using that script and my suggestions but for sure this comment:
will not drive you anywhere further.
Notice
In the Chum and StoreMan installation scripts, these two lines attracted my attention because they are related to a problem similar to your, as explained into the related links.
export LC_ALL=POSIX # For details see https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_02
export POSIXLY_CORRECT=1 # Can have side-effects, see e.g., https://github.com/Olf0/sfos-upgrade/issues/73
# Ultimately this ensures an almost consistent behaviour across shell implementations.
Unfortunately in my case exporting POSIXLY_CORRECT=1 or 0 mess-up things rather than fixing anything. But in your case it might be different and therefore it is worth a try. If this helps you, please inform me.
Before set and export this environment variable do this:
echo ${POSIXLY_CORRECT:-not set}
Possibly a general solution can be checking if it is zero and then set to one but doing nothing if that variable is not set like in my case.
UPDATE
Checking the type of the image, there are two kind of them
- sparse
- data / boot
The second ones are better written with flash:raw while the others requires flash without raw because they are sparse image (image files with holes).
file dtbo.img hybris-boot.img sailfish.img001 SW_binaries_for_Xperia_Android_10.0.7.1_r1_v12b_seine.img
dtbo.img: data
hybris-boot.img: Android bootimg, kernel (0x8000), ramdisk (0x2000000), page size: 4096, cmdline (lpm_levels.sleep_disabled=1 service_locator.enable=1 msm_drm.blhack_dsi_display0=dsi_panel_somc_seine_cmd:config0 androidboot.s)
sailfish.img001: Android sparse image, version: 1.0, Total of 426485 4096-byte output blocks in 1468 input chunks.
SW_binaries_for_Xperia_Android_10.0.7.1_r1_v12b_seine.img: Android sparse image, version: 1.0, Total of 102400 4096-byte output blocks in 45 input chunks.