installer sets "iface encf5f0 inet dhcp" although a static IP address was preseeded

[bugproxy]

== Comment: #0 - Thorsten Diehl - 2016-03-11 12:49:44 ==
I installed xenial with installer version 432 and a preseed file that has a IPv4 static configuration. Upon the initial boot after installation, everything is fine, system comes up with network. When I perform a reboot, the network service waits for "something" and prints continuously messages aka "A start job is running for Raise network interfaces (3min 14s / 5min)". After that, the network is up.
I found, that it was waiting for DHCP responses. (attaching /var/log/syslog).
/etc/network/interfaces looks like this:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto encf5f0
iface encf5f0 inet static
 address 9.152.162.158
 netmask 255.255.252.0
 network 9.152.160.0
 broadcast 9.152.163.255
 gateway 9.152.160.1
 # dns-* options are implemented by the resolvconf package, if installed
 dns-nameservers 9.152.120.241
 dns-search boeblingen.de.ibm.com
/etc/network/interfaces.d/encf5f0 looks like this:
allow-hotplug encf5f0
iface encf5f0 inet dhcp
which seems to be the cause. After removing the second line, it worked as expected.

Not sure, whether this is the best approach. I just wanted to point to the root cause. But starting a dhcp client when you have a static IP address configured is definitely wrong.

== Comment: #2 - Thorsten Diehl <email address hidden> - 2016-03-11 12:55:54 ==
uname -r
4.4.0-12-generic

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2016-03-15 13:08 EDT-------
I have also seen this problem in an installation without preseed file. So this is not preseed-related.

[Dimitri John Ledkov (xnox)]

Hello,

Where did the:
/etc/network/interfaces.d/encf5f0
allow-hotplug encf5f0
iface encf5f0 inet dhcp

Come from? I don't believe installer, nor any default automation writes any files into interface.d directory. At install time, only /etc/network/interfaces file should be generated with is correct.

The preseed file comes without any network configuration information, I presume network configuration would have been done via paramfile.

Could you please attach /var/log/installer? And/or correct a crash report with $ apport-bug debian-installer and attach the resultant report to this bug report.

We need to find out how that interfaces.d/ snippet got created/written, as I'm failing to reproduce it.

[Dimitri John Ledkov (xnox)]

Status Incomplete, further information from the reporter is required.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2016-03-18 03:49 EDT-------
I have attached the files you asked for. I hope that apport contains the info you need, because when executing it, it said "dpkg-query: no packages found matching debian-installer", but it ran through.

[bugproxy (bugproxy)]

------- Comment (attachment only) From <email address hidden> 2016-03-18 03:45 EDT-------

[bugproxy (bugproxy)]

------- Comment (attachment only) From <email address hidden> 2016-03-18 03:46 EDT-------

[Dimitri John Ledkov (xnox)]

Yes, the apport report is good one, has loads of useful stuff.

1) I cannot find any evidance that ubuntu installer created the broken/unneeded file /etc/network/interfaces.d/encf5f0. To recover i recommend you to remove that file. Also note, if system is migrated and network configuration is changing post-install, system administrator is expected to update it accordingly.

2) Can you trace and find who and/or where is modifying files in /etc/network/interfaces.d ? Is there any automation, puppet/chef, administrators, humans creating it? I've checked multiple installs that we have have and none of them generate anything in interfaces.d subdirectory upon install.

3) Is this reporducible? If yes, how? Can you share the full paramfile used to boot the system? From the collected logs the boot kernel command line looks very weird:

Mar 18 07:15:47 kernel: [ 0.049063] Kernel command line: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

literary. Has it been tampered with or censored?

[Dimitri John Ledkov (xnox)]

Setting status to invalid / user-error, there are no indication that d-i is responsible for generating broken interface.d snippet, and thus awaiting clean bug reproducer that can be replicated independently of the reporter's environment.

[Dimitri John Ledkov (xnox)]

Oh, i may have a reproducer located.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2016-03-21 05:48 EDT-------
(In reply to comment #13)
> 2) Can you trace and find who and/or where is modifying files in
> /etc/network/interfaces.d ? Is there any automation, puppet/chef,
> administrators, humans creating it? I've checked multiple installs that we
> have have and none of them generate anything in interfaces.d subdirectory
> upon install.

No there's no automation in place that changes this file, nor does any human interfere here.

> 3) Is this reporducible? If yes, how? Can you share the full paramfile used
> to boot the system?

I was using an empty parmfile. I just executed a fully interactive manual installation on a zVM guest. Nothing special.

> From the collected logs the boot kernel command line
> looks very weird:
>
> Mar 18 07:15:47 kernel: [ 0.049063] Kernel command line:
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> @@@
>
> literary. Has it been tampered with or censored?

Not as far as I know. I attached the files exactly as they were produced.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2016-03-21 14:34 EDT-------
Dimitri,
could the parmfile be the problem? E.g., mine looks like this:

