eth0 not getting configured correctly after upgrade.

I recently upgraded an old droplet from 16.04 ->18.04 ->20.04. The first upgrade went fine but something broke networking after the second update. The droplet no-longer sets its IPV4 address/gateway correctly after a reboot. If I manually configured it using the recovery console everything works fine but it’s obviously broken again on next reboot.

In other words I need to run the following commands before I can use the droplet.

ifconfig eth0 <ipv4 address> netmask up
ip route add default via <gateway>

I thought it might be an issue with cloud-init since I think that is meant to handle configuring the droplet and there was an exception logged in /var/log/cloud-init.log:

2023-09-15 23:16:30,093 -[DEBUG]: Getting data from <class 'cloudinit.sources.DataSourceDigitalOcean.DataSourceDigitalOcean'> failed
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/cloudinit/sources/", line 1018, in find_source
    if s.update_metadata_if_supported(
  File "/usr/lib/python3/dist-packages/cloudinit/sources/", line 904, in update_metadata_if_supported
    result = self.get_data()
  File "/usr/lib/python3/dist-packages/cloudinit/sources/", line 48, in get_data
    (is_do, droplet_id) = self._get_sysinfo()
  File "/usr/lib/python3/dist-packages/cloudinit/sources/", line 45, in _get_sysinfo
    return do_helper.read_sysinfo()
  File "/usr/lib/python3/dist-packages/cloudinit/sources/helpers/", line 194, in read_sysinfo
    vendor_name = util.read_dmi_data("system-manufacturer")
AttributeError: module 'cloudinit.util' has no attribute 'read_dmi_data'
2023-09-15 23:16:30,096 -[DEBUG]: No local datasource found

I tried upgrading cloud-init to the latest version but that didn’t seem to do anything. Didn’t even resolve the error message.

Any ideas? Should I just cut my loses and copy the data over to a new droplet?

Submit an answer

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

Sign In or Sign Up to Answer

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Site Moderator
Site Moderator badge
September 16, 2023
Accepted Answer


I think it’s possible it is related to cloud-init, yes.

First, try reconfiguring it:

sudo dpkg-reconfigure cloud-init

It’s possible that there’s stale data or configurations present from the older version of the OS. You can clean these up:

sudo cloud-init clean

Then reboot the droplet to see if it resolves the networking issue.

If that doesn’t worrk, we can try something else.

DigitalOcean uses a specific cloud-init configuration for its droplets. Check the /etc/netplan/ directory for any .yaml configuration files and make sure they are correct. It should look something like:

  version: 2
      dhcp4: true

If you make any changes, apply them using:

sudo netplan apply

Then, reboot to see if this resolves the issue.

If none of that work, I’ll recommend contacting DigitalOcean Support. They should be able to assist you with the network issue.

I had the same problem on Ubuntu Jammy 22.04 LTS and it turned out to be because cloud-init was not upgraded properly.

There was a local dpkg-divert configuration which was preventing the package from being updated completely. I created a new Droplet with Ubuntu 22.04 and the dpkg-divert configuration is not present there. Therefore, this is something which Digital Ocean used long time ago and is no longer required.

Here is how to fix it:

dpkg-divert --list | grep cloudinit # ensure that the local diverts are in effect

rm /usr/lib/python3/dist-packages/cloudinit/sources/
dpkg-divert --remove --rename /usr/lib/python3/dist-packages/cloudinit/sources/

rm /usr/lib/python3/dist-packages/cloudinit/sources/helpers/
dpkg-divert --remove --rename /usr/lib/python3/dist-packages/cloudinit/sources/helpers/

I had exactly the same problem. I checked and the file is part of cloud-init package ( I compared its contents between the problematic droplet and one that I upgraded successfully and found they were different, even though cloud-init package versions were exactly the same.

In the version that was working correctly the problematic line looked different:


Running “apt remove cloud-init” didn’t remove the dist-package/cloudinit folder and deleting it manually caused the subsequent apt install cloud-init to fail, complaining that the file was missing (?!).

In the end I replaced the contents of the whole /usr/lib/python3/dist-packages/cloudinit folder with files copied from a working droplet and after running cloud-init clean -r again, everything worked.

Try DigitalOcean for free

Click below to sign up and get $200 of credit to try our products over 60 days!

Sign up

Get our biweekly newsletter

Sign up for Infrastructure as a Newsletter.

Hollie's Hub for Good

Working on improving health and education, reducing inequality, and spurring economic growth? We'd like to help.

Become a contributor

Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.

Welcome to the developer cloud

DigitalOcean makes it simple to launch in the cloud and scale up as you grow — whether you're running one virtual machine or ten thousand.

Learn more
DigitalOcean Cloud Control Panel