Some Linux installations on newer motherboards are defaulting to an alternative naming scheme for their network ports. The devices appear as em1 or p1p1 instead of eth0, eth1, etc. The hyperlink below describes the rationale for this change. To summarize, the new names are based on the physical port location and are enumerated by the bios rather than the operating system.
A TurboFloat/Activate installation on a machine using this feature will throw ENABLE_NETWORK_ADAPTERS because the network device names are unconventional. Disabling the feature via "biosdevname=0" seems like the only workaround at this time, but changing the system configuration in this way can lead to a host of other problems for the end-user. So I'd really like to offer a better solution. Do you have anything in the works?
In our case the issue rarely happens because the bios feature seems limited to server-class motherboards. But it will break all of our Linux installations if it ever migrates into consumer-grade hardware.
https://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming
This was solved in TurboActivate 4.0.8: https://wyday.com/limelm/api/ta-changes/
We added support for the partially defunct (and not supported across the industry) "biosdevname" standard.
The more widely supported "Predictable Network Interface Names" standard is also supported:
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
Long story short, use the latest version of TurboActivate.
Thanks, I'll check again with our customer. We are trying to use TurboFloat server version 4.0.9.6 with a Linux installation and the activation fails with error code 0x1C. I thought the odd network names were the culprit, but I suppose it could be something else.
