I sense a #market opportunity for disabled Telekom/T-Mobile SIM cards .
Just an idea that came up, I always intially install/deploy my own smartish phones after buying them without a sim card at all, so initialisation/provisioning at the very beginning without any mobile provider whatsoever. maybe that gives the phone thereafter a different approach or channel for updates, more like vanilla basic manufacturerer (fairphone here) update channel, instead of maybe a more customized or reviewed or delayed update channel when using different mobile/sim providers during an initial phone provisionment?
My current understanding (and I could be wrong) is that the last known primary network’s (seems to be whichever SIM had the data connection last) MMC and MNC value is part of the request that gets sent to the android update servers when checking for updates. The update server response varies depending on those values, which allows country and/or carrier-specific updates to be provided. The update server used is a Google one.
I do not know who needs to OK the update - Fairphone or the carrier. If the carrier ultimately has control, maybe some carriers automatically OK manufacturer-provided updates and other don’t?
Mine is setup without SIMs. Didn’t seem to help it didn’t work now.
Could be, would require some digging though. Has anyone gotten a response from Fairphone?
There is hope for Fairphoners with a SIM from HollandsNieuwe.
Today I received the update message out of the blue.
The update went smoothly.
Since there’s no real progress on this (contacted the FP support 3 weeks ago), I tried installing the update manually today via adb and ran into the exact same problem:
Installing update... E: Error in /sideload/package.zip (Status 1).
Can anyone confirm that the linked OTA-zip file is the correct one? Has anyone tried updating from A.0105 with this package and succeeded?
Small addition: I had a call with a technician from Vodafone and he told me that the manufacturer has to give the “go” for the android updates to be rolled out on a provider level. Without that, the update cannot be released.
So far it has been impossible to sideload any of the updates via adb. I think because there is no
/sbin/update_engine_sideload in the boot image (ramdisk), I just checked the A.0111 images that are available here in the forum.
This would be a static update engine binary that needs to be enabled in the android build configuration but it seems Fairphone / Arima didn’t do that.
Oh ok, thanks for explaining, didn’t know that. Guess I will buy a Sim-Card from a different provider next week, exclusively for updating.
One more information for the affected: I got a reply from the FP support and they confirmed that the latest update is currently not available for Vodafone in Germany (beside other providers). They are waiting for the approval from Vodafone which is mandatory. Hopefully we’re not ending up in a situation where everyone is waiting for the other.
Just my 2 c: Experienced the same problem here (Germany/Vodafone, FP3 vanilla). Solution was to buy a cheap prepaid card from another carrier, disable sim card 1 (V.), reboot, search for the update - et voilà: update was offered, installed and is now running w/o any problem on sim card 1 (V.) for days.
I have no clue why V. is blocking the update for weeks now, but one thing I know for sure: this messes w the security of my communication. This is absolutely inexcusable! I will change my carrier as soon as possible. So you just lost a customer, V. (but I know you don’t care).
Got a message to update a few days ago on Sky/O2 in UK
() Update was seen as soon as I plugged in the T-Mobile SIM and disabled the Vodafone one. It cost me 10 EUR, unfortunately, (plus 5 EUR for the KPN/Xs4all nanoSIM which did not work) but the T-Mobile one does work with updates.
The update does not work. When I download it, it asks me to resume the installation. When I do this, it says “installation failed, tap for more info”. When I tap, I see no info whatsoever. It just allows me to restart the process…
I’ve tried a few things: without the Vodafone SIM (instead of it being disabled), I tried a factory reset. In logcat there is also no info related to why it fails, except for.
04-08 17:15:44.077 730 730 I update_engine: [0408/171544.077534:INFO:delta_performer.cc(374)] Opening /dev/block/bootdevice/by-name/system_b partition without O_DSYNC
04-08 17:15:44.078 730 730 I update_engine: [0408/171544.078799:INFO:delta_performer.cc(126)] Caching writes.
04-08 17:15:44.079 730 730 I update_engine: [0408/171544.079017:INFO:delta_performer.cc(386)] Applying 6620 operations to partition “system”
04-08 17:15:44.093 730 730 E update_engine: [0408/171544.093555:ERROR:delta_performer.cc(990)] The hash of the source data on disk for this operation doesn’t match the expected value. This could mean that the delta update payload was targeted for another version, or that the source partition was modified after it was installed, for example, by mounting a filesystem.
04-08 17:15:44.093 730 730 E update_engine: [0408/171544.093803:ERROR:delta_performer.cc(995)] Expected: sha256|hex = 4624201CA589D350FB5CACFEFBB1B585CA128D42E0B2FEF8B5F0A17145C697C9
04-08 17:15:44.093 730 730 E update_engine: [0408/171544.093846:ERROR:delta_performer.cc(998)] Calculated: sha256|hex = 9866EBBF4F92986C2EA4E4740E29B5778DDAA6E93FF92BDB8F7A7419BD2F4881
04-08 17:15:44.093 730 730 E update_engine: [0408/171544.093942:ERROR:delta_performer.cc(1009)] Operation source (offset:size) in blocks: 0:2,191:16,222:295,8289:2,8303:2,8352:1,8371:1,8383:1,8424:1,8484:1,8488:1,8523:1,8554:1,8559:1,8563:1,8576:1,8601:1,8633:1,8637:1,8658:1,8666:1,8670:1,8682:1,8690:1,8717:1,8724:1,8736:1,8775:1,8779:1,8785:1,24002:8,24362:5,28648:1,32593:1,32768:2,33229:8,38050:20,38116:1,38488:2,38930:1,39799:1,42717:1,46743:1,47109:3,51082:8,54916:31,54948:1,54950:34,54987:6,54996:3,55001:18,55020:1,55022:13
04-08 17:15:44.094 730 730 W update_engine: [0408/171544.094018:WARNING:mount_history.cc(66)] Device was remounted R/W 3 times. Last remount happened on 1970-04-10 21:45:16.000 UTC.
04-08 17:15:44.094 730 730 E update_engine: [0408/171544.094073:ERROR:delta_performer.cc(1191)] ValidateSourceHash(source_hash, operation, source_fd_, error) failed.
04-08 17:15:44.094 730 730 E update_engine: [0408/171544.094119:ERROR:delta_performer.cc(298)] Failed to perform BROTLI_BSDIFF operation 1399, which is the operation 0 in partition “system”
04-08 17:15:44.094 730 730 E update_engine: [0408/171544.094161:ERROR:download_action.cc(337)] Error ErrorCode::kDownloadStateInitializationError (20) in DeltaPerformer’s Write method when processing the received payload – Terminating processing
04-08 17:15:44.094 730 730 I update_engine: [0408/171544.094483:INFO:delta_performer.cc(314)] Discarding 379674 unused downloaded bytes
04-08 17:15:44.094 730 730 I update_engine: [0408/171544.094539:INFO:multi_range_http_fetcher.cc(172)] Received transfer terminated.
04-08 17:15:44.094 730 730 I update_engine: [0408/171544.094575:INFO:multi_range_http_fetcher.cc(124)] TransferEnded w/ code 200
04-08 17:15:44.094 730 730 I update_engine: [0408/171544.094610:INFO:multi_range_http_fetcher.cc(126)] Terminating.
04-08 17:15:44.094 730 730 I update_engine: [0408/171544.094647:INFO:action_processor.cc(116)] ActionProcessor: finished DownloadAction with code ErrorCode::kDownloadStateInitializationError
04-08 17:15:44.094 730 730 I update_engine: [0408/171544.094684:INFO:action_processor.cc(121)] ActionProcessor: Aborting processing due to failure.
04-08 17:15:44.094 730 730 I update_engine: [0408/171544.094720:INFO:update_attempter_android.cc(431)] Processing Done.
04-08 17:15:44.095 730 730 I update_engine: [0408/171544.095456:INFO:update_attempter_android.cc(450)] Resetting update progress.
What can I do at this point?
EDIT: This solved it, my bad.
Edit: Ok, so you unlocked your bootloader and used TWRP. I’ll leave my post here anyway for other passers-by.
The telling bits are these here …
I got these messages, too, simply from using TWRP for the Fairphone 3.
It’s important to use the latest TWRP version and only let it mount system as read-only.
Without that setting even just installing something with TWRP without you explicitly mounting system before will mount the system partition read-write nonetheless and thus break OTA updates.
With an unlocked bootloader you can boot TWRP and restore the stock OS (currently A.0105 or A.0110).
Or you can flash stock A.0111 with fastboot onto the active slot.
Both methods should leave your data and the Apps intact.
Yep your post and the replies solved it.
My bootloader was locked. I’d like to keep it locked for security reasons (even if they’re not very strong measures against a determined actor). So I did lose my data. But next time, OTA should work when I disable my Vodafone SIM and enable my T-Mobile SIM (it is the other way around as it is). I’ll stick with Vodafone for the time being, as we got a good deal with them.
I was having the exact same problem for months. Using a “Lidl Connect” SIM which is a German Vodafone reseller. April 20 and still no January update, no February update, stuck in December 2019. So annoying, especially as we are talking about security updates!
The Fairphone support is useless in this case: I just keep getting excuses and helpless, meaningless replies as if Fairphone was not aware of the problem at all.
Finally, I checked with another SIM card: I removed the mentioned above and put in a 2017 inactive SIM from Laos(!), started the phone and it successfully installed the update immediately! Swapped the SIMs back again and everything is fine.
I think Fairphone should have talks with Vodaphone as this behaviour is simply inacceptable. And so is, sadly, the Fairphone support, too.
It’s interesting that it works with that Sim card for you. I tried it with 3 different American cards (all non Vodafone) and it works with none of them. It seems it heavily depends on the provider and country and not only the already discussed Vodafone+Orange are affected.
Anyway, since it doesn’t look like theres a Google-free OS coming up from Fairphone side I am thinking about switching to the soon to be released /e/ for the FP3. Then the topic should be solved anyway.
quick update from my side:
after some e-mail discussions with FP support finally including harsh words from my side they finally managed to give me the following feedback:
“Dear xxx … After consulting with the tech team, this is what they told me: ***The update was not delivered on devices with Vodafone SIM cards because in some specific conditions it might have caused some malfunctioning. This will be fixed with our next software release which will be deployed also to Vodafone SIM card users and will contain all of the previous updates.***”
Until today no automatic update with my Vodafone SIM, but using the known SIM-swap mechanism I immediately got A.0118. (which includes “Minor fixes for various carriers configurations” according to FP release notes)
After reboot I immediately switched back to Vodafone SIM and even with this SIM I immediately got A.0120. hallelujah ! So this topic seems to be solved …
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.