/etc/resolv.conf is empty on snappy

Bug #1620559 reported by Oliver Grawert
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Snappy
Fix Released
Critical
Unassigned
systemd (Ubuntu)
Fix Released
Undecided
Unassigned
Xenial
Fix Released
High
Martin Pitt

Bug Description

we currently have no working resolver on snappy installs, /etc/resolv.conf is the boilerplate one.

on the low level we seem to have DNS from the DHCP server though

ogra@localhost:~$ grep -r DNS= /run/systemd/netif
/run/systemd/netif/leases/3:DNS=217.237.150.115 217.237.151.205
/run/systemd/netif/links/3:DNS=217.237.150.115 217.237.151.205
/run/systemd/netif/links/3:MDNS=no
ogra@localhost:~$

SRU INFORMATION
===============
Fix: https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=ubuntu-xenial&id=0a96feb1561

Test case:

I cannot reproduce this in a VM or normal laptop, this is somehow specific to the reporter's hardware/DHCP server config.

 * Configure systemd-networkd for an ethernet interface, either directly or via netplan; remove it from /etc/network/interfaces{,.d}
 * Reboot.
 * With current xenial's systemd, if /run/systemd/netif/state does not have "DNS=" then /etc/resolv.conf will not have any nameserver.
 * With the proposed update, /etc/resolv.conf should have the DHCP-provided nameserver.

Regression potential: Low; in 16.04 LTS we do not configure networkd by any Ubuntu tool, so networkd is not widely used there yet. For systems which do use it it could happen that interface-specific DNS servers now appear in resolv.conf that should not be global -- but we do not have anything that would configure or obey this setup in 16.04.

Oliver Grawert (ogra)
Changed in snappy:
importance: Undecided → Critical
Changed in systemd (Ubuntu):
importance: Undecided → Critical
Revision history for this message
Martin Pitt (pitti) wrote :

This is a bug in systemd-networkd-resolvconf-update.service, apparently /run/systemd/netif/state does not always get the received DNS servers. This does not affect yakkety any more as this hackish thing is gone entirely and replaced by resolved.

But it is still relevant for xenial which snappy is based on, so we need to SRU it there.

Quick fix for snappy image builds until this is SRUed:

   sed '/^ExecStart=/ s!netif/state!& /run/systemd/netif/leases/* | sort -u!' /lib/systemd/system/systemd-networkd-resolvconf-update.service

Changed in systemd (Ubuntu):
status: New → Fix Released
Changed in systemd (Ubuntu Xenial):
status: New → In Progress
importance: Undecided → High
Changed in systemd (Ubuntu):
importance: Critical → Undecided
Changed in systemd (Ubuntu Xenial):
assignee: nobody → Martin Pitt (pitti)
Martin Pitt (pitti)
tags: added: hw-specific
Martin Pitt (pitti)
description: updated
Martin Pitt (pitti)
description: updated
Revision history for this message
Andy Whitcroft (apw) wrote : Please test proposed package

Hello Oliver, or anyone else affected,

Accepted systemd into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/229-4ubuntu8 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in systemd (Ubuntu Xenial):
status: In Progress → Fix Committed
tags: added: verification-needed
Revision history for this message
Oliver Grawert (ogra) wrote :

works fine now

tags: added: verification-done
removed: verification-needed
Revision history for this message
Martin Pitt (pitti) wrote : Update Released

The verification of the Stable Release Update for systemd has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package systemd - 229-4ubuntu8

---------------
systemd (229-4ubuntu8) xenial-proposed; urgency=medium

  * Queue loading transient units after setting their properties. Fixes
    starting VMs with libvirt. (LP: #1529079)
  * Connect pid1's stdin/out/err fds to /dev/null also for containers. This
    fixes generators which expect a valid stdout/err fd in some container
    technologies. (LP: #1608953)
  * 73-usb-net-by-mac.rules: Do not run readlink for *every* uevent, and
    merely check if /etc/udev/rules.d/80-net-setup-link.rules exists.
    A common way to disable an udev rule is to just "touch" it in
    /etc/udev/rule.d/ (i. e. empty file), and if the rule is customized we
    cannot really predict anyway if the user wants MAC-based USB net names or
    not. (LP: #1615021)
  * systemd-networkd-resolvconf-update.service: Also pick up DNS servers from
    individual link leases, as they sometimes don't appear in the global
    ifstate. (LP: #1620559)

 -- Martin Pitt <email address hidden> Tue, 06 Sep 2016 14:16:29 +0200

Changed in systemd (Ubuntu Xenial):
status: Fix Committed → Fix Released
Oliver Grawert (ogra)
Changed in snappy:
status: New → Incomplete
status: Incomplete → Fix Released
Revision history for this message
Nikos Paraschou (niparasc) wrote :

gh

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.