[Bug 1013843] Re: resolv.conf empty when doing PXE installations

Daniel Manrique daniel.manrique at canonical.com
Tue Jun 19 15:03:22 UTC 2012


Hi Thomas,

The late_command (or ubiquity's success_command) is run after the rest
of the installation has finished (I think it even runs after installing
the boot loader), but the system doesn't reboot prior to running it.

I did the test you requested on a Precise system. Here's what I do (and
also what I did on Quantal to produce the output on comment #3):

- Start the PXE installation process
- As the installation starts (e.g. the system says creating filesystem), I go to a virtual console
- From here, cat /etc/resolv.conf shows the file I posted in the original report (on Quantal) or a correctly-poopulated file (on Precise; I'll attach this below).
- I run the script you provided, using "script" to capture the output, e.g. 
  script output.txt
  ./thomas-script.sh
- I put the output.txt file on a USB stick and shuttle back to my laptop :0

So as promised, here's the result of running all those commands on a
Precise installation. I see resolv.conf has correct DNS information (as
taken from DHCP) and I also notice it's a symlink:

Script started on Tue 19 Jun 2012 10:55:26 AM EDT
root at ubuntu:/mnt# bash script.sh 
total 4
-rw-r--r-- 1 root root   0 Jun 19 10:54 enable-updates
drwxr-xr-x 2 root root  60 Jun 19 10:53 interface
-rw-r--r-- 1 root root 197 Jun 19 10:54 resolv.conf
total 4
-rw-r--r-- 1 root root 113 Jun 19 10:53 casper
=== /run/resolvconf/interface/casper ===
# /etc/resolv.conf
# Autogenerated by casper
search canonical.com
domain canonical.com
nameserver 10.153.104.60

=== /etc/resolvconf/resolv.conf.d/base ===
=== /etc/resolvconf/resolv.conf.d/head ===
# 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
[main]
plugins=ifupdown,keyfile
dns=dnsmasq

[ifupdown]
managed=false
cat: /run/nm-dns-dnsmasq.conf: No such file or directory
root at ubuntu:/mnt# cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual

root at ubuntu:/mnt# cat /etc/resolv.conf 
# 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 10.153.104.60
search canonical.com
root at ubuntu:/mnt# ls -l /etc/resolv.conf 
lrwxrwxrwx 1 root root 29 Apr 25 12:04 /etc/resolv.conf -> ../run/resolvconf/resolv.conf
root at ubuntu:/mnt# exit
Script done on Tue 19 Jun 2012 10:55:59 AM EDT

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to resolvconf in Ubuntu.
https://bugs.launchpad.net/bugs/1013843

Title:
  resolv.conf empty when doing PXE installations

Status in “resolvconf” package in Ubuntu:
  New
Status in “ubiquity” package in Ubuntu:
  New

Bug description:
  Quantal daily image as of 20110615.
  resolvconf 1.65ubuntu4.

  In our environment we do network installs via PXE booting. We noticed
  that name resolution wasn't working during the late_command phase
  (e.g. any apt-get install operations in the ubiquity/late_command
  fail).

  PXE passes IP information (including DNS) to the kernel, and in this
  case, the entry in /etc/network/interfaces is:

  auto eth0
  iface eth0 inet manual

  What we found is that, with this configuration, /etc/resolv.conf will
  be unconfigured (even though DHCP *did* send DNS information):

  # 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

  if I change the /etc/network/interfaces entry  to

  auto eth0
  iface eth0 inet dhcp

  then I run:

  sudo ifup --force eth0

  then /etc/resolv.conf is populated correctly and DNS resolution starts
  working.

  This would be a regression from Precise, where the resolv.conf file
  gets correctly populated even if the interface is set as manual.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1013843/+subscriptions




More information about the foundations-bugs mailing list