IPv4 broken on r222048

[Garrett Cooper]

On Wed, Jun 8, 2011 at 9:33 PM, Garrett Cooper <yanegomi at gmail.com> wrote:
> On Wed, Jun 8, 2011 at 9:31 AM, Bjoern A. Zeeb
> <bzeeb-lists at 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 at lists.zabbadoz.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.  That should give one a working
>>>>>> /rescue/ifconfig in all cases and should be sufficient to recover?
>>>>>
>>>>>  That 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.  Note that
>>>> 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, reinstalled, 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 anything 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
>
>    Is 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).
>    BTW, 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 :/..
>    I 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.
>    Just for grins I put...
>
> #ifndef INET
> #error "you lose!"
> #endif
>
>    ... in in_proto.c and it didn't bail. So obviously it thinks it
> has INET support.
>    Time 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