Network not configured on bionic

Can you attach the xenial log that boots just fine on the same hardware?

Also can you provide a list of interfaces and their mac address values? Maybe the commissioning, lshw output?

Thanks

So, what's happening here is the BOOTIF parameter specifies a MAC of a device, but that device is *not* found; then we see the errors here.

So let's get confirmation that the BOOTIF parameter mac matches with one or more of the interfaces on the system.

I recreated this same failure by booting a bionic instance with these parameters:

ip=::::amused-guinea:BOOTIF ip6=off BOOTIF=01-00-25-90-4c-f0-38

With a default virio nic whose MAC does not match and I see the exact same output.

I repeated that with a Xenial instance and it fails in the same way; so I suspect there's something misconfigured w.r.t the MAC on the boot params; or possible since this is hardware, something is going on with the MAC addrs on the system with the e1000e nics.

Possibly related:

 https://bugzilla.redhat.com/show_bug.cgi?id=1525523
 https://marc.info/?l=linux-kernel&m=151272209903675&w=2

That *should* be in bionic 4.15 ...

and from the log, you're running 4.13.

I suspect kernel bug on e1000e here.

Can you boot with bionic 4.15 kernel and check again?

So it seems that the latest 4.15 kernel in -updates has indeed made a difference, however, it hasn't really solve the problem. [1] shows the new issue. It doesn't seem to be driver problem and DHCP is working fine, provided that otherwise, the machine wouldn't have even gotten to this point.

[1]: https://pastebin.canonical.com/p/HjXS85hr4F/

Can you paste the whole log?

It still looks like something about the nic isn't working right. Can
you boot something non-network on that hardware and just confirm
that the nic actually works?

On Thu, Apr 12, 2018 at 1:43 PM, Andres Rodriguez
<email address hidden> wrote:
> So it seems that the latest 4.15 kernel in -updates has indeed made a
> difference, however, it hasn't really solve the problem. [1] shows the
> new issue. It doesn't seem to be driver problem and DHCP is working
> fine, provided that otherwise, the machine wouldn't have even gotten to
> this point.
>
> [1]: https://pastebin.canonical.com/p/HjXS85hr4F/
>
> ** Changed in: cloud-initramfs-tools (Ubuntu)
> Status: Incomplete => New
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1761573
>
> Title:
> Network not configured on bionic
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/cloud-initramfs-tools/+bug/1761573/+subscriptions

full log

The hardware is remote, the only thing I could do is deploy Xenial and dist-upgrade to Bionic if that helps ?

Hrm, You could install Xenial and then upgrade to bionic's cloud-init ramfs; but keep the 4.4 kernel. This would allow us to test the initramfs code vs. the hardware. If 4.4 + cloud-initramfs-tools 0.40 works, then you likely have an issue with the kernel + the e1000e driver to sort.

Ryan,

Maybe I’m missing something but I’m wondering How Will installing Xenial
and upgrading cloud-initramfs help here when the system boots of the kernel
and not an ephemeral image/network?

On Thu, Apr 12, 2018 at 4:01 PM Ryan Harper <email address hidden>
wrote:

> Hrm, You could install Xenial and then upgrade to bionic's cloud-init
> ramfs; but keep the 4.4 kernel. This would allow us to test the
> initramfs code vs. the hardware. If 4.4 + cloud-initramfs-tools 0.40
> works, then you likely have an issue with the kernel + the e1000e driver
> to sort.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1761573
>
> Title:
> Network not configured on bionic
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/cloud-initramfs-tools/+bug/1761573/+subscriptions
>
> Launchpad-Notification-Type: bug
> Launchpad-Bug: distribution=ubuntu; sourcepackage=cloud-initramfs-tools;
> component=main; status=Incomplete; importance=Undecided; assignee=None;
> Launchpad-Bug-Information-Type: Public
> Launchpad-Bug-Private: no
> Launchpad-Bug-Security-Vulnerability: no
> Launchpad-Bug-Commenters: andreserl raharper
> Launchpad-Bug-Reporter: Andres Rodriguez (andreserl)
> Launchpad-Bug-Modifier: Ryan Harper (raharper)
> Launchpad-Message-Rationale: Subscriber
> Launchpad-Message-For: andreserl
>
--
Andres Rodriguez (RoAkSoAx)
Ubuntu Server Developer
MSc. Telecom & Networking
Systems Engineer

On Thu, Apr 12, 2018 at 4:36 PM, Andres Rodriguez
<email address hidden> wrote:
> Ryan,
>
> Maybe I’m missing something but I’m wondering How Will installing Xenial
> and upgrading cloud-initramfs help here when the system boots of the kernel
> and not an ephemeral image/network?

Right, so if Xenial deploys fine, then we know that:

e1000e on 4.4 with cloud-initramfs-tools 0.27 is OK

We have a few things to try:

