I have a situation with several hEX PoE routers where when the router restarts because of a power loss the last changes I made to the configuration seem to disappear. I'm using Winbox and am sure I haven't activated safe mode. RouterOS = 7.10.2 and firmware = 6.48.6 Should the ROS and board firmware always be matched? Thanks.

If safe mode is not enabled, it is usually due to low disk space on the device.

I was NOT using safe mode. I can confirm that making one simple change like removing a DHCP assignment for a disconnected device then rebooting reverts back to the exact same configuration. However, this router appears to have the low disk space issue which the others do not. Which is strange since they were all provisioned in exactly the same way before being shipped to the field

I've seen a fix for this but it appears to be for an older ROS version and also the file is no longer available for download.

…an older ROS version and also the file is no longer available for download.

Doubt it.

I'm still not clear on why the disk space problem happens. I'm only logging to memory nothing to disk. I can still upload script files and execute them but the next time the router reboots the config changes are lost.

I might try upgrading the firmware. These routers have been on a rolling release and I upgraded the routerOS to whatever the latest 7.* stable was at the time of config because of wireguard support. The router with the problem has 7.10.2 and the other more recent devices have 7.12.1. I have to test the upgrade carefully because my only connection is through a cell modem over a VPN.

Maybe not related but what does the Upgrade button do in this window? How is it different from upgrading the firmware from packages.

There is RouterBOARD firmware (a.k.a. routerboot) which is similar to BIOS/UEFI on PCs. And there is RouterOS (a.k.a. ROS) which is similar to Windows/Linux/... on PC.

The Upgrade button on screen shown upgrades routerboot (the "BIOS") to version, shipped with currently running ROS.
"Upgrading firmware from packages" is upgrading ROS (the "Windows").

I don't think it has anything to do with flash becoming full. The original problem is more likely due to some glitch in configuration database and which might be present since many upgrades ago. And to fix that glitch, the only sure way is to netinstall device and reconfigure it. Don't use binary backup to restore config, it seems that problems with configuration database are carried over in these backups. You should save textual export of configuration and use it to replicate config after netinstalling device. In theory it should be possible to import the file but it doesn't always work. All of it can hardly be done remotely (not impossible, but very, very hard).

There is RouterBOARD firmware (a.k.a. routerboot) which is similar to BIOS/UEFI on PCs. And there is RouterOS (a.k.a. ROS) which is similar to Windows/Linux/... on PC.

The Upgrade button on screen shown upgrades routerboot (the "BIOS") to version, shipped with currently running ROS.
"Upgrading firmware from packages" is upgrading ROS (the "Windows").

Thanks for clearing that up.

I don't think it has anything to do with flash becoming full. The original problem is more likely due to some glitch in configuration database and which might be present since many upgrades ago. And to fix that glitch, the only sure way is to netinstall device and reconfigure it. Don't use binary backup to restore config, it seems that problems with configuration database are carried over in these backups. You should save textual export of configuration and use it to replicate config after netinstalling device. In theory it should be possible to import the file but it doesn't always work. All of it can hardly be done remotely (not impossible, but very, very hard).

I've come to a similar conclusion by a different method. The very first routers we configured were done with the cut and paste method or using the import command. This was not always successful. On subsequent routers we reset the configuration (after ROS upgrade to 7.x) with no defaults and selected the configuration script to run after reset. AFAIK this has been 100% successful.

Still the issue with doing this remotely is the only access I have access to the router through WireGuard. The router is using a cell modem so I never know what its real IP is. If I reset the config I will loose the VPN connection because when the WireGuard interface is recreated the public/private key will change. I've determined that I can export the private key for the WireGuard interface. If I add this to the script that I run after reset I should be able to connect. Tested today and the remote configuration reset worked without loss of VPN connection. Will try it on the remote customer router later this week to see if that clears up the configuration problem.

Solution was to replace the router. Unfortunately customer decided to dissect the malfunctioning router instead of shipping it back to us so I did not have a chance to try netinstal. BTW before we powered it down I noticed the CPU usage was consistently at 100%.