|Summary:||Manual IPv6 configuration for network install is broken|
|Product:||[Fedora] Fedora||Reporter:||Mark McClelland <mark>|
|Component:||libdhcp||Assignee:||David Cantrell <dcantrell>|
|Status:||CLOSED RAWHIDE||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-04-22 03:11:02 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
|Bug Blocks:||195271, 235706|
Description Mark McClelland 2007-03-04 23:58:37 UTC
Description of problem: If I configure an Ethernet interface manually when setting up for an IPv6 HTTP install, the settings I entered are not used according to ifconfig. Instead, it looks like the interface is set up with stateless autoconfig. Also, the address of the gateway is assigned to the interface. This network has an radvd server, and no DHCP/DHCPv6 or available IPv4 addresses. Version-Release number of selected component (if applicable): Fedora 7 test 2 (i386 or x86_64) How reproducible: Every time Steps to Reproduce: 1. Start anaconda from CD (boot.iso) 2. Choose HTTP install source 3. Choose network interface 4. At "Configure TCP/IP" dialog, uncheck "Enable IPv4 support" 5. Select "Enable IPv6 support" and choose "Manual configuration" 6. On "Manual TCP/IP Configuration" dialog, I entered this info: IPv6 address: 2001:470:1f01:2931::42 / 64 Gateway: 2001:470:1f01:2931::0 Name Server: 2001:470:1f01:2931::0 7. Enter HTTP server info and wait for X to start Actual results: ifconfig output: eth1 Link encap:Ethernet HWaddr 00:0F:B5:FB:3B:28 inet6 addr: 2001:470:1f01:2931::/0 Scope:Global inet6 addr: fec0::1:20f:b5ff:fefb:3b28/64 Scope:Site inet6 addr: 2001:470:1f01:2931:20f:b5ff:fefb:3b28/64 Scope:Global inet6 addr: fe80::20f:b5ff:fefb:3b28/64 Scope:Link UP BROADCAST RUNNING MTU:1500 Metric:1 [...] Expected results: eth1 Link encap:Ethernet HWaddr 00:0F:B5:FB:3B:28 inet6 addr: fec0::1:20f:b5ff:fefb:3b28/64 Scope:Site inet6 addr: 2001:470:1f01:2931::42/64 Scope:Global inet6 addr: fe80::20f:b5ff:fefb:3b28/64 Scope:Link Additional info: Here's the routing table (global unicast addresses only). The first entry looks wrong (but consistent with the ifconfig output). #route -n -A inet6 Kernel IPv6 routing table Destination Next Hop Flags Metric Ref Use Iface 2001:470:1f01:2931::/128 2001:470:1f01:2931:: UAC 0 6 0 eth1 2001:470:1f01:2931::/64 :: UA 256 35 0 eth1 ::/0 2001:470:1f01:2931:: UG 1024 0 0 eth1 2001:470:1f01:2931:20f:b5ff:fefb:3b28/128 :: U 0 56270 1 lo [...]
Comment 1 David Cantrell 2007-03-05 15:42:52 UTC
Excellent debugging info, thanks (we don't usually get detailed reports like this)! DHCP (for IPv4 and IPv6) in anaconda's loader is handled by libdhcp, so I've reassigned the component.
Comment 2 David Cantrell 2007-03-08 20:00:46 UTC
OK, so it wasn't in libdhcp. It was in anaconda's use of libdhcp. Fixed in rawhide. Thanks.
Comment 3 Mark McClelland 2007-03-17 03:01:29 UTC
I'm still seeing this in the Mar. 14 rawhide. I tried using three unique addresses for the IPv6 address, gateway, and nameserver, and I can confirm that the gateway text field is where the bogus 2001:470:1f01:2931::/0 address is coming from.
Comment 4 Matthew Miller 2007-04-06 20:23:08 UTC
This isn't obvious anywhere, but Fedora 7 test bugs should be filed against the "devel" version.
Comment 5 David Cantrell 2007-05-22 20:31:27 UTC
I think I have this fixed up. It was staring at me for a while and I kept overlooking it. I wasn't disabling the auto neighbor discovery for IPv6 when you select manual IPv6 configuration in anaconda. So anaconda would take the information for you, set it, and then drive over it with the auto discovery garbage. When you select manual IPv6 configuration, I disable both DHCPv6 *and* auto neighbor discovery. Code is checked in to anaconda CVS, will show up in rawhide the next time we rebuild anaconda. Going ahead and marking this as closed rawhide. Thanks.
Comment 6 Mark McClelland 2007-05-26 05:36:03 UTC
Thanks for trying to get a fix in under the wire, but it appears that your fix needs fixing. I get the error below after entering my IPv6 addresses and hitting OK. I couldn't get it to happen with IPv4 (manual or otherwise) or IPv6 autoconf, so I suspect it's related to your fix. If not, I can open a new bug. loader received SIGSEGV! Backtrace: [0x80402a4] [0x5da420] [0x80b2529] [0x806105a] [0x8063ccb] [0x8049246] [0x804a9e8] [0x8172728] [0x8048131] install exited abnormally [1/1]
Comment 7 David Cantrell 2007-05-29 15:11:42 UTC
Damn. Yeah, totally related. I'll get on this, but the window for getting fixes in for Fedora 7 is closed. I can get this fixed up and provide you with a custom initrd.img for F-7 that has the fix. I hate to leave you hanging where you can't get it installed in your environment. First things first, let me reproduce this and get it fixed, then we test, then I can make you custom initrds (or show you how).
Comment 8 Mark McClelland 2007-05-30 03:12:29 UTC
Don't worry, I'm only trying to install this way for better testing coverage. I normally use IPv6 autoconfig instead, and I suspect that most IPv6 users do the same (or use DHCPv6). I'd be glad to test a custom initrd though, since I'm sure someone else will want it eventually.
Comment 9 David Cantrell 2008-02-09 03:04:23 UTC
Is this happening for you with the current development releases?
Comment 10 Mark McClelland 2008-02-09 06:50:30 UTC
Just tested with F9 alpha i386 DVD askmethod and got this: loader received SIGSEGV! Backtrace: /sbin/loader(loaderSegvHandler+a0)[0x80505f0] [0x12f420] /lib/libdhcp-1.99.so.1(pumpSetupInterface+0x1f2)[0x25df92] /sbin/loader(configureNetwork+0x1a)[0x806350a] /sbin/loader(readNetConfig+0x5c6)[0x8066316] /sbin/loader(main+0xdba)[0x8051d0a] /lib/libc.so.6(__libc_start_main+0xe0)[0x4274a0] /sbin/loader[0x804e771] install exited abnormally [1/1]
Comment 11 David Cantrell 2008-02-09 08:41:27 UTC
Right, so that was a problem that creeped in to the alpha release of F-9. If you could try from the nightly rawhide builds, that would be good. I have fixed the problem you see above. http://download.fedora.redhat.com/pub/fedora/linux/development/i386/os/images/boot.iso
Comment 12 Mark McClelland 2008-02-09 09:57:06 UTC
With the boot.iso dated 08-Feb-2008 15:20: loader received SIGSEGV! Backtrace: /sbin/loader(loaderSegvHandler+0xa0)[0x8050320] [0x131420] /lib/libdhcp-1.99.so.1(pumpSetupInterface+0x1f2)[0x25ff92] /sbin/loader(configureNetwork+0x1a)[0x806330a] /sbin/loader(readNetConfig+0x5de)[0x806704e] /sbin/loader(main+0xf05)[0x8051855] /lib/libc.so.6(__libc_start_main+0xe6)[0x4304a6] /sbin/loader[0x804e541] install exited abnormally [1/1] I don't know if the fix was supposed to be in that boot.iso already. I'll try again tomorrow.
Comment 13 Mark McClelland 2008-02-18 01:18:28 UTC
I get basically the same backtrace with boot.iso dated 17-Feb-2008 12:43: loader received SIGSEGV! Backtrace: /sbin/loader(loaderSegvHandler+0xa0)[0x804fb90] [0x131400] /lib/libdhcp-1.99.so.1(pumpSetupInterface+0x1d0)[0x261000] /sbin/loader(configureNetwork+0x1a)[0x8062a5a] /sbin/loader(readNetConfig+0x5de)[0x806679e] /sbin/loader(main+0xf05)[0x80510b5] /lib/libc.so.6(__libc_start_main+0xe6)[0x432516] /sbin/loader[0x804ddb1] install exited abnormally [1/1]
Comment 15 Mark McClelland 2008-04-02 05:42:17 UTC
This bug is still present in F9 beta. The backtrace is virtually the same.
Comment 16 Charles R. Anderson 2008-04-04 03:32:03 UTC
Same crash from Comment #13 in F9 rawhide as of 2008-04-03.
Comment 17 Jon Stanley 2008-04-16 17:16:59 UTC
*** Bug 433290 has been marked as a duplicate of this bug. ***
Comment 18 David Cantrell 2008-04-22 03:11:02 UTC
Fought this bug today and won. It is actually a libdhcp bug, so changing the components there. Basically, in pumpSetupInterface(), it was not allowing a set of configuration data that only contained a single networking stack. It assumed that every caller would be doing both IPv4 and IPv6. I released a new version of libdhcp with the fix, libdhcp-1.99.8, so you can now do just IPv6 and completely disable IPv4. There are also some cleanup patches I did for anaconda that are related to this bug, so there should be a rebuild there too.