Openmoko Bug #2056: /etc/resolv.conf is empty on first boot

Openmoko Public Trac bugs at docs.openmoko.org
Mon Oct 6 18:53:18 CEST 2008


#2056: /etc/resolv.conf is empty on first boot
------------------------+---------------------------------------------------
    Reporter:  rwhitby  |        Owner:  julian_chu
        Type:  defect   |       Status:  new       
    Priority:  normal   |    Milestone:            
   Component:  Distro   |      Version:            
    Severity:  normal   |   Resolution:            
    Keywords:           |    Blockedby:            
Reproducible:  always   |     Blocking:            
------------------------+---------------------------------------------------

Comment(by newkirk):

 If wlan utilizes resolvconf, then resolvconf itself will ensure that the
 DNS servers associated with the wlan connection are used, NOT the DNS
 server(s) associated with usb0.  That's much of its purpose.

 Whatever active interface (assuming they all interact with resolvconf, not
 difficult) is highest in the list /etc/resolvconf/interface-order will
 have its DNS servers inserted in /etc/resolv.conf - lower-priority (lower
 in the list) interfaces will NOT, until/unless the higher-priority
 interface goes down. (Again, presuming it cooperates with resolvconf)

 The result is that usb0 tells resolvconf "use nameserver 192.168.0.254",
 and resolvconf sets up to use that nameserver initially.  Then eth0 comes
 online, and DHCP provides DNS, so eth0 tells resolvconf "use nameserver
 172.31.254.2", and resolvconf stuffs that into /etc/resolv.conf INSTEAD of
 192.168.0.254.  Then eth0 goes back down, and resolvconf knows to restore
 the nameserver associated with usb0, since no higher-priority interface is
 available.

 I agree that 192.168.0.200 as nameserver is just offloading the headache
 on the user, who must then deal with it in some fashion on the desktop -
 not entirely unreasonable for linux developers, but it IS entirely
 unreasonable for the run-of-the-mill phone user who just wants to upgrade
 some things.

 The 'simplest' solution is just to hardcode publicly-accessible caching
 DNS server(s) like opendns.org in etc/resolv.conf. But unless all
 interfaces leave it alone, it will still get broken when, for instance,
 GPRS ppp stuffs the cell-carrier's DNS servers in there, then purges them
 (or not!) on disconnect.

-- 
Ticket URL: <https://docs.openmoko.org/trac/ticket/2056#comment:3>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac


More information about the buglog mailing list