1

0. Introduction

I've just installed Ubuntu 18.04.4 LTS (server) on an old-ish Dell Poweredge 510 - formerly hosted Windows 2008R2.

The installer "mentioned" an issue with the network adapters. This system has two (eno1, eno2) adapters that were bonded in the Windows server. However, despite the installer's gripe, the system installed successfully - including a functional network.

As my first order of business, I decided to sort the installer's gripes about the network. I decided that bonding the two adapters would be a good idea, and perused some documentation showing how that was done. Unfortunately, I may have fallen into a "Netplan rabbit-hole", and so this Question is about how to get out! Here's what I did:

1. Edit the file /etc/cloud/cloud.cfg.d/50-curtin-networking.cfg

Following are the contents of this file as I found it (before ANY edits):

network:  
  ethernets:  
eno1:  
  addresses:  
  - 192.168.1.74/24  
  gateway4: 192.168.1.1  
  nameservers:  
    addresses:  
    - 192.168.1.1  
    - 8.8.8.8  
    search:  
    - mylan.local  
  version: 2  

I created a replacement for the file above. This is it:

network:
  version: 2
  ethernets:
    eno1:
      dhcp4: no
    eno2:
      dhcp4: no
      optional: true
  bonds:
    bond0:
      interfaces: [eno1, eno2]
      addresses: [192.168.1.74/24]
      gateway4: 192.168.1.1
      nameservers:
        addresses: [192.168.1.1, 8.8.8.8]
        search: mylan.local
      parameters:
        mode: active-backup
        primary: eno1
        mii-monitor-interval: 100

2. Run commands to check the configuration:

$ sudo cloud-init clean
$ sudo cloud-init init
# errors, incl the following: 
...

2020-03-31 04:58:22,849 - util.py[WARNING]: failed stage init  

...

cloudinit.util.ProcessExecutionError: Unexpected error while running command.
Command: ['netplan', 'generate']
Exit code: 1
Reason: -
Stdout: 
Stderr: /etc/netplan/50-cloud-init.yaml:13:15: Error in network definition: bond0: interface 'eno1' is not defined
                    - eno1
                      ^

Note the file ref'd by stderr is /etc/netplan/50-cloud-init.yaml. But I did not edit this file.

OK - so the yaml file is apparently generated by the file I did edit. I decided against following this advice that advised editing the yaml file contrary to the information in the file! Instead, I opted to beat a hasty retreat! But that doesn't seem to have worked either:

3. Retreat! Restore the original .cfg file:

Fortunately, I saved a copy of the ORIGINAL file: /etc/cloud/cloud.cfg.d/50-curtin-networking.cfg

I restored this file to its original contents by simply copying the ORIGINAL file over the edited file:

$ sudo cp /etc/cloud/cloud.cfg.d/50-curtin-networking_ORIGINAL.cfg /etc/cloud/cloud.cfg.d/50-curtin-networking.cfg

I thought this would solve my problems, but when I run the commands again, I continue to get errors. In fact, I get the same errors I got with the edited .cfg file above!?

$ sudo cloud-init clean
$ sudo cloud-init init
# errors, incl the following: (same errors as above)

4. The Question

At this point, I feel like someone who's just stepped into quicksand - the more I move, the deeper I sink. So, I'm staying still, and asking for help. I believe Netplan must work at some level, but there's a lot of conflicting information out there.

What do I need do to restore my network to its original, as-installed configuration?

Where is the DEFINITIVE guidance for network configuration under Netplan?

2

The replacement yaml has an error, the search: key takes a list rather than a single value, e.g.:

search: [mylan.local]

If you fix this, the netplan generation should succeed.

As for whether to edit the cloud config file vs the netplan yaml file, I have opened https://bugs.launchpad.net/cloud-init/+bug/1869967 to discuss this. The intent is that a user never has to rerun cloud-init on a server install, and the config files under /etc/netplan should be treated as the authoritative location to edit.

| improve this answer | |
  • Let me try to make sure I understand: When you say the replacement yaml has an error, are you referring to /etc/netplan/50-cloud-init.yaml? Is that the file I should edit? Or should I edit the file at /etc/cloud/cloud.cfg.d/50-curtin-networking.cfg? – Seamus Mar 31 at 22:50
  • And once I've made the edit, do I run cloud-init, or do I run a netplan command? – Seamus Mar 31 at 22:51
  • the "replacement yaml" I'm referring to is what you had pasted. At the time I think you were putting it in the cloud-init config. Ideally you should be configuring this directly in netplan and running netplan apply, and ignoring (or even deleting) the cloud-init config. You should never have to run cloud-init again on an Ubuntu Server system installed with the new server installer, and the messages in /etc/netplan pointing you to /etc/cloud/cloud.cfg.d are an error that we're working on correcting. – slangasek Apr 1 at 15:29
  • This is all good. I've selected yours as "the" answer & upvoted it. I have one comment, and it's not intended as criticism: I'd appreciate it if you edited your answer at some point to include the clarifications in your comment. I am also sharing this with the author of this answer so that he can update if he chooses. You Ubuntu guys all need to be on the same page :) – Seamus Apr 1 at 21:11
0

This is NOT the answer. This isn't even an answer per se, but for those that find themselves in the Netplan Rabbit Hole because they were trying to bond two Ethernets, this is how to get confirmation that you've escaped:

$ sudo lshw -class network -short
H/W path            Device      Class      Description
======================================================
/0/100/1/0          eno1        network    NetXtreme II BCM5716 Gigabit Ethernet
/0/100/1/0.1        eno2        network    NetXtreme II BCM5716 Gigabit Ethernet
/1                  bond0       network    Ethernet interface

I'll also call attention to the error messages generated when I ran cloud-init init (ref Item 2 in my question above). Apparently these error messages have absolutely nothing to do with the actual error. We're all used to cryptic error messages, but this one is insidious IMHO as it specifically threw out a red herring! Kudos to @slangasek for spotting that.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.