Re: r228700 can't dhclient em0
On 23. Dec 2011, at 01:40 , Doug Barton wrote: On 12/21/2011 23:20, Gleb Smirnoff wrote: On Wed, Dec 21, 2011 at 12:35:23PM -0800, Doug Barton wrote: D So does that mean that if I upgrade to the latest HEAD from a system D built before the ifconfig changes that when I reboot my network will D come up? Yes, older infconfig will work in head r228571 || head r228768. I just tried with r228122 and got the same result. dhclient errors out with can't find em0 although 'ifconfig em0' does produce results. Which is due to getifaddrs() most likely; please go back and read up the other half of the thread; I am working on this. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r228700 can't dhclient em0
On 12/23/2011 01:14, Bjoern A. Zeeb wrote: On 23. Dec 2011, at 01:40 , Doug Barton wrote: On 12/21/2011 23:20, Gleb Smirnoff wrote: On Wed, Dec 21, 2011 at 12:35:23PM -0800, Doug Barton wrote: D So does that mean that if I upgrade to the latest HEAD from a system D built before the ifconfig changes that when I reboot my network will D come up? Yes, older infconfig will work in head r228571 || head r228768. I just tried with r228122 and got the same result. dhclient errors out with can't find em0 although 'ifconfig em0' does produce results. Which is due to getifaddrs() most likely; please go back and read up the other half of the thread; I read the whole thread. It's my thread after all. :) I was taking Gleb at his word when he answered my question with yes. I am working on this. Excellent. ETA? Normally I wouldn't be worried about updating, but I want to try the newly updated code to recognize music CDs. If it works I would like to encourage re@ to include it in the new release since I think it will save our users a lot of pain. Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r228700 can't dhclient em0
On 12/21/2011 23:20, Gleb Smirnoff wrote: I'm afraid, if we would try to document every kernel-userland API/ABI change in head/ in the UPDATING, then the file will grow extremely quickly, and still many issues will be forgotten to be added there. That doesn't mean we shouldn't do our best to make sure that they are documented. This is particularly true regarding changes that will affect the network on reboot. In any case, thanks for the info, and for your hard work. :) Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r228700 can't dhclient em0
On 12/21/2011 23:20, Gleb Smirnoff wrote: On Wed, Dec 21, 2011 at 12:35:23PM -0800, Doug Barton wrote: D So does that mean that if I upgrade to the latest HEAD from a system D built before the ifconfig changes that when I reboot my network will D come up? Yes, older infconfig will work in head r228571 || head r228768. I just tried with r228122 and got the same result. dhclient errors out with can't find em0 although 'ifconfig em0' does produce results. I'm also not sure what you meant by head r228768 above, since we're only up to r228824 in total so far. Maybe your time machine works better than mine? :) Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r228700 can't dhclient em0
On Thu, Dec 22, 2011 at 05:40:03PM -0800, Doug Barton wrote: D D So does that mean that if I upgrade to the latest HEAD from a system D D built before the ifconfig changes that when I reboot my network will D D come up? D D Yes, older infconfig will work in head r228571 || head r228768. D D I just tried with r228122 and got the same result. dhclient errors out D with can't find em0 although 'ifconfig em0' does produce results. The dhclient issue you faced isn't related to my new CARP commit either my SIOCAIFADDR work. I'm sorry that we flooded your email thread with the discussion. The breakage from r228571 looks like: # ifconfig em0 10.0.0.1 ioctl (SIOCAIFADDR): Invalid argument # The breakage from r228313 looks like: Starting dhclient. ifconfig: ioctl (SIOCAIFADDR): File exists D I'm also not sure what you meant by head r228768 above, since we're D only up to r228824 in total so far. Maybe your time machine works better D than mine? :) I don't see any problem. r228824 r228768, isn't it? -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r228700 can't dhclient em0
On 12/22/2011 23:22, Gleb Smirnoff wrote: On Thu, Dec 22, 2011 at 05:40:03PM -0800, Doug Barton wrote: D D So does that mean that if I upgrade to the latest HEAD from a system D D built before the ifconfig changes that when I reboot my network will D D come up? D D Yes, older infconfig will work in head r228571 || head r228768. D D I just tried with r228122 and got the same result. dhclient errors out D with can't find em0 although 'ifconfig em0' does produce results. The dhclient issue you faced isn't related to my new CARP commit either my SIOCAIFADDR work. I'm sorry that we flooded your email thread with the discussion. The breakage from r228571 looks like: # ifconfig em0 10.0.0.1 ioctl (SIOCAIFADDR): Invalid argument # The breakage from r228313 looks like: Starting dhclient. ifconfig: ioctl (SIOCAIFADDR): File exists OK, thanks. D I'm also not sure what you meant by head r228768 above, since we're D only up to r228824 in total so far. Maybe your time machine works better D than mine? :) I don't see any problem. r228824 r228768, isn't it? D'oh ... I don't know how I missed that, moving too fast, pulled in too many directions, etc. Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r228700 can't dhclient em0
Brooks, On Tue, Dec 20, 2011 at 07:52:41PM -0600, Brooks Davis wrote: B While this is the documented path, it's not actually been required B except in edge cases for ages (the last I can remember is a.out-elf). B It's been long enough that I don't think we can really make people do B it except for a short period of time in HEAD. I believe it's B unacceptable for a release to release upgrade. I have provided API compatibility in r228768. I have tested it with an ifconfig binary taken from 9.0 installation. I hope, this change would satisfy you, and you won't say that We almost certainly need to back r228571 out. The in_control() and in6_control() are getting more and more hairy :( I'd eager to remove the shim in the 11.x timeline. Since subject mentions dhclient, I must notice that the dhclient-script always relied on a bug in in_control(). The bug was fixed here: http://svnweb.freebsd.org/base?view=revisionamp;revision=228313 Later the dhclient-script was fixed: http://svnweb.freebsd.org/base?view=revisionamp;revision=228463 So, if we are claiming for an undocumented but important feature that new kernel being capable to configure network with world from a previous major release, then I should merge r228463 right now to stable/9, and not merge r228313. If I don't merge r228463 before 9.0-RELEASE is out, then in 2 years, 10.x-RELEASE kernel won't bring network up via DHCP with world from 9.0-RELEASE. Thus, should I now either bribe re@ to push r228463 prior to release, either back out the bugfix: r228463. Also, backing out r228463 would require backing out a larger work: r228455. Hey, this policy greatly discourages hacking on bugs and new features... :( -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r228700 can't dhclient em0
On Wed, Dec 21, 2011 at 04:55:40PM +0400, Gleb Smirnoff wrote: Brooks, On Tue, Dec 20, 2011 at 07:52:41PM -0600, Brooks Davis wrote: B While this is the documented path, it's not actually been required B except in edge cases for ages (the last I can remember is a.out-elf). B It's been long enough that I don't think we can really make people do B it except for a short period of time in HEAD. I believe it's B unacceptable for a release to release upgrade. I have provided API compatibility in r228768. I have tested it with an ifconfig binary taken from 9.0 installation. I hope, this change would satisfy you, and you won't say that We almost certainly need to back r228571 out. Thank you! I spoke too strongly there. I was worried that we would end up in an untenable situation, but you appear to have resolved it. The in_control() and in6_control() are getting more and more hairy :( I'd eager to remove the shim in the 11.x timeline. Since subject mentions dhclient, I must notice that the dhclient-script always relied on a bug in in_control(). The bug was fixed here: http://svnweb.freebsd.org/base?view=revisionamp;revision=228313 Later the dhclient-script was fixed: http://svnweb.freebsd.org/base?view=revisionamp;revision=228463 So, if we are claiming for an undocumented but important feature that new kernel being capable to configure network with world from a previous major release, then I should merge r228463 right now to stable/9, and not merge r228313. If I don't merge r228463 before 9.0-RELEASE is out, then in 2 years, 10.x-RELEASE kernel won't bring network up via DHCP with world from 9.0-RELEASE. Thus, should I now either bribe re@ to push r228463 prior to release, either back out the bugfix: r228463. You and bz have convinced me that for the configuration tools tools this change breaks, that it should be OK to have only supported 9.x releases (or possibly even only the last 9.x release) be able to upgrade without extra effort. I took too strong a position to start out. Also, backing out r228463 would require backing out a larger work: r228455. Hey, this policy greatly discourages hacking on bugs and new features... :( I hope we're approaching a more acceptable position... I don't want to discourage fixing bugs or adding features and more than having to deal with users inevitably does. -- Brooks pgpNKlBWWf6s2.pgp Description: PGP signature
Re: r228700 can't dhclient em0
On 12/21/2011 4:55 AM, Gleb Smirnoff wrote: Brooks, On Tue, Dec 20, 2011 at 07:52:41PM -0600, Brooks Davis wrote: B While this is the documented path, it's not actually been required B except in edge cases for ages (the last I can remember is a.out-elf). B It's been long enough that I don't think we can really make people do B it except for a short period of time in HEAD. I believe it's B unacceptable for a release to release upgrade. I have provided API compatibility in r228768. I have tested it with an ifconfig binary taken from 9.0 installation. So does that mean that if I upgrade to the latest HEAD from a system built before the ifconfig changes that when I reboot my network will come up? I hope, this change would satisfy you, and you won't say that We almost certainly need to back r228571 out. I think Brooks raised some really good points about backward compatibility, but it sounds to me like you've addressed them. In any case, my original concern was limited to Do we need an UPDATING entry? :) The in_control() and in6_control() are getting more and more hairy :( I'd eager to remove the shim in the 11.x timeline. Since subject mentions dhclient, I must notice that the dhclient-script always relied on a bug in in_control(). The bug was fixed here: http://svnweb.freebsd.org/base?view=revisionamp;revision=228313 Later the dhclient-script was fixed: http://svnweb.freebsd.org/base?view=revisionamp;revision=228463 Right, I saw those go by, which is why I tried not to jump too hard on ifconfig is broken since I wasn't sure which change was causing my problem. It sounds like you're saying that perhaps I still won't be able to get the network up after booting a new kernel without also installing part of the new world? Perhaps an UPDATING entry is needed after all? Hey, this policy greatly discourages hacking on bugs and new features... :( Learning how to innovate while providing backwards compatibility is a valuable skill. Think of this as an opportunity. :) Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r228700 can't dhclient em0
On Tue, Dec 20, 2011 at 11:23:54PM +0400, Gleb Smirnoff wrote: Considering r228571: we need to specify vhid as additional address attribute in atomic manner, via one ioctl(). Address can't be first configured, and then made redundant, that would lead it to being static for a short period, sending gratutious ARP announcement, etc. An assumption that we are not allowed to change ABI for our own tools strongly discourages bringing in new features :( Consider changing to a more flexible ABI that does not need to be broken for new features. Examples are nmount(2)'s name-value pairs and GEOM's XML topology descriptions. This is initially more work and has poorer performance, but it may well be worth it. Process information reserves space in structures for future extension; this is less flexible but performs better (which matters somewhat). Another consideration is compatibility for 32-bit applications on 64-bit kernels; a good ABI design will minimize the amount of code needed to support that. -- Jilles Tjoelker ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r228700 can't dhclient em0
On Wed, Dec 21, 2011 at 12:35:23PM -0800, Doug Barton wrote: D On Tue, Dec 20, 2011 at 07:52:41PM -0600, Brooks Davis wrote: D B While this is the documented path, it's not actually been required D B except in edge cases for ages (the last I can remember is a.out-elf). D B It's been long enough that I don't think we can really make people do D B it except for a short period of time in HEAD. I believe it's D B unacceptable for a release to release upgrade. D D I have provided API compatibility in r228768. I have tested it with an D ifconfig binary taken from 9.0 installation. D D So does that mean that if I upgrade to the latest HEAD from a system D built before the ifconfig changes that when I reboot my network will D come up? Yes, older infconfig will work in head r228571 || head r228768. D I think Brooks raised some really good points about backward D compatibility, but it sounds to me like you've addressed them. In any D case, my original concern was limited to Do we need an UPDATING entry? :) r228571 put an updating entry. D Since subject mentions dhclient, I must notice that the dhclient-script D always relied on a bug in in_control(). The bug was fixed here: D D http://svnweb.freebsd.org/base?view=revisionamp;revision=228313 D D Later the dhclient-script was fixed: D D http://svnweb.freebsd.org/base?view=revisionamp;revision=228463 D D Right, I saw those go by, which is why I tried not to jump too hard on D ifconfig is broken since I wasn't sure which change was causing my D problem. It sounds like you're saying that perhaps I still won't be able D to get the network up after booting a new kernel without also installing D part of the new world? Perhaps an UPDATING entry is needed after all? On the second thought, I understand that r228313 breaks the dhclient-script only for people running two DHCP interfaces. If one obtains default route, then second can't run dhclient. I'm afraid, if we would try to document every kernel-userland API/ABI change in head/ in the UPDATING, then the file will grow extremely quickly, and still many issues will be forgotten to be added there. -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r228700 can't dhclient em0
On 12/19/2011 05:24, Dimitry Andric wrote: On 2011-12-19 10:17, Doug Barton wrote: I updated to r228700 from 228122 and dhclient exits immediately saying that em0 doesn't exist. However ifconfig seems to disagree: em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=4219bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO ether 00:24:e8:30:10:9b nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (100baseTXfull-duplex) status: active lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 options=3RXCSUM,TXCSUM nd6 options=21PERFORMNUD,AUTO_LINKLOCAL Interestingly, some of the options are different in that version, vs. the working version: em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=219bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC ether 00:24:e8:30:10:9b inet 172.17.198.245 netmask 0x broadcast 172.17.255.255 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (100baseTXfull-duplex) status: active I saw this too, when my kernel and userland were out of sync (e.g. just after installing a new kernel, and before installworld). I suspect it is caused by the changes in r228571, which cause old ifconfig and dhclient to not recognize any interfaces. I'm not 100% sure though... I tried replacing both ifconfig and dhclient with the versions that were built along with the new kernel, and that didn't work. The traditional (and documented) upgrade process for many years has been to boot the new kernel, make sure it's Ok, then update world. Obviously something different is needed this time, so it needs an UPDATING entry (assuming that all this is not just a bug). Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r228700 can't dhclient em0
On 2011-12-20 09:38, Doug Barton wrote: ... I tried replacing both ifconfig and dhclient with the versions that were built along with the new kernel, and that didn't work. Looking at the changes in r228571, it seems they also affect libc, so installing that is probably also needed. Since all my test systems are already upgraded to post-r228571, can somebody please confirm it works after doing: make -C $srcdir/lib/libc install make -C $srcdir/sbin/dhclient install make -C $srcdir/sbin/ifconfig install The traditional (and documented) upgrade process for many years has been to boot the new kernel, make sure it's Ok, then update world. Obviously something different is needed this time, so it needs an UPDATING entry (assuming that all this is not just a bug). Well, if there *is* any method of getting your network working before installworld, it should be added to UPDATING... :) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r228700 can't dhclient em0
On Tue, Dec 20, 2011 at 04:43:21PM +0100, Dimitry Andric wrote: On 2011-12-20 09:38, Doug Barton wrote: ... I tried replacing both ifconfig and dhclient with the versions that were built along with the new kernel, and that didn't work. Looking at the changes in r228571, it seems they also affect libc, so installing that is probably also needed. Since all my test systems are already upgraded to post-r228571, can somebody please confirm it works after doing: make -C $srcdir/lib/libc install make -C $srcdir/sbin/dhclient install make -C $srcdir/sbin/ifconfig install We almost certainly need to back r228571 out. This is not an acceptable upgrade path that would be acceptable historically. Specially, we have effectively promised users that an X.Y world will work on an X+1.0 kernel for most of history. There are obvious exceptions to this, but we have never allowed ifconfig to be one of them (I broke it many years ago with my first attempt to add if_epoch to if_data and had to back that out). -- Brooks pgpHMjvu8huYI.pgp Description: PGP signature
Re: r228700 can't dhclient em0
On 20. Dec 2011, at 16:51 , Brooks Davis wrote: On Tue, Dec 20, 2011 at 04:43:21PM +0100, Dimitry Andric wrote: On 2011-12-20 09:38, Doug Barton wrote: ... I tried replacing both ifconfig and dhclient with the versions that were built along with the new kernel, and that didn't work. Looking at the changes in r228571, it seems they also affect libc, so installing that is probably also needed. Since all my test systems are already upgraded to post-r228571, can somebody please confirm it works after doing: make -C $srcdir/lib/libc install make -C $srcdir/sbin/dhclient install make -C $srcdir/sbin/ifconfig install Depends on what you are trying to achieve. There is more software affected. We almost certainly need to back r228571 out. This is not an acceptable upgrade path that would be acceptable historically. Specially, we have effectively promised users that an X.Y world will work on an X+1.0 I am not sure we supported that but X.latest to X+1.Y maybe? kernel for most of history. There are obvious exceptions to this, but we have never allowed ifconfig to be one of them (I broke it many years ago with my first attempt to add if_epoch to if_data and had to back that out). There is a couple of issues here. The one that's on me is struct ifa_msghdr / getifaddrs() and the problem here is that software incl. getifaddrs() doesn't use the in structs embedded lengths in first place. In if_data only a spare was reused, so no changes there. That's certainly something we can and should fix in 9 before 10.0 will happen. If that was the problem back then, it's certainly a pity it wasn't fixed as we wouldn't have that problem these days then. It would allow appending more stuff. For the appended int to ifaliasreq, in_aliasreq, in6_aliasreq I haven't looked at the actual problem in the upgrade paths. I guess it's not much outside of ifconfig and probably ppp at least for the in_ in6_ variants. Backing r228571 out completely will be harder with every change glebius commits on top. So if we think it'll be needed we should stop those commits now and think first. Just breaking carp and backing out the user space API parts is only a usable path with a plan B on how to fix carp as well in the same go really. Ingoring 9.0 - 10-CURRENT or an update on HEAD (neither of which is not a normal user upgrade path an supported) I am still wondering how much of that can be mitigated and if it might make sense to ponder that direction (also for further future changes for sure to happen) to not be stuck forever? I fear we'll see/want to do more of these kinds as more people look at the if/ll layer... /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family.___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r228700 can't dhclient em0
Doug, On Tue, Dec 20, 2011 at 12:38:53AM -0800, Doug Barton wrote: D I saw this too, when my kernel and userland were out of sync (e.g. just D after installing a new kernel, and before installworld). I suspect it D is caused by the changes in r228571, which cause old ifconfig and D dhclient to not recognize any interfaces. I'm not 100% sure though... D D I tried replacing both ifconfig and dhclient with the versions that were D built along with the new kernel, and that didn't work. This shouldn't happen. If you did 'make buildworld buildkernel', then your world in objdir would have binaries compiled with includes from source tree, not from /usr/include, thus compatible with new kernel. 'make buildworld buildkernel' always produces compatible kernel and worlds. However, if you did 'cd /usr/src/sbin/ifconfig make all install' then that didn't work, since used headers from /usr/include. D The traditional (and documented) upgrade process for many years has been D to boot the new kernel, make sure it's Ok, then update world. Obviously D something different is needed this time, so it needs an UPDATING entry D (assuming that all this is not just a bug). The documented one says 'Reboot into single user mode' and then install new world. This path was not broken, since single user mode doesn't imply network support. The undocumented brave way 'make installkernel installworld reboot' works also, without any problems. -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r228700 can't dhclient em0
Brooks, On Tue, Dec 20, 2011 at 10:51:34AM -0600, Brooks Davis wrote: B We almost certainly need to back r228571 out. This is not an acceptable B upgrade path that would be acceptable historically. Specially, we have B effectively promised users that an X.Y world will work on an X+1.0 B kernel for most of history. There are obvious exceptions to this, but B we have never allowed ifconfig to be one of them (I broke it many years B ago with my first attempt to add if_epoch to if_data and had to back B that out). Pardon, where did we promise that? The applications in jail should work, but not kernel configuration tools. The network facilities like ipfw and pf has changed their ABI numerous times, making a new kernel with older world inaccessible via network after boot. Considering r228571: we need to specify vhid as additional address attribute in atomic manner, via one ioctl(). Address can't be first configured, and then made redundant, that would lead it to being static for a short period, sending gratutious ARP announcement, etc. An assumption that we are not allowed to change ABI for our own tools strongly discourages bringing in new features :( -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r228700 can't dhclient em0
T An assumption that we are not allowed to change ABI for our own tools T strongly discourages bringing in new features :( P.S. Quoting documentation: The old world might not run correctly on the new kernel, so you must install the new world immediately upon installing the new kernel. http://www.freebsd.org/doc/en/books/handbook/makeworld.html -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r228700 can't dhclient em0
On Tue, Dec 20, 2011 at 06:48:40PM +, Bjoern A. Zeeb wrote: On 20. Dec 2011, at 16:51 , Brooks Davis wrote: On Tue, Dec 20, 2011 at 04:43:21PM +0100, Dimitry Andric wrote: On 2011-12-20 09:38, Doug Barton wrote: ... I tried replacing both ifconfig and dhclient with the versions that were built along with the new kernel, and that didn't work. Looking at the changes in r228571, it seems they also affect libc, so installing that is probably also needed. Since all my test systems are already upgraded to post-r228571, can somebody please confirm it works after doing: make -C $srcdir/lib/libc install make -C $srcdir/sbin/dhclient install make -C $srcdir/sbin/ifconfig install Depends on what you are trying to achieve. There is more software affected. We almost certainly need to back r228571 out. This is not an acceptable upgrade path that would be acceptable historically. Specially, we have effectively promised users that an X.Y world will work on an X+1.0 I am not sure we supported that but X.latest to X+1.Y maybe? That's the guarantee we've advertised, but the breakage we've supported has mostly been for more narrowly focused tools that grovel around in KVM space. We've usually allowed an old world to work with only a few shims (ps for instance). Adding a new ifconfig to the list would be an expansion there. I also worry about the problem that once you've installed world there is no easy way back. kernel for most of history. There are obvious exceptions to this, but we have never allowed ifconfig to be one of them (I broke it many years ago with my first attempt to add if_epoch to if_data and had to back that out). There is a couple of issues here. The one that's on me is struct ifa_msghdr / getifaddrs() and the problem here is that software incl. getifaddrs() doesn't use the in structs embedded lengths in first place. In if_data only a spare was reused, so no changes there. That's certainly something we can and should fix in 9 before 10.0 will happen. If that was the problem back then, it's certainly a pity it wasn't fixed as we wouldn't have that problem these days then. It would allow appending more stuff. It would nice to fix, but allowing append to if_data means reving the routing socket API. I looked at it a bit and then gave up because there were too many consumers (many out of tree), pretty much all of which ignore the version number. I didn't have time to rev the whole API which is probably where the bar is for breaking the API. For the appended int to ifaliasreq, in_aliasreq, in6_aliasreq I haven't looked at the actual problem in the upgrade paths. I guess it's not much outside of ifconfig and probably ppp at least for the in_ in6_ variants. Those many have few enough consumers that we can come up with a reasonable path forward. Backing r228571 out completely will be harder with every change glebius commits on top. So if we think it'll be needed we should stop those commits now and think first. Just breaking carp and backing out the user space API parts is only a usable path with a plan B on how to fix carp as well in the same go really. Ingoring 9.0 - 10-CURRENT or an update on HEAD (neither of which is not a normal user upgrade path an supported) I am still wondering how much of that can be mitigated and if it might make sense to ponder that direction (also for further future changes for sure to happen) to not be stuck forever? I fear we'll see/want to do more of these kinds as more people look at the if/ll layer... If we can identify all the changed interfaces and we can teach 9-STABLE to deal with them then this change is probably OK and we just need to do the appropriate libc and ifconfig spackling and merge it. We can't let this slide too long though because the current state requires an installkernel+installworld for all intents and purposes and that means that if the kernel is broken you are dead in the water. I agree we could really use some sort of way forward that increases our abilty to make these sorts of changes. - Brooks /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. pgp3SB4aWm9NV.pgp Description: PGP signature
Re: r228700 can't dhclient em0
On Tue, Dec 20, 2011 at 01:30:34PM -0600, Brooks Davis wrote: B I also worry about the problem that once you've installed world there is B no easy way back. When working on the patch for last months I did numerous 'make installkernel installworld' switching between a patched sources and unpatched, and everything goes fine. B If we can identify all the changed interfaces and we can teach 9-STABLE B to deal with them then this change is probably OK and we just need to B do the appropriate libc and ifconfig spackling and merge it. We can't B let this slide too long though because the current state requires an B installkernel+installworld for all intents and purposes and that means B that if the kernel is broken you are dead in the water. B B I agree we could really use some sort of way forward that increases our B abilty to make these sorts of changes. Why 9-STABLE? This change isn't going to be merged. -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r228700 can't dhclient em0
On 20. Dec 2011, at 19:35 , Gleb Smirnoff wrote: On Tue, Dec 20, 2011 at 01:30:34PM -0600, Brooks Davis wrote: B I also worry about the problem that once you've installed world there is B no easy way back. When working on the patch for last months I did numerous 'make installkernel installworld' switching between a patched sources and unpatched, and everything goes fine. Yeah for the time being but we are talking about a 4-5 year timeframe. B If we can identify all the changed interfaces and we can teach 9-STABLE B to deal with them then this change is probably OK and we just need to B do the appropriate libc and ifconfig spackling and merge it. We can't B let this slide too long though because the current state requires an B installkernel+installworld for all intents and purposes and that means B that if the kernel is broken you are dead in the water. B B I agree we could really use some sort of way forward that increases our B abilty to make these sorts of changes. Why 9-STABLE? This change isn't going to be merged. Because we'd need to make sure that fixes go backward to work with the new stuff for the update path - the fixes, not your change. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r228700 can't dhclient em0
On Tue, Dec 20, 2011 at 11:15:20PM +0400, Gleb Smirnoff wrote: Doug, On Tue, Dec 20, 2011 at 12:38:53AM -0800, Doug Barton wrote: D I saw this too, when my kernel and userland were out of sync (e.g. just D after installing a new kernel, and before installworld). I suspect it D is caused by the changes in r228571, which cause old ifconfig and D dhclient to not recognize any interfaces. I'm not 100% sure though... D D I tried replacing both ifconfig and dhclient with the versions that were D built along with the new kernel, and that didn't work. This shouldn't happen. If you did 'make buildworld buildkernel', then your world in objdir would have binaries compiled with includes from source tree, not from /usr/include, thus compatible with new kernel. 'make buildworld buildkernel' always produces compatible kernel and worlds. However, if you did 'cd /usr/src/sbin/ifconfig make all install' then that didn't work, since used headers from /usr/include. D The traditional (and documented) upgrade process for many years has been D to boot the new kernel, make sure it's Ok, then update world. Obviously D something different is needed this time, so it needs an UPDATING entry D (assuming that all this is not just a bug). The documented one says 'Reboot into single user mode' and then install new world. This path was not broken, since single user mode doesn't imply network support. While this is the documented path, it's not actually been required except in edge cases for ages (the last I can remember is a.out-elf). It's been long enough that I don't think we can really make people do it except for a short period of time in HEAD. I believe it's unacceptable for a release to release upgrade. The undocumented brave way 'make installkernel installworld reboot' works also, without any problems. At least until someone screws up something else and you now can't use kernel.old either. This is somewhat ok for HEAD users, but I think we should try harder to avoid this sort of situation. -- Brooks pgp309HM5Uyj4.pgp Description: PGP signature
Re: r228700 can't dhclient em0
On Tue, Dec 20, 2011 at 11:23:54PM +0400, Gleb Smirnoff wrote: Brooks, On Tue, Dec 20, 2011 at 10:51:34AM -0600, Brooks Davis wrote: B We almost certainly need to back r228571 out. This is not an acceptable B upgrade path that would be acceptable historically. Specially, we have B effectively promised users that an X.Y world will work on an X+1.0 B kernel for most of history. There are obvious exceptions to this, but B we have never allowed ifconfig to be one of them (I broke it many years B ago with my first attempt to add if_epoch to if_data and had to back B that out). Pardon, where did we promise that? The applications in jail should work, but not kernel configuration tools. The network facilities like ipfw and pf has changed their ABI numerous times, making a new kernel with older world inaccessible via network after boot. We've not promised it in writing, but by not breaking it for many years we're created an effective promise IMO. Considering r228571: we need to specify vhid as additional address attribute in atomic manner, via one ioctl(). Address can't be first configured, and then made redundant, that would lead it to being static for a short period, sending gratutious ARP announcement, etc. An assumption that we are not allowed to change ABI for our own tools strongly discourages bringing in new features :( I'm not saying we can't change the ABI. I am saying that we should make sure we can support a remote, console-less upgrade from what ever 9.x branches are practical to 10.0 in the average case. We've set the expectation that this will work and IMO it's a reasonable expectation. We've violated it in a few cases such as the emX-igbX fiasco, but by and large most users have been able to do this. I guess I'm ok with dealing with this in HEAD, but I'm not OK with it for all upgrades from 9.x. -- Brooks pgpQrFZn3sdT9.pgp Description: PGP signature
Re: r228700 can't dhclient em0
On 2011-12-19 10:17, Doug Barton wrote: I updated to r228700 from 228122 and dhclient exits immediately saying that em0 doesn't exist. However ifconfig seems to disagree: em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=4219bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO ether 00:24:e8:30:10:9b nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (100baseTXfull-duplex) status: active lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 options=3RXCSUM,TXCSUM nd6 options=21PERFORMNUD,AUTO_LINKLOCAL Interestingly, some of the options are different in that version, vs. the working version: em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=219bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC ether 00:24:e8:30:10:9b inet 172.17.198.245 netmask 0x broadcast 172.17.255.255 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (100baseTXfull-duplex) status: active I saw this too, when my kernel and userland were out of sync (e.g. just after installing a new kernel, and before installworld). I suspect it is caused by the changes in r228571, which cause old ifconfig and dhclient to not recognize any interfaces. I'm not 100% sure though... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r228700 can't dhclient em0
On Dec 19, 2011, at 5:24 AM, Dimitry Andric d...@freebsd.org wrote: On 2011-12-19 10:17, Doug Barton wrote: I updated to r228700 from 228122 and dhclient exits immediately saying that em0 doesn't exist. However ifconfig seems to disagree: em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=4219bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO ether 00:24:e8:30:10:9b nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (100baseTXfull-duplex) status: active lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 options=3RXCSUM,TXCSUM nd6 options=21PERFORMNUD,AUTO_LINKLOCAL Interestingly, some of the options are different in that version, vs. the working version: em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=219bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC ether 00:24:e8:30:10:9b inet 172.17.198.245 netmask 0x broadcast 172.17.255.255 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (100baseTXfull-duplex) status: active I saw this too, when my kernel and userland were out of sync (e.g. just after installing a new kernel, and before installworld). I suspect it is caused by the changes in r228571, which cause old ifconfig and dhclient to not recognize any interfaces. I'm not 100% sure though. This makes sense because the structs that describe addresses changed recently. -Garrett___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r228700 can't dhclient em0
On 2011-12-19 17:36, Garrett Cooper wrote: On Dec 19, 2011, at 5:24 AM, Dimitry Andricd...@freebsd.org wrote: On 2011-12-19 10:17, Doug Barton wrote: I updated to r228700 from 228122 and dhclient exits immediately saying that em0 doesn't exist. However ifconfig seems to disagree: ... I saw this too, when my kernel and userland were out of sync (e.g. just after installing a new kernel, and before installworld). I suspect it is caused by the changes in r228571, which cause old ifconfig and dhclient to not recognize any interfaces. I'm not 100% sure though. This makes sense because the structs that describe addresses changed recently. It may make sense, but it is very annoying when you want to installworld over NFS, or have any other network access before or during installation. :( ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
