The usual OTAs are incremental updates, the system basically downloads patches for the things that have changend, applies them to your current partitions and writes the result to the other slot, which gets booted into afterwards. The patches are on the partition not the file level so they need to exactly match a checksum because patches need a specific starting point. Most partitions are read-only so this isn’t a problem, unless you modify them or there’s filesystem corruption.
The main reason for this is update size. If you check the release notes you’ll notice that most updates are only a few hundred MBs instead of the several GBs you’d get with a full OTA (which is still something that’s supported and those can work with modified partitions).
I tried to do as indicated by k3dAR.
Due to my initial configuration I needed to flash stock boot.img BEFORE I could start the OTA update.
As a consequence I lost the root permission so I could not perform the following to extract the new boot.img from the non active slot
So instead I downloaded and extracted FP5-UT2B-factory/images/boot.img from https://fairphone-android-builds.ams3.digitaloceanspaces.com/FP5/A14/FP5-UT2B-factory.zip
I copied it on the phone and let Magisk patched it then copied the boot.patched.img to my computer and could finish as k3dAR indicated.
Let’s see if the next FP5 update is then allowed without flashing a boot.img and simplifies (a bit) the process for me (in both cases I will need a computer and to patch a boot.img with Magisk, I could just avoid some steps if the update is allowed while I am still having root permission).
I still wonder what changes with this way of installing Magisk since the “Install direct” indicates that it flashes something. If it flashes in the boot.img, then the next OTA update should indicate an error, as I had till now. If it flashes somewhere else, where this is not problematic for OTA update, I would like to know where and why the standard process asks to patch boot.img and not this other partition.
Several months later after being unable to update to Android 14 with OTA, I have not bothered doing the update manually, but as of a few days ago, the OTA update worked without any issues. Didn’t even need to manually update, as it seems like something must have changed with the OTA update.
@yvmuell Could there have been a security update in the meantime that applied some fixes to the OTA? Or did the FP5 device somehow make all the checksums pass? I have no idea how it happened, but now my FP5 device is now at Android 14 Upside-Down Cake.