Software update: FP4.FP4I.A.175.20221207

Welcome to the community :wave:

Is your phone rooted or did you modify your system in any other significant way? :thinking:

If you are familiar with adb, you can capture logs with the steps mentioned above:

Once it fails, stop the adb command and have a look at the log.

Guys, I’ve just noticed that the 30% autobrightness limit no longer applies after this update. Can anyone confirm?

I still have the same issues. Try a reboot, the issue will be back after you manually lowered it. It will also reset without a reboot.

done that, the log is quite exhaustive (> 27000 lines), some recurring errors like:

12-29 11:33:09.128 1204 1696 E KernelCpuSpeedReader: Failed to read cpu-freq: /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state: open failed: ENOENT (No such file or directory)
12-29 11:33:09.129 636 2233 E android.system.suspend@1.0-service: Error opening kernel wakelock stats for: wakeup58: Permission denied

12-29 11:42:26.030 1204 2322 E BatteryService: getUsbPresent version1
12-29 11:42:26.030 1204 2322 E BatteryService: getUsbNTCTemp temp27.4
12-29 11:42:28.615 924 19730 E sensors-hal: handle_sns_std_sensor_event:298, front_handle_sns_std_sensor_event upload[0] = 60.532478

|12-29|11:35:59.019|1204|4132|E|VibratorService: Failed to issue command to vibrator HAL. Retrying.
|12-29|11:35:59.149|941|941|E|ANDR-IOP: UXEngine: Error no.: 0|
|12-29|11:35:59.459|1204|2283|E|WifiVendorHal: The product is FP4eea|
|12-29|11:36:00.147|953|3888|E|ANDR-PERF-LM: VmRssMeter:: start() 447: Could not find pid, can not collect vmrss data|
|12-29|11:36:00.147|953|3888|E|ANDR-PERF-LM: AdaptiveLaunch: writeToDataBase() 64: Meter aborted or could not get meter data for this run|

On the screen it comes to state “Optimizing system - this can take a moment” before it fails.
But in the log, it ends with D or I entries, nothing like “giving up”.

It is just a warning, but there is something with my banking-app:
12-29 11:42:28.782 15765 15765 W sybank.easybank: type=1400 audit(0.0:108967): avc: denied { search } for name=“/” dev=“cgroup2” ino=1 scontext=u:r:untrusted_app:s0:c232,c256,c512,c768 tcontext=u:object_r:cgroup_bpf:s0 tclass=dir permissive=0 app=com.easybank.easybank

Could that be it?

I don’t really see anything related to the update process in the snippets you posted, check the last messages for SystemUpdate and update_engine :thinking:

That’s some kind of SELinux warning, maybe @UPPERCASE can help here :crossed_fingers:
I don’t think that’s what keeps your device from updating.

Since you didn’t answer my other question about root, etc., I’m assuming you haven’t modified your system in any significant way, right?

Yes, nothing modified or rooted.

There where hundreds of basically same entries, but near the end, this could be it:
12-29 11:42:23.632 1369 1369 I update_engine: [] Hash of product: 9Xnm8UL5T2+YezUM2XFkJm4qCOSQnZjPckJNdglbQP4=
12-29 11:42:23.636 1369 1369 E update_engine: [] Old ‘product’ partition verification failed.
12-29 11:42:23.637 1369 1369 E update_engine: [] This is a server-side error due to mismatched delta update image!
12-29 11:42:23.638 1369 1369 E update_engine: [] The delta I’ve been given contains a product delta update that must be applied over a product with a specific checksum, but the product we’re starting with doesn’t have that checksum! This means that the delta I’ve been given doesn’t match my existing system. The product partition I have has hash: 9Xnm8UL5T2+YezUM2XFkJm4qCOSQnZjPckJNdglbQP4= but the update expected me to have TrU18aftsCgHxkYkN4N+WG2GWLMx5K3UP/3Bb/deIqg= .
12-29 11:42:23.640 1369 1369 I update_engine: [] To get the checksum of the product partition run this command: dd if=/dev/block/dm-2 bs=1M count=1919934464 iflag=count_bytes 2>/dev/null | openssl dgst -sha256 -binary | openssl base64
12-29 11:42:23.641 1369 1369 I update_engine: [] To get the checksum of partitions in a bin file, run: …/src/scripts/ …/file.bin
12-29 11:42:23.644 1369 1369 I update_engine: [] ActionProcessor: finished FilesystemVerifierAction with code ErrorCode::kDownloadStateInitializationError
12-29 11:42:23.645 1369 1369 I update_engine: [] ActionProcessor: Aborting processing due to failure.
12-29 11:42:23.647 1369 1369 I update_engine: [] Processing Done.
12-29 11:42:23.985 17911 17911 I SystemUpdate: [Phone,SystemUpdateChimeraActivity] Status change: status=0x111, isSetupWizard=false, layoutType=5
12-29 11:42:24.012 15980 18952 I SystemUpdate: [Control,InstallationControl] Resume on reboot feature enabled: true.
12-29 11:42:24.064 15980 18952 I SystemUpdate: [Control,InstallationControl] Update engine status updated to 0x000.
12-29 11:42:24.094 15980 18952 I SystemUpdate: [Control,InstallationControl] Update engine status updated to 0x000.
12-29 11:42:24.129 15980 19217 I SystemUpdate: [Control,InstallationControl] Installation progress updated to (0x412, -1.000).
12-29 11:42:24.146 17911 17911 I SystemUpdate: [Phone,SystemUpdateChimeraActivity] Status change: status=0x412, isSetupWizard=false, layoutType=5
12-29 11:42:24.165 15980 19217 I SystemUpdate: [Control,InstallationControl] Resume on reboot feature enabled: true.
12-29 11:42:24.282 15980 19217 I SystemUpdate: [Execution,SynchronizedUpdateEngine] stop()
12-29 11:42:24.282 15980 19217 I SystemUpdate: [Execution,ExecutionManager] Action streaming-apply executed for 247.08 seconds.
12-29 11:42:24.292 15980 19217 I SystemUpdate: [Execution,ExecutionManager] Action exponential-backoff-delay-execution executed for 0.01 seconds.

If I read it right, it is some sort of partition verification.
But how to handle this?
Should I reset to factory and update from there?

Yeah, your product partition has a hash miss-match. What I find interesting is how verbose those messages are, I’ve seen several hash errors, but never with whole paragraphs of explanation :man_shrugging:

So somehow one of your partitons changed. If you didn’t install Magisk or something similar, probably a bit flipped for some reason. That usually shouldn’t happen.

You could try to flash only that one partition, but honestly I wouldn’t trust the rest of the system at this point, flashing it from factory images is what I would do.
A factory reset won’t help you since that only wipes userdata and doesn’t restore damaged partitions.

Relocking the bootloader after flashing FPOS comes with some risks of bricking the device, read up on it and ask questions before you do it.
If you are unsure, #contactsupport and let them handle it.

Side note: In the future, please put logs between code tags like this …


… makes it easier to read :slightly_smiling_face:

1 Like