during recovery mode, enable network failed due to /etc/resolv.conf not being present

Bug #1682637 reported by themusicgod1 on 2017-04-13
This bug affects 13 people
Affects Status Importance Assigned to Milestone
friendly-recovery (Ubuntu)
Status tracked in Bionic
Eric Desrochers
Eric Desrochers

Bug Description

Something went wrong that required me to boot to recovery mode via grub. The important part here, is that while I got as far as the recovery screen asking to "Enable Networking" and other options fsck filesystems, drop to root shell, etc.

and selected "Enable Networking":

the result was:

grep: /etc/resolv.conf: No such File or directory.

Unknown group "power" in message bus configuration file.

(Networking did not enable, leaving me stranded at root shell without network which would have made adding/removing packages to troubleshoot easier)

Ubuntu: zesty 17.04
Linux: Linux Hedy 4.10.0-19-generic #21-Ubuntu SMP Thu Apr 6 17:04:57 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
network-manager: 1.4.4-1ubuntu3

ProblemType: Bug
DistroRelease: Ubuntu 17.04
Package: network-manager 1.4.4-1ubuntu3
ProcVersionSignature: Ubuntu 4.10.0-19.21-generic 4.10.8
Uname: Linux 4.10.0-19-generic x86_64
ApportVersion: 2.20.4-0ubuntu4
Architecture: amd64
CurrentDesktop: XFCE
Date: Thu Apr 13 16:40:19 2017
EcryptfsInUse: Yes
 # interfaces(5) file used by ifup(8) and ifdown(8)
 auto lo
 iface lo inet loopback
InstallationDate: Installed on 2014-07-09 (1009 days ago)
InstallationMedia: Ubuntu-GNOME 14.10 "Utopic Unicorn" - Alpha amd64 (20140708)
 default via dev wlan1 proto static metric 600 dev lxcbr0 proto kernel scope link src linkdown dev lxcbr0 scope link metric 1000 linkdown dev wlan1 proto kernel scope link src metric 600

SourcePackage: network-manager
UpgradeStatus: Upgraded to zesty on 2017-04-13 (0 days ago)
 lxcbr0 bridge connected /org/freedesktop/NetworkManager/Devices/3 lxcbr0 46595dd8-757b-4d93-ade3-c066f72d9e2e /org/freedesktop/NetworkManager/ActiveConnection/0
 wlan1 wifi connected /org/freedesktop/NetworkManager/Devices/2 Brisbane House 2b25e748-f9c5-4c84-9fe6-0f64071fcf0b /org/freedesktop/NetworkManager/ActiveConnection/1
 eth1 ethernet unavailable /org/freedesktop/NetworkManager/Devices/1 -- -- --
 lo loopback unmanaged /org/freedesktop/NetworkManager/Devices/0 -- -- --
 running 1.4.4 connected started full enabled enabled enabled enabled disabled

Related branches

themusicgod1 (themusicgod1) wrote :
Launchpad Janitor (janitor) wrote :

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

Changed in network-manager (Ubuntu):
status: New → Confirmed
aleandro (aleandrodasilva) wrote :

Here the same. I upgraded from 16.10 to 17.04. Network is not active. I cannot surf in internet.

themusicgod1 (themusicgod1) wrote :

but did you boot into recovery mode in grub? Might be a different bug if not

aleandro (aleandrodasilva) wrote :

I booted into recovery to see if there the network was working again.

It is a bug of Networkmanager. Probably the username 'power' doesn't affect the connection.


sudo -H gedit /etc/NetworkManager/NetworkManager.conf

At the bottom of this file, copy and paste the following:


Restart the networkmanager

sudo service network-manager restart

themusicgod1 (themusicgod1) wrote :

So editing NetworkManager.conf didn't help.
I did some digging though and found that in /etc/dbus-1/system.d in element busconfig in org.freedesktop.thermald.conf:

        <policy group="power">
                <allow send_destination="org.freedesktop.thermald"/>
                <allow receive_sender="org.freedesktop.thermald"/>

this is owned by thermald

thermald: 1.5.4-4

Launchpad Janitor (janitor) wrote :

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

Changed in thermald (Ubuntu):
status: New → Confirmed
starkus (starkus) wrote :

Booting to recovery mode and trying to enable networking tells me Unknown group "power" in message bus configuration file.

And networking will not be available running 17.04 ubuntu-gnome.

Daniel Pietrucha (texar) wrote :

To to establish connection run:

dpkg-reconfigure resolvconf

eth connection is working in my case

Hannu N (garbage-collector-) wrote :

I can confirm "Daniel Pietrucha (texar)"'s experience.

Boot into the recovery console and run
# dpkg-reconfigure resolvconf