e1000e on 4.4 with cloud-initramfs-tools 0.40 (which is whati's in bionic)

So, you don't have to do an install, but the easiest path IMO is to deploy
Xenial on the system with e1000e, upgrade the cloud-initramfs-tools to 0.40
from bionic, rebuild the initramfs file, copy that to MAAS and redeploy
with 4.4 kernel and a 4.4 initramfs but using the cloud-initramfs-tools 0.40

If this combination works, then we can rule out any changes to initramfs tools
being the issue here and left with a kernel bug in 4.15 and e1000e.

>
> On Thu, Apr 12, 2018 at 4:01 PM Ryan Harper <email address hidden>
> wrote:
>
>> Hrm, You could install Xenial and then upgrade to bionic's cloud-init
>> ramfs; but keep the 4.4 kernel. This would allow us to test the
>> initramfs code vs. the hardware. If 4.4 + cloud-initramfs-tools 0.40
>> works, then you likely have an issue with the kernel + the e1000e driver
>> to sort.
>>
>> --
>> You received this bug notification because you are subscribed to the bug
>> report.
>> https://bugs.launchpad.net/bugs/1761573
>>
>> Title:
>> Network not configured on bionic
>>
>> To manage notifications about this bug go to:
>>
>> https://bugs.launchpad.net/ubuntu/+source/cloud-initramfs-tools/+bug/1761573/+subscriptions
>>
>> Launchpad-Notification-Type: bug
>> Launchpad-Bug: distribution=ubuntu; sourcepackage=cloud-initramfs-tools;
>> component=main; status=Incomplete; importance=Undecided; assignee=None;
>> Launchpad-Bug-Information-Type: Public
>> Launchpad-Bug-Private: no
>> Launchpad-Bug-Security-Vulnerability: no
>> Launchpad-Bug-Commenters: andreserl raharper
>> Launchpad-Bug-Reporter: Andres Rodriguez (andreserl)
>> Launchpad-Bug-Modifier: Ryan Harper (raharper)
>> Launchpad-Message-Rationale: Subscriber
>> Launchpad-Message-For: andreserl
>>
> --
> Andres Rodriguez (RoAkSoAx)
> Ubuntu Server Developer
> MSc. Telecom & Networking
> Systems Engineer
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1761573
>
> Title:
> Network not configured on bionic
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/cloud-initramfs-tools/+bug/1761573/+subscriptions

I can no longer deploy Xenial on the same hardware. I see the same issues as with Bionic (Note that the system PXE boots just fine, loads the ephemeral env, but gets stuck in the same place).

hostname big-koi hostname big-koi hostname big-koi hostname big-koi hostname big-koi hostname big-koi IP-Config: no response after 4 secs - giving up
IP-Config: enp1s0 hardware address 00:25:90:4c:f0:28 mtu 1500 DHCP RARP [ 27.054023] random: nonblocking pool is initialized
hostname big-koi hostname big-koi hostname big-koi hostname big-koi hostname big-koi hostname big-koi IP-Config: no response after 6 secs - giving up IP-Config: enp1s0 hardware address 00:25:90:4c:f0:28 mtu 1500 DHCP RARP
hostname big-koi hostname big-koi hostname big-koi hostname big-koi hostname big-koi hostname big-koi hostname big-koi hostname big-koi IP-Config: no response after 9 secs - giving up
IP-Config: enp1s0 hardware address 00:25:90:4c:f0:28 mtu 1500 DHCP RARP
hostname big-koi hostname big-koi hostname big-koi hostname big-koi hostname big-koi hostname big-koi hostname big-koi hostname big-koi hostname big-koi hostname big-koi IP-Config: no response after 16 secs - giving up
IP-Config: enp1s0 hardware address 00:25:90:4c:f0:28 mtu 1500 DHCP RARP
hostname big-koi hostname big-koi hostname big-koi hostname big-koi hostname big-koi hostname big-koi hostname big-koi hostname big-koi hostname big-koi hostname big-koi IP-Config: no response after 25 secs - giving up
IP-Config: enp1s0 hardware address 00:25:90:4c:f0:28 mtu 1500 DHCP RARP
hostname big-koi hostname big-koi hostname big-koi hostname big-koi hostname big-koi hostname big-koi hostname big-koi hostname big-koi hostname big-koi hostname big-koi hostname big-koi hostname big-koi IP-Config: no response after 36 secs - giving up
IP-Config: enp1s0 hardware address 00:25:90:4c:f0:28 mtu 1500 DHCP RARP

I'm also running into this issue..

using today's https://cloud-images.ubuntu.com/daily/server/bionic/current/bionic-server-cloudimg-amd64.img - converted into vmdk and using vmxnet3 or e1000 or e1000e adapters. In any constellation it does not initialize any interfaces or attempts any DHCP requests.

Looking at the contents of the image, it seems that both systemd-networkd and netplan are without any configuration at all.

Any pointers?

Creating /etc/systemd/network/default.network with contents:
```
[Match]
Type=en*

[Network]
DHCP=yes
```

is a valid workaround. However, cloud-init is still not run for some reason, but at least the VM now initializes the NICs.

Are these images tested? are the results somewhere reviewable? It seems very incomplete...

After another edit, namely a symlink of cloud-init.target into the multi-user.target.wants directory it finally boots up with cloud-init and everything work as expected.

This is quite a lot of manual work for something that's presented as `Ready to use`.

I'd like to contribute to the review/QA process for this because it clearly isn't catching all issues and these two issues (no network and no cloud-init) makes the image practically worthless in any cloud environment.

Hi Daniel,

Thanks for commenting. I don't believe your issue is the same as this bug (kernel issue with e1000e driver in the 4.15 kernel). Rather it appears that you're booting a cloud image outside of a cloud and without any cloud configuration.

Cloud-init only runs if it detects that it has been provided configuration from a Datasource. Typically for booting outside of a cloud, the NoCloud datasource[1] is a good option that can help provide minimal configuration.

http://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html

Once you've provided a NoCloud datasource to the image, cloud-init will enable itself and run. The default behavior is to DHCP on one of the nics to provide networking.

If you are booting this image in a cloud, please provide the user-data and more details about where you are running the image in a separate bug and we can helps sort out any booting/networking issues you're facing at this time.

We are hitting the same problem while booting VM with cloud-init configuration disk (iso image). Network interface will not configure itself with dhcp.