Date: Sat, 11 Jun 2011 10:19:34 -0700 From: Garrett Cooper <yanegomi@gmail.com> To: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: IPv4 broken on r222048 Message-ID: <BANLkTinJOMAF0aRgaeTAqrO6UUz3ADYrdg@mail.gmail.com> In-Reply-To: <BANLkTi=FYpy4K1Kwo%2BzPzr_TT=B5SJpr6w@mail.gmail.com> References: <BANLkTinWSP0ko69qi9Qca7O2=LRpSn19yw@mail.gmail.com> <6D37AF86-9C14-4824-96CA-55C86497DECD@lists.zabbadoz.net> <BANLkTi=PXebdMw9X7=WJ4ygZ6iom=TDJhA@mail.gmail.com> <4434466E-F4B0-47B1-98BF-80E4E495AA4C@lists.zabbadoz.net> <BANLkTikdy1effxAwiWOqoMwa989kKapm=g@mail.gmail.com> <66750835-22BE-4F95-8940-567D74BC0488@lists.zabbadoz.net> <828CAE62-9C52-40EF-9C6B-A412645DB347@gmail.com> <96924B71-E657-460A-B274-BB38DCA5713A@lists.zabbadoz.net> <BANLkTi=FYpy4K1Kwo%2BzPzr_TT=B5SJpr6w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 8, 2011 at 9:33 PM, Garrett Cooper <yanegomi@gmail.com> wrote: > On Wed, Jun 8, 2011 at 9:31 AM, Bjoern A. Zeeb > <bzeeb-lists@lists.zabbadoz.net> wrote: >> >> On Jun 8, 2011, at 4:25 PM, Garrett Cooper wrote: >> >>> On Jun 8, 2011, at 9:07 AM, "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbado= z.net> wrote: >>> >>>> On Jun 7, 2011, at 6:15 PM, Garrett Cooper wrote: >>>> >>>>>> I think I just found a good "recovery" idea -- I should disable the >>>>>> features with rescue builds. =A0That should give one a working >>>>>> /rescue/ifconfig in all cases and should be sufficient to recover? >>>>> >>>>> =A0That would be a good backup plan so people could at least avoid >>>>> painting themselves into a corner by accident. >>>> >>>> Can you confirm that >>>> http://people.freebsd.org/~bz/20110608-02-ifconfig-rescue.diff >>>> would work for you? >>>> >>>> One will still be screwed if doing it remotely without serial console = or >>>> keyb access, but with that there should be a way to recover. =A0Note t= hat >>>> the rc scripts also check the AF to be present and will not configure = them >>>> if not. >>> >>> Will do when I get back home. I rebuilt world and kernel a few times, r= einstalled, and I'm still running into the same issues (kern.features.inet = is missing), so something is really funky with the system. >>> >>> I'll look at my last buildkernel log, an if that doesn't turn up anythi= ng helpful try building GENERIC tonight and boot it to see what happens.. >>> >>> I'll let you know how the patch goes.. >> >> check with strings if you can find a __kern_features_inet > > =A0 =A0Is that the right string to look for? All I found was > sysctl__kern_features_children (despite the fact that I do actually > have OIDs hanging off of kern.features). > =A0 =A0BTW, objdump -x /boot/kernel/kernel | grep __kern_features_ turned > up a lot more data, but unfortunately inet isn't one of the missing > pieces between strings and objdump -x :/.. > =A0 =A0I checked opt_global.h and opt_inet.h and #define INET 1 is > present in opt_inet.h at least.. Nothing apparently fishy in the > buildkernel log either... but why isn't it pulling in headers from -I@ > or ${KERNBUILDDIR} (!). Also, why is /sys/conf/*.mk blantantly > ignoring my CFLAGS (I hardcoded /usr/obj/usr/src/sys/FALLOUT just for > kicks and it was clearly omitted from the cc calls I saw)?? I haven't > dug down that deep yet, but it would be interesting if someone knew > the answer to that question offhand. > =A0 =A0Just for grins I put... > > #ifndef INET > #error "you lose!" > #endif > > =A0 =A0... in in_proto.c and it didn't bail. So obviously it thinks it > has INET support. > =A0 =A0Time to try GENERIC. A fresh tree exhibited the problem as well with my custom KERNCONF (which has INET and INET6 support compiled in), whereas GENERIC with the same src.conf doesn't. I diff reduced my custom KERNCONF a bit with GENERIC and it's still not working (I stripped a bunch of unneeded drivers out of the configuration and load a handful as modules, e.g. aio, if_re, linux*), and still ran into problems. I wiped out /boot/$INSTKERNNAME and /boot/kernel (for some reason the symlink I setup wasn't there.. hmm). So I'll need to dig through the installkernel target in a bit to figure out why things weren't sane. Overall, this case is now closed. I'll post more findings in another thread when I find out why stuff was broken, if it wasn't a trivial PEBKAC issue. Thanks, -Garrett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTinJOMAF0aRgaeTAqrO6UUz3ADYrdg>