IPv4 broken on r222048
Bjoern A. Zeeb
bzeeb-lists at lists.zabbadoz.net
Tue Jun 7 18:13:21 UTC 2011
On Jun 7, 2011, at 6:00 PM, Garrett Cooper wrote:
> On Tue, Jun 7, 2011 at 10:41 AM, Bjoern A. Zeeb
> <bzeeb-lists at lists.zabbadoz.net> wrote:
>> On Jun 7, 2011, at 5:29 PM, Garrett Cooper wrote:
>>> I'm running into an issue where ifconfig isn't executing properly,
>>> and is emitting the following message:
>>> # ifconfig re0 inet w.x.y.z
>>> ifconfig: can't set link-level netmask or broadcast
>>> I haven't traced down what commit exactly is causing this, but the
>>> issue appears to be a purely userland based problem so far (I
>>> accidentally forgot to swap kernels before booting up the second time
>>> and the symptoms are exactly the same).
>> Yes, you lost. My changes did that. You are the second to hit it.
>> Your kernel does not have "FEATURES()" present and the new user space
>> that came a couple of days later expect it and disable your IPv4
>> because of that.
>> The real problem is when people update the kernel, then update world
>> and then figure out they need to go back to kernel.old.
>> I'll add an UPDATING entry.
> That I would expect, but I just built the kernel last night, installed
> it, and am running it right now and I run into the same issue as I do
> with the older kernel :). Was there any magic foo that I needed to use
> to get FEATURES working properly, or was it supposed to be seamless? I
> don't know because I never had a need to fiddle around with the
It's supposed to be seamless. Can you check if you have the following two?
> Looks like I need an old userland, because a new kernel/userland combo
> doesn't seem to work as advertised :/...
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?
Bjoern A. Zeeb You have to have visions!
Stop bit received. Insert coin for new address family.
More information about the freebsd-current