On 06/15/2012 12:58 PM, Camaleón wrote: > On Fri, 15 Jun 2012 12:18:03 -0400, Gilbert Sullivan wrote: > >> On 06/15/2012 10:35 AM, Camaleón wrote: > >>> Anyway, I'd also run the following tests: >>> >>> 1/ Just for testing purposes, you can momentary disable wicd and test >>> with a static IP configuration defined at "/etc/network/interfaces". If >>> this boost the booting process then we can center exclusively in WICD >>> (I still have my doubts about what is causing this). >>> >>> (if 1/ makes no difference, stop here as we will have to find another >>> culprit other than WICD, otherwise proceed with 2/) >>> >>> >> Yup, I set Wicd up to not start at boot, and I configured static IP in >> /etc/network/interfaces. At the next reboot, I saw the same 60 sec. >> delay in configuring interface and the 60 sec. delay for starting MTA. > > Wow :-O > > Then forget about WICD, profiles and all that... if the traditional ifup > method is exposing the same behaviour this has to be something else. > >>> As you are running wheezy (and considering the freeze is going to be in >>> about a few weeks) consider in opening a bug report. >>> >>> >> I'm thinking of doing that. I guess I'll file a bug against netscript. >> The problem may not be there, but it sure as heck started when the >> recent netscript upgrade was installed. > > I'm also running wheezy (and removed the said package which had to > reinstall) but I'm using N-M and I haven't noticed this problem :-? > >>>> In the meantime, until I get a chance to really get into it, I can >>>> just continue to use <Ctrl>+<C> at the "configuring interface" prompt. >>>> The system boots up as quickly as normal, and everything appears to be >>>> working. >>> >>> If Exim4 is started afterwards, then there should be no other gotchas. >>> >>> >> Yes, Exim4 is starting up properly, and everything seems to be going >> well. >> >> I'll run bugreport and file against netscript to see what happens. >> >> Thank you for your ideas, and I'll return to this thread when I have any >> kind of information. > > Ok, keep us informed. I feel curious about what's going on here :-) >
Just a note about an observation. Just for grins -- even though name resolution was working fine -- I checked the contents of /etc/resolv.conf. They are listed below: ----------------------------8<---------------------------- # 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 127.0.0.1 search wp.comcast.net ----------------------------8<---------------------------- This is with the system connected at a location that does use Comcast as its ISP. But the contents of this file are not at all what I'd expect. I tried adding dns-nameservers 208.67.222.222 208.67.220.220 to /etc/network/interfaces. Rebooting made no difference in the contents of /etc/resolv.conf. Is that because something weird is going on, or because the changes in netscript that happened at the time of the update have changed the way resolvconf works? I suspect the latter due to other information available. I'll have to do some reading. But my initial glance at the man pages doesn't provide me any insight. Other Debian testing systems I'm running that are functioning normally -- but which don't travel around like this one -- show the same contents of /etc/resolv.conf -- with the exception of the final line. I have to admit I'm stumped right now. I'm going to try to get time this weekend to try to learn something about this. Best regards, Gilbert -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fdbcbcb.4010...@comcast.net
