An error pops up when flashing the Sailfish OS to Xperia 10 III (using MacBook Pro M1). Screenshot attached. What should I do?
Retry again and again, at one certain point it will succeed. Hopfully.
I tried that like 20 times 
Sorry I can’t help but with a small tip. Ignore robang74, He is not here to help anyone.
4 Likes
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.
I see you were doing the steps manually. The guide says to use the flash.sh script for linux and osx.
Did you try just using the flash.sh file in the Sailfish_OS-Jolla-4.5.0.18-xqbt52-1.0.1.18 directory?
1 Like
No I did not do that manually. I used the script and it performed those commands automatically.
1 Like
Ok, then it sounds like a customer support issue. https://jolla.zendesk.com/hc/en-us I think.
1 Like
I did a quick look for related erros on expria devices which, for instance, led to [Discovery] boot.img exceeds max size · Issue #305 · sonyxperiadev/bug_tracker · GitHub
It might help to try different cables and check if you are using USB 2 vs 3 (which is a known issue). In short, try USB2 if you can with a cable you know is good.
or try to find a Windows pc.
or use an USB hub with a USB2 jack.
My laptop only has USB3. So I put an old USB2 hub in between. This worked (although I’m not sure whether it caused the problems. USB3 did cause problems with earlier Xperia models.)
2 Likes
Some time ago I read in this forum that some Sony’s have problems with USB3 when booting into flashing mode, this comes from Sony’s firmware, which cannot handle USB3, but only USB2. I myself have only old Xperia 10, and this is also present here and USB3 flashing doesn’t work but flashing via USB2 does without any problem. I use a small USB powered hub ‘aqprox appHT7B’, < 10€.
I used windows PC and now it is okay. SFOS flashed okay, but the cellular is now working cannot make calls nor the internet is working
Try if disabling the other SIM slot makes a difference.
I had to activate the SIM. Card should be inside before booting
1 Like
SIM cards and/or memory cards must be inserted properly on booting time.
If inserted later into the running system, no warranty for working and also risk to damage something.
@BIRINYI , read my Quick First Setup Guide to learn how to deal with the SIM also on the dual-SIM smartphones… 
Hi,
I’ve had the exact same problem on Arch Linux when trying to flash 2 different XPeria 10III.
Running the flash tool multiple times, changing cable, usb-port… nothing helped.
Just a node: I wasn’t able to use the version of fastboot that shipped with Arch, as it reproducibly segfaulted during flash (known bug). So I manually downloaded version ‘34.0.4-10411341’ after which I ran into this problem.
The solution for me was, to edit line 431 in flash.sh (to make fastboot split the image into smaller sparse files) by adding ‘-S 7000000’, like so:
$ diff flash.sh.broken flash.sh
431c431
< print_and_run "$FASTBOOTCMD" flash "$partition" "$b"
---
> print_and_run "$FASTBOOTCMD" -S 7000000 flash "$partition" "$b"
This will of course change the checksum, so you’ll need to run with…
flash.sh --force