resolv.conf not updated correctly for interfaces configured in initramfs
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| | open-iscsi (Ubuntu) |
High
|
Martin Pitt | ||
| | systemd (Ubuntu) |
High
|
Unassigned | ||
Bug Description
maas images utilize cloud-initramfs
* /etc/network/
* kernel command line 'ip=' convince the initramfs to bring up networking using 'ipconfig'
example: ip=::::
* ipconfig writes files in /run/net-*.conf for each interface it configures.
* cloud-initramfs
end result is that after the move to real root, /etc/network/
| ## This file is generated by cloud-initramfs
| auto lo
| iface lo inet loopback
| manual eth0
| iface eth0 inet dhcp
| dns-nameservers 192.168.64.3
| dns-search maas
resolvconf seems not to be working as well as it should be. In vivid (now using systemd), I have only the resolvconf header in the file.
in all other supported ubuntu releases, doing the above results in functional resolv.conf via resolv.conf. Seen here from trusty:
| # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
| # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
| nameserver 192.168.64.3
Related Bugs:
* bug 1432821: something deleting /run/network after during boot
* bug 1463461: resolvconf not updated by /lib/systemd/
* bug 1501033: transient error results in /etc/resolv.conf not populated in iscsi root
ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: resolvconf 1.69ubuntu1.1
ProcVersionSign
Uname: Linux 3.19.0-9-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.7
Architecture: amd64
Date: Mon Mar 16 20:42:24 2015
PackageArchitec
ProcEnviron:
TERM=vt102
PATH=(custom, no user)
XDG_RUNTIME_
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: resolvconf
UpgradeStatus: No upgrade log present (probably fresh install)
Related branches
| Thomas Hood (jdthood) wrote : | #2 |
| Thomas Hood (jdthood) wrote : | #3 |
I just tried to reproduce the bug in Ubuntu 14.10 by editing the file /etc/network/
# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback
manual eth0
iface eth0 inet dhcp
dns-nameservers 1.2.3.4
dns-search maas
I do `ifup eth0` and get the following in /etc/resolv.conf (content actually at /run/resolvconf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 1.2.3.4
nameserver 192.168.1.254
search maas mydomain
(The nameserver address 192.168.1.254 and search domain "mydomain" come in via DHCP.)
This is exactly what I would expect. The bug must arise from something in your system that differs from mine.
AIUI you can still boot Vivid using Upstart. If you boot using Upstart, does the bug still occur?
| Scott Moser (smoser) wrote : | #4 |
Thomas,
Yeah, you're right about 'manual <devname>'. Seems unnecessary.
wrt you not reproducing it, I'm seeing the issue
a.) when using systemd as init
b.) when configuring networking from the initramfs
the interface being used is already up, and in this case cant be bounced when init runs from the root. It can't be bounced because its on iscsi.
| Scott Moser (smoser) wrote : | #5 |
possibly related...
likely related, I find that on this system
$ ls /run/network/
ls: cannot access /run/network/
$ ifquery --state --all
Segmentation fault (core dumped)
$ sudo ifquery --state --all
$ ifconfig eth0
eth0 Link encap:Ethernet HWaddr 52:54:00:12:34:98
inet addr:192.168.64.112 Bcast:192.
inet6 addr: fe80::5054:
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:14050 errors:0 dropped:0 overruns:0 frame:0
TX packets:13591 errors:0 dropped:0 overruns:0 carrier:0
RX bytes:152616463 (152.6 MB) TX bytes:1138294 (1.1 MB)
$ ls /run/network
ls: cannot access /run/network: No such file or directory
On an upstart system, /etc/init/
I suspect we dont have such in a systemd system.
| Scott Moser (smoser) wrote : | #6 |
Tomorrow I'll look into adding code in systemd package that would basically do what the open-iscsi job did previously.
| Scott Moser (smoser) wrote : | #7 |
I've made this affect systemd as that is where I have the fix for it.
I could fix in open-iscsi as it was in upstart, but I think adding general infrastructure that considers open-iscsi is more sane than open-iscsi playing around with tricking ifupdown.
| affects: | resolvconf (Ubuntu) → systemd (Ubuntu) |
| Changed in systemd (Ubuntu): | |
| importance: | Undecided → High |
| status: | New → Confirmed |
| Scott Moser (smoser) wrote : | #8 |
| tags: | added: patch |
| Scott Moser (smoser) wrote : | #9 |
-- adt --
Note, my adt runs so far have failed each time (and after 30+ minutes)
The last last failure due to guest running out of space, so changed to 20G
(default 4)
# per http://
sudo addgroup kvm
sudo adduser $(id --user --name) kvm
sudo apt-get install -qy autopkgtest qemu-system qemu-utils python-distro-info genisoimage
adt-buildvm-
adt-run systemd_
time adt-run --output-
--
--debug systemd_
qemu --cpus=4 --ram-size=8192 \
~
-- physical server system booted (cloud-init installed) --
system has 2 nics, both could dhcp. only one configured to auto.
system booted fine.
both 'systemctl status ifup@eth0' and 'ifup@eth1' show 'success'
EN had:
auto eth0
iface eth0 inet dhcp
iface eth1 inet dhcp
-- cloud image on openstack --
- boot system, rm -Rf /var/lib/cloud /var/log/cloud*,
apt-
sudo reboot
system booted fine
systemctl status ifup@eth0
-- laptop booting test --
- boot system with eth0 connected, but not listed in /etc/network/
- [P] network-manager should bring up network interface on login
- [P] ifup@eth0 service should succeed but do nothing
$ systemctl status ifup@eth0
● <email address hidden> - ifup for eth0
Loaded: loaded (/lib/systemd/
Active: active (exited) since Thu 2015-03-19 09:41:21 EDT; 3min 26s ago
Process: 557 ExecStart=
Main PID: 557 (code=exited, status=0/SUCCESS)
CGroup: /<email address hidden>
Mar 19 09:41:21 brickies systemd[1]: Starting ifup for eth0...
Mar 19 09:41:21 brickies systemd[1]: Started ifup for eth0.
- boot system with 'iface eth0 inet dhcp' in ENI but not auto
- [P] service should show success but no network brought up
- [P] network-manager should not bring up network:
$ systemctl status ifup@eth0
● <email address hidden> - ifup for eth0
Loaded: loaded (/lib/systemd/
Active: active (exited) since Thu 2015-03-19 10:01:16 EDT; 1min 6s ago
Process: 531 ExecStart=
Main PID: 531 (code=exited, status=0/SUCCESS)
CGroup: /<email address hidden>
Mar 19 10:01:16 brickies systemd[1]: Starting ifup for eth0...
Mar 19 10:01:16 brickies systemd[1]: Started ifup for eth0.
- boot system with 'iface eth0 inet dhcp' in ENI + 'auto eth0'
- [P] service should show success and network brought up
- [P] network-manager should not bring up network:
$ systemctl status ifup@eth0
● <email address hidden> - ifup for eth0
Loaded: loaded (/lib/systemd/
| Launchpad Janitor (janitor) wrote : | #10 |
This bug was fixed in the package systemd - 219-4ubuntu7
---------------
systemd (219-4ubuntu7) vivid; urgency=medium
* use systemd-
of auto or hotplug devices. This allows iscsi root volumes
to work again. (LP: #1432829)
* debian/
upstart packaging bug 1422681 is resolved.
-- Scott Moser <email address hidden> Thu, 19 Mar 2015 11:43:14 -0400
| Changed in systemd (Ubuntu): | |
| status: | Confirmed → Fix Released |
| summary: |
- resolvconf not updated correctly for interfaces configured in initramfs + resolv.conf not updated correctly for interfaces configured in initramfs |
| Martin Pitt (pitti) wrote : | #11 |
Thanks Scott for fixing this! However, this is awkward to have in systemd: it meddles with ifupdown's and open-iscsi's internals and has open-iscsi specific knowledge which really belongs into open-iscsi itself. I. e. open-iscsi should ship the counterpart of debian/
| Changed in open-iscsi (Ubuntu): | |
| status: | New → Triaged |
| Martin Pitt (pitti) wrote : | #12 |
I uploaded a new open-iscsi which uses the same logic for short-circuiting ifupdown for the upstart job and a new systemd ifup@.service drop-in. With that we keep the logic in one place.
| Changed in open-iscsi (Ubuntu): | |
| assignee: | nobody → Martin Pitt (pitti) |
| importance: | Undecided → High |
| status: | Triaged → Fix Committed |
| Martin Pitt (pitti) wrote : | #13 |
I'll revert the systemd 219-4ubuntu7 changes on the next upload.
| Changed in systemd (Ubuntu): | |
| status: | Fix Released → Invalid |
| Launchpad Janitor (janitor) wrote : | #14 |
This bug was fixed in the package open-iscsi - 2.0.873-3ubuntu11
---------------
open-iscsi (2.0.873-3ubuntu11) vivid; urgency=medium
* Factor out logic from debian/
into debian/
* Add debian/
net-
-- Martin Pitt <email address hidden> Fri, 27 Mar 2015 09:51:05 +0100
| Changed in open-iscsi (Ubuntu): | |
| status: | Fix Committed → Fix Released |
| description: | updated |
First a parenthetical remark. According to interfaces(5) the "manual" keyword is used exclusively in the "method" field, as in `iface eth0 inet manual`. But in your example you use it at the beginning of a line. Perhaps you think that in that context "manual" means the opposite of "auto" (non-auto?) but so far as I can tell by reading the manual page and the source code it does not have any meaning in that context. If a logical interface is not declared as "auto" then it is non-auto and there is no way affirmatively to declare a logical interface as non-auto. If I am right, please see to it that the software you are using gets fixed so that it doesn't write out meaningless "manual ..." lines. If I am not right then please let me know. :)
The submitter wrote:
| ## This file is generated by cloud-initramfs
| auto lo
| iface lo inet loopback
| manual eth0
| iface eth0 inet dhcp
| dns-nameservers 192.168.64.3
| dns-search maas