ro locale=C cio_ignore=all,!9,!f5f0-f5f2,!eb15,!1800-19ff
s390-netdevice/choose_networktype=qeth DEBCONF_DEBUG=5
s390-netdevice/qeth/choose=0.0.f5f0-0.0.f5f1-0.0.f5f2
s390-netdevice/qeth/port=0 s390-netdevice/qeth/layer2=true
netcfg/confirm_static=true netcfg/disable_dhcp=true
netcfg/get_ipaddress=9.152.162.158 netcfg/get_netmask=255.255.252.0
netcfg/get_gateway=9.152.160.1 netcfg/get_nameservers=9.152.120.241
netcfg/get_hostname=s8330008 netcfg/get_domain=boeblingen.de.ibm.com
network-console/password=******** network-console/password-again=********
preseed/url=http://bistro/ubuntu/tarball/s8330008.preseed

------- Comment From <email address hidden> 2016-03-22 12:22 EDT-------
When installation is complete, I checked /target/etc/network/interfaces.d/ before reboot - it was empty:

~ # ls -l /target/etc/network/interfaces.d/
~ #

This explains, why the very first reboot works as expected. During the first reboot after installation, when network is already up, somebody adds the file encf5f0 to /etc/network/interfaces.d/, containing the inappropriate dhcp statement.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2016-03-22 12:48 EDT-------
OK, I found the cause. :-)

/lib/systemd/system/ubuntu-snappy.firstboot.service writes the file /etc/network/interfaces.d/encf5f0 on first reboot - and write the dhcp statement also. See the attached strace log, line 274-283:
openat(AT_FDCWD, "/etc/network/interfaces.d", O_RDONLY|O_CLOEXEC) = 5
openat(AT_FDCWD, "/etc/network/interfaces.d/encf5f0.M1yTYCQL5bt5", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_CLOEXEC, 0644) = 6
write(6, "allow-hotplug encf5f0\niface encf5f0 inet dhcp\n", 46) = 46
fsync(6) = 0
futex(0x2aa3b1d73b0, FUTEX_WAKE, 1) = 1
renameat(AT_FDCWD, "/etc/network/interfaces.d/encf5f0.M1yTYCQL5bt5", AT_FDCWD, "/etc/network/interfaces.d/encf5f0") = 0
fsync(5) = 0
futex(0x2aa3b1d73b0, FUTEX_WAKE, 1) = 1
close(6) = 0
close(5)

ubuntu-snappy.firstboot.service must consider a static configuration of an interface, but it does not. Please fix this, if possible for the upcoming Beta version!

[bugproxy (bugproxy)]

------- Comment on attachment From <email address hidden> 2016-03-22 12:52 EDT-------

to create that output:

~# rm /var/lib/snappy/firstboot/stamp
~# rm /etc/network/interfaces.d/encf5f0
~# strace -o snappy-firstboot.strace.txt -s 50 snappy firstboot

[Thorsten Diehl (thorsten-diehl)]

By the way, this is (for sure) also reproducable on installer version 440. It is not caused by the installer, but ubuntu-snappy.firstboot

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

Default Comment by Bridge

[bugproxy (bugproxy)]

------- Comment (attachment only) From <email address hidden> 2016-03-18 03:45 EDT-------

[bugproxy (bugproxy)]

------- Comment (attachment only) From <email address hidden> 2016-03-18 03:46 EDT-------

[bugproxy (bugproxy)]

------- Comment on attachment From <email address hidden> 2016-03-22 12:52 EDT-------

to create that output:

~# rm /var/lib/snappy/firstboot/stamp
~# rm /etc/network/interfaces.d/encf5f0
~# strace -o snappy-firstboot.strace.txt -s 50 snappy firstboot

[Michael Vogt (mvo)]

The snappy first-boot must should not run on a normal ubuntu-system.

[Steve Langasek (vorlon)]

ubuntu-snappy should not write out its separate network interface config when installed on an Ubuntu classic system. mvo asked this to be filed as a critical bug against ubuntu-snappy.

In general, the ubuntu-snappy firstboot task does not apply to an Ubuntu classic system. While it sounds like the Snappy team will take steps to disable this in the future, as a workaround for new installs, we can make the installer touch /var/lib/snappy/firstboot/stamp on install.

[Steve Langasek (vorlon)]

The ubuntu server seed has been updated to work around this, by only pulling in ubuntu-snappy-cli instead of the ubuntu-snappy package. No workaround should be needed in debian-installer.

[Launchpad Janitor (janitor)]

This bug was fixed in the package ubuntu-snappy - 1.7.3+20160310ubuntu2

---------------
ubuntu-snappy (1.7.3+20160310ubuntu2) xenial; urgency=medium

  * Fix ubuntu-snappy-cli package to include snapd and its
    systemd files. But do ship the firstboot and boot-ok
    systemd files in ubuntu-snappy. LP: #1556241

 -- Michael Vogt <email address hidden> Wed, 23 Mar 2016 16:08:27 +0100

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2016-03-31 09:25 EDT-------
(In reply to comment #25)
> This bug was fixed in the package ubuntu-snappy - 1.7.3+20160310ubuntu2
>
> ---------------
> ubuntu-snappy (1.7.3+20160310ubuntu2) xenial; urgency=medium
>
> * Fix ubuntu-snappy-cli package to include snapd and its
> systemd files. But do ship the firstboot and boot-ok
> systemd files in ubuntu-snappy. LP: #1556241
>
> -- Michael Vogt <email address hidden> Wed, 23 Mar 2016 16:08:27 +0100

Fixed with latest installer (version 443), which installs ubuntu-snappy-cli only. Closed.