Ubuntu 17.10+ disable netplan

These directions have been tested also to Ubuntu 18.04.1 and will very likely work also for any future release using netplan and systemd.

There's no need at all to fiddle with GRUB nor any manual file removal. The configuration set up in /etc/networking files and directories will survive reboots.

These are the verified steps:

  1. Check the actual interface names you are interested in with ip l for the links (aka interfaces) and with ip a for addresses.
  2. Install ifupdown with sudo apt -y install ifupdown.
  3. Purge netplan with sudo apt -y purge netplan.io.
  4. Configure /etc/network/interfaces and/or /etc/network/interfaces.d accordingly to your needs (man 5 interfaces can be of some help with examples).
  5. Restart the networking service with sudo systemctl restart networking; systemctl status networking or sudo /etc/init.d/networking restart; /etc/init.d/networking status. The output of the status command should mention active as its status.
  6. The command ip a will show whether the expected network configuration has been applied.
  7. Optionally, manually purge the remants of the netplan configuration files with sudo rm -vfr /usr/share/netplan /etc/netplan.

No reboot is needed in order to "refresh" the IP configuration: it will be active as of step no.5 . In case of troubles, double check the interface names. A typical IPv4 DHCP configuration will resemble this one:

auto enp0s3
iface enp0s3 inet dhcp

while a static IPv4 address can be configured like this:

auto enp0s3
iface enp0s3 inet static
address 192.168.255.42/24
gateway 192.168.255.254
#dns-nameservers 8.8.8.8 208.67.222.222

Beware, the dns-nameservers entry won't work (thanks @Velkan for pointing it out!): the resolver is still using /etc/resolv.conf and systemd is providing his own resolution service from 127.0.0.53. So you can manually update it (no networking restart needed!):

nameserver 8.8.8.8
nameserver 208.67.222.222

But his would be only a temporary solution to vanish after the next reboot.

To get a permanent solution you need to edit /etc/systemd/resolved.conf and add a line like this one to the "[Resolve]" stanza:

DNS=8.8.8.8 208.67.222.222

Please, refer to man 5 resolved.conf for the full documentation.

Finally, in the unlikely case any network service is not responding as expected, then that services may need a restart. But that's a weird non-standard network daemon behavior.


The exact method to do this is hard, perhaps impossible to locate now in the early days of netplan.

I currently have this set to:

GRUB_CMDLINE_LINUX="ipv6.disable=1"

I assume that you mean that your /etc/default/grub reads, in part:

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX="ipv6.disable=1"
<snip>

I also assume that the link you give suggests that you add the referenced wording:

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX="ipv6.disable=1 netcfg/do_not_use_netplan=true"
<snip>

I suggest that you do just that, followed by:

sudo update-grub

You will also need:

sudo apt install ifupdown

It may already be installed.

Finally, fill in /etc/network/interfaces manually to configure your network the way you want it.

The exact process to do this post-installation, as far as Google and I can find, doesn't exist. Reboot with your fingers crossed!


Had this issue on Ubuntu 18.10 Server 64-bits (running on Virtual Box) and the following steps allowed to remove netplan and install Network Manager - not sure if they work for ifupdown. These steps are adapted from @Uqbar's answer (thank you).

  1. Check the actual interface names you are interested in with ip l for the links (aka interfaces) and with ip a for addresses.
  2. Install Network Manager with sudo apt -y install network-manager.
  3. Purge netplan with sudo apt -y purge netplan.io.
  4. Optionally, manually purge the remnants of netplan's configuration files with sudo rm -vfr /usr/share/netplan /etc/netplan.

  5. Configure /etc/network/interfaces accordingly to your needs (man 5 interfaces can be of some help with examples). Mine is configured as follows:

    auto lo
iface lo inet loopback

auto enp0s3
allow-hotplug enp0s3
iface enp0s3 inet dhcp

  6. On file /etc/NetworkManager/NetworkManager.conf, modify the line managed=false to managed=true. This will make Network Manager manage the interfaces configured in /etc/network/interfaces.

  7. Restart the Network Manager service with sudo service network-manager restart. The output of the status command should mention active as its status.

  8. The command nmcli dev will show whether the expected network configuration has been applied. Initially interface enp0s3 (my virtual ethernet) was appearing as unmanaged. After rebooting the machine, it appeared as connected. An example output of nmcli follows:

    DEVICE           TYPE      STATE         CONNECTION
enp0s3           ethernet  connected     Ifupdown (enp0s3)
wlxc46e1f179799  wifi      disconnected  --
lo               loopback  unmanaged     --

NOTE: I'm having some issues with processes hanging, as described here and here. I managed to change the vm.dirty_ratio and `vm.dirty_background_ratio to 10 and 5 respectively, from the defaults 20 and 10. For that, execute the following commands:

sudo sysctl -w vm.dirty_ratio=10
sudo sysctl -w vm.dirty_background_ratio=5

I'll update this answer reporting the results after running the VM for some time.

It's been a long time, but I think this problem never occurred again (can't verify as the VM is corrupted). Never really understood why; I'll leave the note here for future reference. See also my comment bellow.

Tags:

Grub2

Netplan

Recent Posts