Description of problem: I have Fedora 17 x86_64 kickstart working well with DHCP and PXELINUX. But when I try to use static IP address assignment by adding the following text to the APPEND line in my otherwise working PXELINUX menu file: nameserver=xxx.xxx.6.247:xxx.70.168.183:xxx.37.137.85 ip=xxx.122.100.124:xxx.122.100.1:255.255.254.0:examplehostname:em1:off rdnetdebug (I got these values from http://fedoraproject.org/wiki/Anaconda_Boot_Options BTW) ... I get this: dracut: Warning: Empty autoconf values default to dhcp dracut: FATAL: For argument 'ip=xxx.122.100.124:xxx.122.100.1:255.255.254.0:examplehostname:em1:off'\nSorry, setting client-ip does not make sense for 'dhcp' dracut: Refusing to continue Something or someone is confused. It might be me, but if I'm setting ip= to something with the last value being "off", aren't I implicitly saying "don't use dhcp" ? Why then is anaconda/dracut confused about this? Version-Release number of selected component (if applicable): F17 x86_64
I've gotten a little further with this syntax: ip=xxx.122.100.124::xxx.122.100.1:255.255.254.0:::off That spends a decent amount of time trying different interfaces... all of which fail. I do see a udev message saying "em1: link becomes ready", but seems that was was too late for the network connectivity test to use.
ip=xxx.122.100.124::xxx.122.100.1:255.255.254.0::em1:off Doesn't get any further, but at least doesn't try all the other interfaces. The static IP is pingable, but anaconda still times out when trying to access the webserver.
What webserver are you referring to? What's the full commandline you're using?
Sorry, I should have posted the working PXELINUX label from which I'm starting: KERNEL http://server/fedora/path/vmlinuz APPEND initrd=http://server/path/pxeboot/initrd.img ks=http://server/path/ks.cfg repo=http://server/path/x86_64/os/ ksdevice=bootif kssendmac sshd=1 This works all by itself ... but breaks with the addition of the ip= arg, with the nameserver=ip1:ip2:ip3 I'm also optionally adding rdnetdebug and rdinitdebug on the end of the append line for debugging purposes.
I see the new ip= and nameserver= rules listed here at http://fedoraproject.org/wiki/Dracut/Options#Dracut_kernel_command_line_parameters ... but I've googled extensively, and not found any working examples of Fedora 17 kickstarting with a static IP address specified on the kernel command line. Are we sure this works at all?
Is your PXE environment adding a BOOTIF argument? If so, that could be a source of conflicting arguments. Try adding 'rd.debug' and 'rd.break=cmdline' to the boot arguments. (This should give you a shell right when dracut starts up.) Once the shell starts, check /proc/cmdline to see the exact arguments passed to dracut by the PXE environment. The other possible problem is the kickstart - do you have any 'network' lines in the kickstart? If you can show me the contents of /proc/cmdline and the kickstart 'network' lines I can attempt to reproduce the problem locally.
The kernel command line looks like this: ks=http://stuff repo=http://stuff kssendmac sshd=1 nameserver=ip1:ip2:ip3 ip=ip:1:gatewayip:netmask::macaddr:off rdnetdebug rdinitdebug rd.debug rd.break=cmdline initrd=http://stuff BOOT_IMAGE=http://stuff There is no BOOTIF, I'm not using any APPEND statement in the PXELINUX menu. Also, there is no network line in ks.cfg ... not that it would matter, as the machine can't access anything over the network with ip= static IP kickstart not working.
(In reply to comment #7) > The kernel command line looks like this: > > ks=http://stuff repo=http://stuff kssendmac sshd=1 nameserver=ip1:ip2:ip3 > ip=ip:1:gatewayip:netmask::macaddr:off rdnetdebug rdinitdebug rd.debug > rd.break=cmdline initrd=http://stuff BOOT_IMAGE=http://stuff > > There is no BOOTIF, I'm not using any APPEND statement in the PXELINUX menu. > > Also, there is no network line in ks.cfg ... not that it would matter, as > the machine can't access anything over the network with ip= static IP > kickstart not working. ip=ip:1:gatewayip:netmask::macaddr:off macacddr? are you sure, you want to _set_ the macaddr for your interface?
I'm sure I *don't* want to set the MAC ... the instructions at http://fedoraproject.org/wiki/Dracut/Options#Network though leave a lot unsaid. I thought it was implying that we should specify the MAC if we wanted to *identify* the NIC on which we were setting the IP address. Error messages seem to indicate that using BOOTIF isn't compatible with using ip=, though it would be very useful to specify the NIC that I just PXELINUX booted from. Regardless, could you post something that is known to work? I've tried just about every combination, and dracut just dies. Google and I have yet to find a single example or instance where this works... lots of the old ip=/netmask=/gateway= examples yes, but none with the newer syntax though.
primary source for dracut documentation: $ firefox /usr/share/doc/dracut-*/dracut.html $ man dracut $ man dracut.cmdline
I added a note in the wiki pages.
>ks=http://stuff repo=http://stuff kssendmac sshd=1 nameserver=ip1:ip2:ip3 ip=ip:1:gatewayip:netmask::macaddr:off rdnetdebug rdinitdebug rd.debug rd.break=cmdline initrd=http://stuff BOOT_IMAGE=http://stuff Might look like this: ks=http://stuff repo=http://stuff kssendmac sshd=1 nameserver=ip1 nameserver=ip2 nameserver=ip3 ifname=myeth:macaddr ip=myeth:1:gatewayip:netmask:::off BOOT_IMAGE=http://stuff Changing component to anaconda, to get more comments on the anaconda specific options.
Do I have to specify the NIC at all? I'd like to assign a static IP address to the NIC that is BOOTIF. Is there anyway to do that?
Anyone?
Hi Joshua! I got that solved following these 2 links: http://fedoraproject.org/wiki/Dracut/Options#Network http://dracut.git.sourceforge.net/git/gitweb.cgi?p=dracut/dracut;a=patch;h=cc02093 (searching for ip=) Using: ip=<client-IP-number>:<server-id>:<gateway-IP-number>:<netmask>:<client-hostname>:<interface>:[dhcp|on|any|none|off] The <server-id> param can be supressed. ip=<client-IP-number>::<gateway-IP-number>:<netmask>:<client-hostname>:<interface>:[dhcp|on|any|none|off] An example: ip=10.10.13.1:1:10.10.13.1:255.255.255.0:hostname.sys:p2p1:off Its very important to use [off:none] at the end, thus the system will cutoff the dhcp. so, the complete argument that worked to me is: ip=10.10.13.51:1:10.10.13.1:255.255.255.0:hostname.sys:p2p1:off nameserver=8.8.8.8 ks=nfs:10.10.13.254:/shares/ks/ks.cfg Best regards, Edilson
Following the description on your first post, ip=xxx.122.100.124:xxx.122.100.1:255.255.254.0:examplehostname:em1:off I think it could work if you use the <server-id> or supress that with [::] So, try again: ip=xxx.122.100.124::xxx.122.100.1:255.255.254.0:examplehostname:em1:off or ip=xxx.122.100.124:1:xxx.122.100.1:255.255.254.0:examplehostname:em1:off Regards, Edilson
What's the status of this bug for F17? F18?
I can confirm that this seems to not be a bug in functionality, but a lack of sufficiently detailed documentation. I started out experiencing the same symptoms as Joshua, and using Edilson's syntax suggestions I confirmed that I could get a reliable network connection to my kickstart server using F17's anaconda image with a static IP address. Eg: after booting from a Fedora F17 anaconda boot flash (USB), and after hitting escape to get the anaconda "boot:" prompt, I entering the following commandline boot: linux ks=ftp://1.1.1.1/junk ip=1.1.1.2::1.1.1.3:junkhostname:junketh:off This deliberately caused a networking failure, which loads the dracut debug console, where I was able to identify the device's ethernet interface names, ie: dracut:/# ip link show My interfaces were em1 and p4p1. I then re-launched anaconda, using the correct ethernet names, and correct syntax for the remaining attributes and values (per Edilson's syntax suggestions), and I successfully connected to my Kickstart server, ie: boot: linux ks=ftp://10.10.10.10/f17.ks ip=10.10.10.99::10.10.10.1:realhostname:em1:off Hope this helps. Good luck.
Yes, I agree. This needs to be documented in one of the Fedora Docs... the System Administrator's Guide or something
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
This should be fixed in Fedora 19. If you still hit the problem, feel free to reopen the bug.