While testing upgrade to 5.15 for the hardened patchset PR, ran into a somewhat nuanced problem with how configuration copies are made during commit. Test device boots with an apparently configured state, but configure followed by show yields an empty config. After loading the default config and trying to commit that, i found this gem in the vyatta-cfg logs:
cp w->tw failed[boost::filesystem::copy_file: Invalid cross-device link: "/opt/vyatta/config/tmp/new_config_1607/interfaces/ethernet/eth0/hw-id/node.val", "/opt/vyatta/config/tmp/tmp_1607/work/interfaces/ethernet/eth0/hw-id/node.val"]
Which seems related to this fix in libboost itself: https://github.com/boostorg/filesystem/commit/4b9052f1e0b2acf625e8247582f44acdcc78a4ce
Given that Boost's API is "somewhat fragile," its probably safer to drop-down to stdapi for file operations so that we know exactly what is happening and aren't at the mercy of Boost's innards determining whether to rename(), copy ranges, or who knows what else it will want to do under the skin someday. In the very least, it probably makes sense to catch the EXEDEV exception and use a native primitive to complete the op it tried to execute (boost::filesystem::file_copy())
I can verify that nothing other than the kernel version have changed, including sysctls, mount options, packages, etc - same build for both images a few minutes apart with 5.10 working fine and 5.15 refusing to commit.
