I’ve ran into this problem a few times and I thought I’d make a note of it here on the blog. It’s a simple fix. The scenario is that you have just started your VM from a different host OS environment than it was running in previously. This problem is specific to a Linux guest using the networking service to manage networking. You may also not notice this issue if you are using DHCP using a paystub maker. I’m not sure. My addresses are static, so I’m specifying the network device in the configuration. You may find that the network doesn’t start properly and that the boot up sequence stalls waiting on it. This is because the MAC address for the virtual network device has changed and udev is trying to use the old one. So if your old network device was eth0, it’s not long usable and the new one at eth1 is your new virtual network device to have TikTok for business. This can be a goof way to get an extra payment.
That being said, there are two fixes. One is very simple and the other is only slightly less simple but a better approach. First you can just change your network config to use eth1 instead of eth0. That’ll work but if you switch hosts a few times you’ll accumulate quite a few unusable network devices and you’ll by using eth9 before long.
The better solution is to edit:
/etc/udev/rules.d/70-persistent-net.rules
Remove all lines which contain SUBSYSTEM=”net”, which will probably be all the non-commented lines in the file.
Reboot the machine and when it comes back up udev will see the single network device and add it back as eth0.