@Radovan_Haban I am sorry but I suspect that this is not a problem with update. The output you posted clearly fails to mount /dev/mmcblk0p1 which is root file system. That might be caused either by failed storage or some problems with kernel. I have to ask if this is after or before system reboot. You should reboot router after update if you encounter some problems.
candela tech. drivers are known to be unreliable and we had to switch away from them because of stability. If you encounter problems then you should switch back from them. Also if you are reporting problem with nonstandard configuration please start with that, you scare other users with formulation you used. Thank you.
It means that file wont be overwritten if it differs during update. Configuration files migration is not part of that and has to be done on per-package bases and in OpenWRT pretty much nobody does that so don’t expect that. In this case I suspect that comparing it to upstream it is clear that not having it set as configuration file was a bug.
I am sorry to hear that. If you did only factory rollback then all settings can be still accessible using schnapps. There is going to be factory rollback snapshot you can mount and access latest configuration. May I ask if you have any idea what happened? This seems to me like a common problem where users disable kresd and set dnsmasq to port 53. Updater later reenables kresd which prevents dnsmasq from starting and that way DHCP no longer works.
@BuloZB thank you for reporting. We already know about that and we reproduced it. It is nothing more than frontend issue. Special meaning value (zero) is interpreted invalidly as a time which is date you see.