On Fri, May 22, 2015 at 11:15:00AM +0200, Norbert Lange wrote: > Hi Ron > > 2015-05-22 2:08 GMT+02:00 Ron <r...@debian.org>: > > > > From a sample space of two, Networkmanager appears to be emerging as > > the common culprit ... > > Quite possibly its Networkmanager fault, but its strange that only > tftp-hpa is affected.
It's not only tftp-hpa that would get burned by this. Any network using service that needs to resolve or use an address would fail in exactly the same way if started before your network is up. And lots of them do. This isn't a new problem, you're just lucky that it's the only thing that you are seeing it on. > I also use fixed ip/dns via the gnome gui (what exactly the gui > affects and how NM is hooked into it is unclear to me). Which is probably a big part of the problem here. The getaddrinfo(3) call is failing because your network is not yet configured, and anything which calls that (which means just about everything with IPv6 support that is even half sane) would fail in the same way that this does if started at the same point in your boot sequence. As would anything that tries to bind to a specific address before the interface it is assigned to is up. > At home I have two systems where I killed NM and used the interfaces > config file, exactly because this thing caused me alot trouble already You could do a lot worse than do the same on this system too then :) > And I am far from the only one with the problem, I found this report > from another sites. > And Ubuntu has this issue too: > https://bugs.launchpad.net/ubuntu/+source/tftp-hpa/+bug/972845 "Upstart in broken boot dependency shocker. film@11" The fix suggested there is more correct though, since it tried to address the broken boot dependency, not hack around it by exploiting an implementation detail of the tftpd configuration which will only "work" for some users. > I can did out more references from my browser cache when I`m back at > work next week "me too" references aren't really helpful here. The problem isn't a mystery and the solution to it isn't a popularity contest. Unless the broken boot dependency is fixed in NM, this problem will still exist. Changing the default config so that it doesn't effect *you* as a side-effect won't make it go away for other people who need a different config. I've left this bug open here because the question of whether the old default (which has been what it is for much longer than I've been maintaining this package) should be changed is an open one worth some further thought -- but what we change it to if we do doesn't really depend on "will this be broken with NM" because until NM is fixed it will *always* be broken with some/most valid tftpd configurations (and it won't be the only thing that is). The answer to that needs to depend purely on "what is sane/safe for a default tftpd install". We can note there are workarounds with varying degrees of ugly that may work for some people in some circumstances, but we really can't "fix" NM from here - that needs to happen in NM itself. Cheers, Ron -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