# apt update # worked immediately afterwards.

Domizio Demichelis (domizio) wrote :

None of the above worked here! Without the /etc/resolv.conf nothing works obviously, then the dpkg-reconfigure resolvconf does nothing (i.e. there is still no file after running it. Adding it manually solved a part of the problem, but the Unknown group "power" still blocks starting of the network. How to fix that one?

Woodrow Shen (woodrow-shen) wrote :

The issue still can be reproduced by 18.04.

Woodrow Shen (woodrow-shen) wrote :

Giving the working note what I'm doing currently:

In order to analyze the issue, I tried to remove the /etc/resolv.conf in the normal mode and traced the syslog if any systemd service restored the file. What I observed is NM will go through this line of writing DNS, and reported the warning from calling /etc/resolvconf/update.d/libc:

<info> [1516604239.0578] dns-mgr: Writing DNS information to /sbin/resolvconf
warning "/etc/resolv.conf is not a symbolic link to /run/resolvconf/resolv.conf"

I'm thinking the /etc/resolv.conf will be dynamically recreated, and then NM moved on to finish its service (so NM is able to keep alive). However, under the recovery mode, the NM can't normally start its service and exit due to catch the signal SIGTERM (not sure if it's related to nm_dispatcher). So seems like we have two problems here:

1. why does NM fail to start
2. why does NM not try to call /etc/resolvconf/update.d/libc to restore the file in the recovery mode

Woodrow Shen (woodrow-shen) wrote :

Above should fix the situation as I just found out the resolvconf service seems not be triggered when recovery mode is applied...

If resolvconf.service can be triggered normally, then it would execute "/sbin/resolvconf --enable-updates". This creates a symbolic link /etc/resolv.conf for /run/resolvconf/resolv.conf. Basically the step is a implementation of "dpkg-reconfigure resolvconf".

Woodrow Shen (woodrow-shen) wrote :

The issue is not NM, but in the friendly-recovery, and I already prepare the patch to be reviewed.

Changed in friendly-recovery (Ubuntu):
assignee: nobody → Woodrow Shen (woodrow-shen)
Woodrow Shen (woodrow-shen) wrote :

My understanding is recovery-mode should do a task to update its resolv.conf when "Enable networking" option was chosen,
just like normal boot will trigger resolvconf service to update resolv.conf (so /sbin/resolvconf calls /etc/resolvconf/update.d/libc).
What I patch the friendly-recovery is just to add one line, see the patch I attached.

Changed in network-manager (Ubuntu):
status: Confirmed → Opinion
Changed in thermald (Ubuntu):
status: Confirmed → Opinion
Changed in friendly-recovery (Ubuntu):
status: New → Confirmed

The attachment "fix-resolvconf-not-found.patch" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

tags: added: patch
Changed in network-manager (Ubuntu):
status: Opinion → Invalid
Changed in thermald (Ubuntu):
status: Opinion → Invalid
tags: added: rls-bb-incoming
Changed in friendly-recovery (Ubuntu):
status: Confirmed → Triaged
importance: Undecided → High
tags: added: xenial
tags: added: id-5a6f2ec772ac06a254f2247f
no longer affects: network-manager (Ubuntu)
no longer affects: thermald (Ubuntu)
Steve Langasek (vorlon) on 2018-03-15
tags: removed: rls-bb-incoming
tags: added: id-5ab94ce5cbdbbc3e7f60d704
Changed in friendly-recovery (Ubuntu Bionic):
assignee: Woodrow Shen (woodrow-shen) → nobody
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package friendly-recovery - 0.2.38

friendly-recovery (0.2.38) unstable; urgency=medium

  * Make friendly-recovery block the systemd emergency / rescue shell
    modes. LP: #1662137
  * Bump debhelper and starndards version, drop dh-systemd build-dep.
  * Support activating networking using systemd units for resolved,
    networkd, NetworkManager, ifupdown. LP: #1682637

 -- Dimitri John Ledkov <email address hidden> Thu, 29 Mar 2018 14:38:38 +0100

Changed in friendly-recovery (Ubuntu Bionic):
status: Triaged → Fix Released
Eric Desrochers (slashd) on 2018-04-20
Changed in friendly-recovery (Ubuntu Artful):
importance: Undecided → Medium
Changed in friendly-recovery (Ubuntu Xenial):
importance: Undecided → Medium
assignee: nobody → Eric Desrochers (slashd)
Changed in friendly-recovery (Ubuntu Artful):
assignee: nobody → Eric Desrochers (slashd)
status: New → In Progress
Changed in friendly-recovery (Ubuntu Xenial):
status: New → In Progress
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers