[Paid Software Announcement and Discussion] Chainfire:
This is problematic because preserving the recovery is a function of the OTA action itself. Moving it after a backup is not possible in the current system. I will put it on the feature request list, though.

ERR does not necessarily mean an error, it just means output that written to the STDERR file descriptor. Many programs use that to output information rather than errors.

This is a weird log. It seems like some core things of FlashFire aren't functioning. Do you know what version of SuperSU you were running before the flash ?

Unfortunately this is not really possible. Backlight control is device specific, and trying to set a lower brightness before starting flash mode using Android's brightness control itself results in various Samsung devices bootlooping (which is completely ridiculous, but it does happen).

FlashFire can detect many common USB mount locations, but various OEMs do it differently. It's possible FlashFire doesn't understand your non-standard mount location, or its the explorer itself that manually accesses the USB drive. What exact device and firmware are you using, and what does your "mount" output look like?

Are you using systemless exposed in this log? Is it possible that is what interferes?

Deleting the .supersu file is fixed in the next release. Configuring SuperSU's options is on the list.

(Note that my list is over 100 items long by now, many things that are being suggested have been listed for ages)

Honestly I didn't even know getprop was generally supported in recoveries. getprop in FlashFire will not work unless /system is mounted, it is not present in /sbin.

getprop is not a core linux command, its a core Android command, which is why busybox not generally include it.

Unfortunately, you cannot just copy the implementation from /system, because it (toolbox, toybox) is dynamically linked and thus will not function without /system being mounted (in which case it would already be working). Additionally, there is no easy way to create a compatible statically linked getprop binary, because the property service's internals differ significantly between Android versions, so one piece of code will not work across different Android versions.

I'm sure I can create a solution that emulates getprop, but it would not reflect changes made with setprop since (probably) FlashFire switched to flash mode, and thus it wouldn't be 'real' getprop. It should probably work well enough for most cases. That might be worth doing.

I think FlashFire just doesn't know about this path (I'll add it to the list next to /cache/fota).

Have you tried opening it manually with the "Flash ZIP/OTA" function in FlashFire? It might work that way.

Note that you shouldn't worry that much about the corruption warning. Samsung is using a non-standard form of the ZIP format that is pretty much unsupported by any archiver, throwing an error. FlashFire can read it, though, unless it is truly corrupted.

There is some weirdness sometimes with Samsung KitKat. I'm not sure what causes it.

Yes, as the log said, /system was modified. You cannot apply incremental OTAs on modified /system.

Is it using a visual installer like Aroma, or... ?

Probably only if you wipe (or restore from backup) data. Generally speaking, you cannot downgrade Android version while keeping data.