The correct folder structure should be visible on the stable and dev builds now.
The one build on which it is still pending is the FP3 Q dev build. Will try to get it out as part of the v1.4 or the next v1.5 which should be released in the week after next.
1 Like
https://doc.e.foundation/devices/FP3/upgrade
Warning: Please note this upgrade build could not be tested as there were no device specific testers available. Some devices may need a revert to stock ROM prior to upgrade. To flash the stock ROM you would need to use a tool provided by your vendor. You may also need to download a recovery image built specifically for your device.****
Is this really true for FP3?
And also, in this guide it says sideloading work but that is not the case when you have a locked bootloader
The flash instructions are outdated as for the S dev (or other dev) builds.
The complete section “Installing /e/OS from the bootloader” refers to unzipping and starting “flash_FP3_factory.sh” but the latest dev builds contain the complete OTA which is just a payload.bin file.
So it needs to be flashed by sideloading and not via “flash_FP3_factory.sh”.
As I ran in some kind of a dead end with my FP3 Q dev build, now having to manually upgrade to R, I would suggest to add the following important information for all devices affected:
You can’t switch (or get switched by updates) from a certain dev build to its stable counterpart. OTA upgrades from one OS version to another are not available for dev builds. When development of updates for your dev build is discontinued, you will have to install a more up-to-date OS version manually.
The command line install instructions given at Install /e/OS on a Fairphone FP3/3+ - “FP3” are currently only valid for the stable install files, not for the dev install files.
The stable install files currently come in the format which installs partition images with fastboot, the command line install instructions cover this.
The dev install files currently come in the OTA format ready for use with ADB sideload in the recovery, the command line install instructions don’t reflect this at all as far as I see.
3 Likes
Related to my previous post …
The instructions at /e/OS Version Upgrade for FP3 are currently only valid for the dev install files, not for the stable install files.
While the instructions according to their heading are supposed to upgrade to S, which is dev only currently, R stable downloads are also referenced there.
2 Likes
the lack of up-to-date instructions is horrifying(!).
We’re not talking about any phone, but about the (kind of) flagship of /e/ - about FAIRPHONE that officially refers google-criticists to the murena website. Not that the instructions are remarkably better for other phones (even the ones that get supported by Easy Installer).
Since I reported that issue on Sep '22, there is still no solution except for the very recent Forum Post by AnotherElk, that could be converted into a simple and fast guide. you woldn’t even have to write anything new, since the recently referred upgrade instructions contain the same procedure…
1 Like
Woaw, that’s just frightening!
I spent two hours reading posts and I still don’t know REALLY how to update my FP3 Pie version to R with the appropriate documentation. The geeks world is amazing 
Did you manage the upgrade?
Hi.
Why do I need to manually upgrade the OS
The updater app does not support upgrades from one Android version to another. It will hide any update of a different version. We are working on resolving this issue. While this issue is resolved, users need to manually upgrade their OS. Upgrading manually requires similar steps to installing /e/OS for the first time.
This is outdated - at least for me.
The OTA upgrade from a stable 1.8.1-R to a stable 1.9-S just worked for me flawlessly.
I did not even expect it - except that the system-upgrade info box warned me, that the new Android 12 - based version … bla bla… please make a backup - etc.
I thought that the upgrade information would be a typo or not realizing correctly I still had an Android 11-based version.
2 Likes
The wording from step 4 is confusing, it looks like this is a step one has to execute but no instruction how to do it because this how-to is explained in step 5. Maybe merge these two together to get a better understanding for the non-so-knowables like myself
Hi,
I followed the doc for installation on my FP3 :
https://doc.e.foundation/devices/FP3/install
Once downloaded and unziped this :
IMG-e-1.10-s-20230412278810-stable-FP3.zip
I launched the script to wipe and install eos on my phone :
chmod +x flash_FP3_factory.sh && ./flash_FP3_factory.sh
I got the following error:
error: cannot load ‘…/IMG-e-1.10-s-20230412278810-stable-FP3/tz.img’: No such file or directory
Editing the script and checking, I see that there are two files missing in the zip built:
flash_image_ab_or_abort “${sn}” tz “${IMAGES_DIR}/tz.img”
flash_image_ab_or_abort “${sn}” vendor “${IMAGES_DIR}/vendor.img”
Can you help ?
My mistake, sorry : the downloaded file was corrupted.
Yes @fab, I eventually understood how to do and used easyinstaller. Some steps were not working exactly as expected but the process succeeded. Now I have version 1.8.1 R and most things work fine.
1 Like
That’s cool. So now you know how to upgrade to 1.10 stable! 
1 Like
Yes! I have done it two days ago. It was just easy and fast!
1 Like
Maybe I am at the correct place. If not, please move.
I present my findings on the battery usage and charging of my FP3+.
Since January 8th 2023 (262.2 days) I noted some data to find out about time and effort related to it.
It is understood that this is relying on my personal using pattern which might not be average, since I go without email on it, rarely use „social‟ media and do seldomly look up anything but use my head instead.
So, I guess the numbers might not be fully representative.
I have a special charging pattern, too, as I tend to keep the battery between 30 and 70% and fully charge it to 100% about every 10th time charging to reset the controller. This is due to the given fact that batteries get stressed by being totally drained or fully charged, which decreases their lifetime.
My FP3+ is two years old now and so is the battery.
That said I recon that the knowledge of relationships of the different versions and subversions possibly are useful to the developers as well as the users.
I started to note on January 8th with v1.7, but began to note the special charging times (e.g. such as daytime of start and end, giving the average charging time for 1% battery life) with v1.9 on March 30th.
This results in graphs for the power usage starting with v1.7 and start of the charging graphs with v.1.9.
As I always install the rc-subversions as soon as they are available, which tend to sometimes give a wide range of results within the version. It is difficult to decide what the special reasons are, as sometimes version changes appear within a few days being accompanied by changes in the using pattern which I note as well.
E.g., the subversions of v1.13 (v1.13-rc, 1.13-rc2, 1.13-rc4 and v1.13) have an average of 4.91 lasting days. The subversions themselves appear to last 5.60 days (v1.13-rc), 4.19 days (v1.13-rc2), 5.77 days (v1.13-rc4) and 4.45 days.
As they had different durations (327:44 hrs or 13,7 days,102:30 hrs or 4.3 days, 55:43 hrs or 2.3 days, 424:17 hrs or 17.7 days) I included the relationship of installed time into the result (something like (([lasting subversion 1][intall time sv1])+([lasting sv2][intall time sv2])+([lasting sv3][install time sv3])+([lasting time sv4][install time sv4]))/[sum of version install time].
On July 2nd I installed a Matrix-client and started to use it increasingly due to it being a major communication channel on the Chaos Communication Camp which had to be prepared and I went there from August 11th through 20th. So, the actual numbers are clearly influenced by this and might not representate a „normal‟ user pattern, especially for myself. For the camp I noted „excessive use‟.
Here are the graphs for the usage and lasting times, firstly summarized under the main versions, then the single subversions:
And here we go with the charging times and duration, as well summarized under the main versions, then the single subversions:
Usually I tend to charge slowly on my desk- or laptop computer to further save battery life, as fast charging also means stress for the battery resulting in decreased lifetime. Since the heavy usage and very little time on the camp meant that I had to fastcharge it, I thought about the average time that I have to „care‟ for the thing.
I found that the „caring time‟ varies between 1.63% of total time (v1.12-rc.4, lasting 7.27 days, installed for 256:43 hrs or 10.3 days) and 8.72% of total time (v1.14-rc, lasting 2.24 days, installed for 61:57 hrs or 2.6 days).
3 Likes
hello everybody,
I try since a long time to understand how i can sync my APP GALERIE ON MY FAIRPHONE 3+ WITH my murena cloud.
It seems difficult for numerous other users.
Why not a tuto about sync?
Thanks a lot for all the good work you did.
Philippe
Yesterday I installed v1.16-rc.4, which means that v1.15 is final.
- Edit: I forgot to mention that the rc took 5:36 hrs to completely install which makes me wonder for what reason.
It seems that the tendencies are going in the right direction, as the usage decreases and the lasting gets longer.
The “caring time” for the phone seems to be stable more or less.
Here are the figures.
Lasting and usage:
and the subversions:
Charging and “caring time”:
and the subversions:
Now, I wondered how to display the endurance of the versions/subversions and tried this:
and for the subversions:
As I still stick to the habit to keep the battery between 30 and 70% and charge to 100% about every 10th time charging (to reset the controller) I found that in the higher percentages the charging time increases significantly.
When last time charging up fully I noticed at 97% an average of 4:00 minutes per % (charging from 60% through the time of 19:30 to - at the end - 22:40).
9 minutes later it had 98% and the average had risen to 4:07 minutes.
14 minutes later it had 99% with an average of 4:16.
It took another 28 minutes (!) for the last percent and ended up with an average of 4:45.
Have fun!
1 Like
great graphs, at the very least helps catching outliers
seen this at Update e/OS very slow - #8 by tcecyk before