Bug 836039 - setting static ip= for kickstart doesn't work
setting static ip= for kickstart doesn't work
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-27 19:41 EDT by joshua
Modified: 2013-08-01 03:34 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-31 14:27:24 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description joshua 2012-06-27 19:41:03 EDT
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
Comment 1 joshua 2012-06-28 17:23:08 EDT
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.
Comment 2 joshua 2012-06-28 17:28:57 EDT
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.
Comment 3 Will Woods 2012-06-29 13:42:12 EDT
What webserver are you referring to? What's the full commandline you're using?
Comment 4 joshua 2012-06-29 17:53:46 EDT
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.
Comment 5 joshua 2012-07-06 19:06:32 EDT
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?
Comment 6 Will Woods 2012-07-13 11:51:10 EDT
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.
Comment 7 joshua 2012-07-13 19:53:12 EDT
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.
Comment 8 Harald Hoyer 2012-07-16 05:13:14 EDT
(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?
Comment 9 joshua 2012-07-20 21:02:09 EDT
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.
Comment 10 Harald Hoyer 2012-07-24 05:31:53 EDT
primary source for dracut documentation:

$ firefox /usr/share/doc/dracut-*/dracut.html
$ man dracut
$ man dracut.cmdline
Comment 11 Harald Hoyer 2012-07-24 05:37:37 EDT
I added a note in the wiki pages.
Comment 12 Harald Hoyer 2012-07-24 05:41:01 EDT
>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.
Comment 13 joshua 2012-07-28 18:20:29 EDT
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?
Comment 14 joshua 2012-08-14 19:50:09 EDT
Anyone?
Comment 15 Edilson Osorio Junior 2012-10-18 14:47:25 EDT
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
Comment 16 Edilson Osorio Junior 2012-10-18 14:55:02 EDT
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
Comment 17 Chris Lumens 2012-12-14 12:40:52 EST
What's the status of this bug for F17?  F18?
Comment 18 peter gal 2012-12-30 07:02:56 EST
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.
Comment 19 joshua 2013-01-02 17:38:42 EST
Yes, I agree.  This needs to be documented in one of the Fedora Docs... the System Administrator's Guide or something
Comment 20 Fedora End Of Life 2013-07-03 15:39:03 EDT
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.
Comment 21 Fedora End Of Life 2013-07-31 14:27:30 EDT
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.
Comment 22 Radek Vykydal 2013-08-01 03:34:50 EDT
This should be fixed in Fedora 19. If you still hit the problem, feel free to reopen the bug.

Note You need to log in before you can comment on or make changes to this bug.