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

[Openmoko Public Trac]

#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):

 Sorry, I didn't understand you were speaking to the case where NO valid
 network connection exists, but route and DNS via usb0 were still active.

 I ran some tests with USB unplugged (Raster's latest image with FSO feed,
 though I expect 2007.x and 2008.x would be very similar) and I get these
 times with 'opkg update' (with two 'dead' feeds where I've not removed
 unused 'my-distribution.org' entries):

 160 secs - usb0 up, dns pointing out usb0
 40 secs - usb0 up, /etc/resolv.conf empty
 5 secs - usb0 down with or without /etc/resolv.conf populated

 So generally speaking, emptying resolv.conf leads to 25% the wait,
 bringing usb0 down leads to 3%.  (oh, and of that 5 secs about 4 is opkg
 setting up before it tries to communicate - same for all scenarios - it
 fails each connection attempt faster than it can print the status to the
 screen with no route available)

 The flipside is that if the default is to have nothing in /etc/resolv.conf
 when only usb0 is up, then there will be a stream of complaints and bug
 reports that USB networking is broken, etc.  We can't require manual
 insertion of DNS each time a user plugs into a host computer through which
 they wish to route.

 So the 'real' solution as I see it is to have resolv.conf populated
 'correctly' for usb0, but bring usb0 down when no usb cable is present.
 (though I don't see a simple way to achieve that automatically ATM, only
 manually with a widget or icon)  Without that, I don't see a way to "make
 both sides happy"... :(

 Another possibility, addressing the specific opkg/assassin case, is to add
 a test to opkg_download() that tries to ping the default gateway, and dies
 if it's unreachable.  Which seems sensible to me regardless.  ;)

 j

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