@Patryk this is a very weird error as kernel fault of course would be reproduced by other users as well. I looked into the code and I can’t see any clear way the division would happen in that specific function. Thus it leads me to the conclusion that the cause might be a corrupted kernel image. Are you sure that you finished the migration correctly? The router gets rebooted automatically as part of the migration process. Have that happen or was there a forced reboot? The second option is that MMC might just be worn out and out of the sectors and thus new writes could result in corrupted files. The kernel would report a load of BTRFS errors if that is the case (during the update most likely).
In general, I would appreciate it if you could send me the exported snapshot with your working 3.x version so I can attempt migration directly (of course only if you are willing to do so). You can get exported snapshots using
schnappps export X where
X is the number of 3.x snapshot that worked for you.
@Orzech I am happy to hear that migration finished in your case. The process is that we declare migration finished only after the first successful regular check for updates. That happens on a four-hour basis (that is up to four hours later from migration) or can be forced by clicking on
Check and install updates in reForis (as well as few others that trigger an update to install or remove additional software).
On the topic of verification. You do it the same way as you would do with a new router. Feel free to browse reForis and LuCI and look around with SSH. For example, the Firewall is compatible in its settings between 3.x and 5.x versions thus there should be no change.