Description of problem: It appears the ip= boot option, as well as many others no longer work. Version-Release number of selected component (if applicable): Fedora 17 How reproducible: everytime Steps to Reproduce: 1. boot from netinst image 2. edit boot options to include ip=172.16.11.2 Actual results: Error from dracut Warning: dracut FATAL: For Argument 'ip=172.16.11.2'\nSorry, unknown value '172.16.11.2' Expected results: For the install boot to proceed with the ip address configured. Additional info: asknetwork also fails, but does so silently -- the install proceeds, but the network config is never prompted for.
If dracut is parsing the ip= parameter, it has a different syntax in mind (See the Network section at http://fedoraproject.org/wiki/Dracut/Options ) What happens if you fill in the full details per the dracut syntax?
Using the dracut syntax stops the dracut failure, but doesn't set the ip address. So I'm still left with non working isntall.
Ok, we're going to want the full log set, anaconda.log, program.log, basically /tmp/*log from the install environment, which if you still have the system in an installed state you can grab from /var/log/anaconda/*
Uh, the whole point here is that I can't install the system in the first place because I can't set the IP address correctly...... For example, there's a dhcp server on the network that will handout addresses, but they'll be non working. So I need to be able to either do asknetwork or ip= to set some other ip address. However, neither works..... the installer either doesn't set the address listed in ip= or ignores the asknetwork option and plows on using the dhcp address it gets, and then complains it can't find any repos (which is correct based on it using the dhcp address it gets).
Can you please provide the exact arguments you're using to boot the installer?
I boot from the netinst image. I hit tab to edit the options. After the 'quiet' option I add: 'ip=172.16.11.2' -- that leads to the initial failure. After your reference to the Dracut docs, I used 'ip=172.16.11.2::172.16.11.1:255.255.255.0', which I *think* is right from the docs, but I'm not sure. That syntax results in no error reported, but the ip address isn't set to 172.16.11.2
Playing with the options some more, I've got something that mostly works. I needed to do more of the config. So if I do, for example, ip=128.143.12.155::128.143.12.1:255.255.0.0:ciclamino.itc.virginia.edu:em1:off I get the right behaviour. While this will work, it's more restrictive than previous methods because I have to give the device name. Previously (and as still documented for 17), you could use the MAC address in ksdevice. This is especially useful in cases where you don't know what the device name will be. This was most common in upgrading from versions of Fedora that used the old eth* names. Oddly, it looks like only the ip= parameter is not being processed by anaconda. On the assumption that the docs are wrong and all the network options are now done by dracut, I used the nameserver= option (for dracut) and I have no DNS. If I use the anaconda dns= option, it does the right thing.
Another option that's not working is kssendmac. It doesn't do anything. I see in the anaconda source a referernce to it being renamed to 'inst.ks.sendmac', but that using that also doesn't result in the HTTP_X_RHN_PROVISIONING_MAC_* headers being sent. (let me know if you'd rather have this as a separate bug)
Please do a separate bug for separate issues. We are using dracut to handle most of the anaconda options now, although it is a bit in a transition state. Some of the options conflicted with dracut and thus syntax had to change (like ip=), but some did not conflict and were (not yet) collapsed into a single option that can be shared by both dracut and Anaconda. We are working on updated docs for F17, just ran out of runway at the end.
*** Bug 827154 has been marked as a duplicate of this bug. ***
I used the options of ip=<ip>::<gw>:<nm>:<hostname>:em1:off and nameserver=<nameserver> with the network install CD and the installation started up with no error messages. I checked the /etc/sysconfig/network-scripts/ifcfg-em1 file and it had the proper fixed IP address, gateway, netmask, etc. However, it was impossible to do a network install - the computer refused to connect to the repo I had given it. I checked and the repo information was all correct as shown by the retry gui. Further checking showed that the computer was trying to connect to DHCP non-stop. Since our network utilizes web-based authentication, there was no way for the computer to use its DHCP address to access the repo. Is there any options that can be given at boot time that would prevent the computer for looking for a DHCP address and force it to use the fixed IP address that I give it?
A draft of the updated boot option documentation is available here: http://wwoods.fedorapeople.org/doc/boot-options.html As Jesse mentioned in comment #9, there's an unfortunate collision between the way dracut handles the 'ip' option and the way anaconda used to handle it. I've fixed this in upstream dracut, but sadly it didn't make it into Fedora 17, so you have to use the dracut-style 'ip' option for static configuration of ipv4 addresses. (In reply to comment #7) > Previously (and as still documented for 17), you could use the MAC address > in ksdevice. This is especially useful in cases where you don't know what > the device name will be. This was most common in upgrading from versions > of Fedora that used the old eth* names. If you want to specify a device by MAC address you can do: ifname=eth0:<MAC> ip=<ip>::<gw>:<nm>:[hostname]:eth0:off And, in fact, if you do 'ksdevice=<MAC>' it should rewrite this to 'ifname=eth0:<MAC>', so this should be equivalent: ksdevice=<MAC> ip=<ip>::<gw>:<nm>:[hostname]:eth0:off (hostname is optional, by the way - you can leave it empty if you like) If the system only has one network interface, you should be able to leave the interface name out entirely, like so: ip=<ip>::<gw>:<nm>:[hostname]::off And dracut should configure the (lone) network interface with the given arguments. (In reply to comment #11) > Is there any options that can be given at boot time that would prevent the > computer for looking for a DHCP address and force it to use the fixed IP > address that I give it? If you used an "ip=...:em1:off" argument, it shouldn't be trying DHCP on em1. Are you sure "em1" is the right device name? Does the system have multiple network interfaces? NetworkManager's default is to try DHCP on all unconfigured interfaces, which would explain why you're seeing DHCP requests. > Oddly, it looks like only the ip= parameter is not being processed by > anaconda. On the assumption that the docs are wrong and all the network > options are now done by dracut That's correct. The documentation is being updated now - see the link above for the draft. > I used the nameserver= option (for dracut) > and I have no DNS. If I use the anaconda dns= option, it does the right > thing. That's strange. This might warrant a separate bug report if it persists after you sort out the DHCP stuff above.
On a machine with only 1 network interface: ip=<ip>::<gw>:<nm>:::off -- does not work, the machine is still requesting and using a dhcp address. ip=<ip>::<gw>:<nm>::eth0:off -- works These are both with no other options set. On a machine with 2 network interfaces: ifname=eth0:MAC ip=<ip>::<gw>:<nm>::eth0:off -- works
This is for rhel 6.3 also. I am testing locally in a virtual infrastructure (kvm/qemu under F17). I was able to get an IP kickstart with dns successfully to install with a VM (only 1 interface): as in comment 13 ifname=eth0:MAC ip=<ip>::<gw>:<nm>::eth0:off I needed to specify teh ifname even though there is only 1 interface. DNS would not work with the "nameserver" option I had to use "dns=<xxx>" The documentation for rhel6 and F17 needs to be updated as well , many clients use this method to kickstart due to not having DHCP infrastructure for security reasons.
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.