For search purposes the error was actually “Could not load file…” rather than “Cannot load…” Either way, I didn’t really learn much about the error before the interface bounced back. I have a different installation now but as I recall, eth0 came back to life after enabling every dynamic addressing scheme I could think of including the provider’s auto-config network tool. Once the v4 IPs showed up in Webmin I tailored the ifcfg-eth0 file back to static addressing and the server chugged along as if nothing happened. In all I think I rebooted five times.
While researching the problem I came across older Virtualmin posts about similar situations but with different errors.
- “No Ethernet interface could be automatically found on your system”
- “Virtualmin could not work out the system’s default IP”
- and a log entry saying “parent interface eth0 does not exist”
I also came across the workaround of specifying a default server IP in Virtualmin instead of the interface. But like you said, that’s just a workaround for a lower level problem that I think can be attributed to the OS.
One interesting but dubious idea is that Network Manager may choke on loopback definitions in an interface file.
It’s dubious because I normally use DNS1=127.0.0.1 and let Network Manager write it to resolv.conf after a restart. When my busted network rebounded this DNS entry was omitted and I was using the provider’s resolvers, although I’ve since put the local resolver back without any new problems. Perhaps it’s better to manually edit them and leave NM out of it?
This specific error seems to trace back to older releases of CentOS/RHEL. So I’m going to chalk it up as a never-fixed bug and do what everybody else does: blame Network Manager and systemd and move on.
Thanks for your reply and insights!