Score:0

Migrate Ubuntu server from NetPlan to NetworkManager without disconnection (possibly over SSH)

in flag

I see that Ubuntu server after the installation comes as default with NetPlan with a DHCP configuration (at least in Ubuntu 22.04 focal fossa).

Some users don't want NetPlan and just want NetworkManager, for example to use nmcli, nmtui, or import VPN configurations etc. and so after the installation I think it's frequent to migrate to NetworkManager.

At the moment this is my procedure to migrate from NetPlan to NetworkManager after a clean installation.

Create this file:

/etc/netplan/01-er-netplan-fix.yaml

With this content:

# This file describes the network interfaces available on your system
# For more information, see netplan(5).
# Set and change netplan renderer to NetworkManager GUI tool
network:
  version: 2
  renderer: NetworkManager

Then run these commands:

# install Network Manager
sudo apt install network-manager

# disable NetPlan
mv /etc/netplan/00-installer-config.yaml /etc/netplan/00-installer-config.yaml.bak

# reload NetPlan
netplan apply

# I'm not proud of this but I reboot to apply everything now
reboot

Problem: when I reboot, the server obviously disconnects, but also it never renews its IP via DHCP.

As workaround, I open a physical terminal on the server, I run dhclient, and then I continue with nmtui adding a simple Ethernet configuration with DHCP, and everything is good again.

So my question is: how to migrate from NetPlan to NetworkManager? Possibly automatically renewing its IP? Possibly without any disconnection at all? so your SSH connection is not interrupted.

Feel free to suggest as answer to prefill at least a valid NetworkManager configuration for a valid DHCP after the reboot but I still don't understand if I can also avoid the reboot at all and keep a working SSH connection to do the whole migration process.

Thank you for your thoughts! Maybe this question is stupid but I don't know NetPlan, since I usually use Debian and I don't have these problems.

Terrance avatar
id flag
Did you enable the NetworkManager.service so that it starts up when the system reboots? See https://help.ubuntu.com/community/NetworkManager
in flag
Thanks @Terrance. I'm think that, after that reboot, NetworkManager was already running since nmtui and nmcli worked
Terrance avatar
id flag
I think one of the problems is that your devices end up being unmanaged. To fix this all you really need to do is to touch a file for Network Manager to manage the devices (interfaces). `sudo touch /etc/NetworkManager/conf.d/10-globally-managed-devices.conf`
Terrance avatar
id flag
Just ran a test in Ubuntu 22.04 where I installed NetworkManager and made sure that `nmcli` was working. Then I removed Netplan.io completely. `sudo apt remove --purge netplan.io`. Then I did the above comment with touching the file. Rebooted and network came right back up with the last IP address and didn't renew to a new DHCP IP address.
Score:2
de flag

A bit late to the party, but recently ran into a similar issue after inheriting some Ubuntu servers.

After a number of fresh installs and tests, these are the steps I've come up with - this should be do-able over SSH without interruption.

  1. Install NetworkManager with sudo apt install network-manager (this will make nmcli and nmtui available.
  2. Instruct NetworkManager to manage all interface types by default, create the file /etc/NetworkManager/conf.d/manage-all.conf with the following contents:
[keyfile]
unmanaged-devices=none
  1. Restart NetworkManager with sudo systemctl restart NetworkManager.
  2. Check your interface is now being managed by NetworkManager with nmcli.
  3. This step can be a little confusing - while NetworkManager shows the current configuration of the interface, this is based on the config applied through netplan and is not persistent from NetworkManager's point-of-view. To save the current config (and take some of the default config options which would be missed when moving from netplan to NetworkManager), run the following commands:
sudo nmcli connection modify enp1s0 autoconnect yes
sudo nmcli connection modify enp1s0 ipv6.method ignore
sudo nmcli connection modify enp1s0 ipv4.dns 8.8.8.8
sudo nmcli device reapply enp1s0
  1. Ensure the config has been saved - cat /etc/NetworkManager/system-connections/*
  2. Disable networkd and purge netplan:
sudo systemctl disable --now systemd-networkd.service systemd-networkd.socket networkd-dispatcher.service && sudo systemctl restart NetworkManager
sudo apt purge netplan netplan.io -y
  1. If DNS doesn't seem to work at this stage, restart NetworkManager - sudo systemctl restart NetworkManager

This should leave you with a Ubuntu server configured to use NetworkManager and bypass netplan completely. Steps may differ slightly, but this is the process I've found to work on a fresh install of Ubuntu 22.04.

David avatar
cn flag
You are repeating what was already said in the comments of the question.
in flag
I will try, thanks. As already noted, please link your sources to give proper credits
Score:1
aq flag

I believe the fact you didn't disable systemd-networkd (I suppose) has something to do with your issue.

Try this in a testing machine:

  • install network-manager

  • edit your netplan yaml file created by the installer and just add the line renderer: NetworkManager

  • netplan generate (to generate the network manager file) and check if it's there (/run/NetworkManager/system-connections)

  • edit the netplan yaml file again and change it to have the content you mentioned above

  • mask (systemctl mask ) all the networkd services you find with "systemctl | grep network"

  • reboot your system (or simply netplan apply, but it will possibly get a different IP address and your connection will drop anyway)

I have tested it on an Ubuntu 22.04 server installation.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.