Just as an info in case someone else sees this happening:

SXT LTE
after upgrade from 7.1rc2 to rc4, all of a sudden an OSPF entry was added, an entry which made the device do something (and fail, probably because of huge incomplete setup).
I only noticed this week when reviewing the log files on that device (although the upgrade was already done quite some time ago, that device has been down due to power shutdown after a thunderstorm 2 weeks ago, until past weekend when I made the trip of 930km on Friday and back on Sunday I had to assess other damage on site, luckily nothing major except some tripped fuses).

15:20:53 route,ospf,info OspfInstance { version: 2 0 rid: 192.168.100.1 } shutdown
15:20:53 route,ospf,info OspfArea { 0.0.0.0 } shutdown
15:20:53 route,ospf,info OspfArea { 0.0.0.0 } destroyed
15:20:53 route,ospf,info OspfInstance { version: 2 0 rid: 192.168.100.1 } destroyed
15:20:53 route,ospf,info OspfInstance { version: 2 0 rid: 10.18.125.109 } created
15:20:53 route,ospf,info OspfArea { 0.0.0.0 } created

In Winbox / Route / OSPF an entry is visible with some minimal setup.

I have not seen this on Hex, mAP2nD nor mAP Lite (maybe because those went from 7.1rc3 to 7.1rc4 ? Who knows ...)

Ticket created: SUP-63562
They send me a new version but not sure what I am supposed to see different. That OSPF line was still there so ultimately I removed it manually.

ROSv7 by default does not have OSPF configuration at all, v6 has default instance and default backbone area.
Upgrade from v6 converts old config to the new one including default instance and backbone, which lead to initialised OSPF. Version that supout gave you will not run OSPF on areas that do not have interface configuration.

I understand what you are saying but:
- I still have some ROS6-devices running with a customer and they effectively show a default area and backbone in OSPF settings. So that part makes perfect sense.
- All the mentioned devices from above were upgraded from 6.x to 7beta to 7.1rc etc etc.. So if I follow your explanation, they should ALL have this problem. Right ?
- Only ONE showed this behavior. On that device I never saw any OSPF log entries before, even when it was on 7.1rc2. So it was not coming from ROS6 ? Or did 7.1rc4 trigger something ? Why not on the others then ?

Regardless, I understood the new version which was provided should correct this where ever it came from. So one bug squashed

OSPF config upgrade was implemented only in RC4, so if you have upgraded to any older rc version previously ,then OSPF config was not upgraded.