Description of problem: Anaconda doesn't set the DHCP vendor identifier string. It should usually be something like "anaconda-Linux etc.". This breaks network installs that rely on this feature, e.g. if the DHCP server is configured to only give leases to pxe clients and anaconda. The dhcpclass= option also has no effect. Note: I have only tested this with PXE installs. Version-Release number of selected component (if applicable): 17.20 How reproducible: Always Steps to Reproduce: 1. PXE-boot the F17-Beta install images, setting repo etc. as appropriate 2. Look in the dhcpd.leases file (assuming ISC dhcpd) for leases given to anaconda Actual results: No vendor-string. Expected results: vendor-string set to "anaconda-something".
That might be something we could do.
Hi, We have a similar problem but not exactly the same. We rely on the following DHCP options : option rfc3442-classless-static-routes option rfc3442-classless-static-routes code 121 = array of unsigned integer 8; During a PXE install of Fedora 17, the dhclient doesn't set these options so we don't have correct routes to reach one of our subnet. With Fedora 16 Anaconda, there is no problem so we keep using it to install some Fedora 17.
There is code to do this as of anaconda 17.13-1. We put the details in /etc/dhclient.conf. Can you attach that file from your install attempts and all the log files found in /tmp/*log ? (individual text attachments please)
(In reply to comment #3) > There is code to do this as of anaconda 17.13-1. We put the details in > /etc/dhclient.conf. Can you attach that file from your install attempts and > all the log files found in /tmp/*log ? (individual text attachments please) Of note, the /etc/dhclient.conf file only gets written out in dracut land, so you'll have to look at /run/initramfs/etc/dhclient.conf once you've gotten past dracut and into anaconda land.
Created attachment 599713 [details] dhclient.conf from just past dracut Weird enough, vendor-class-identifier is correctly set and dhclient is configured to send it, but it never reaches the DHCP server.
Created attachment 599717 [details] Log from anaconda
Created attachment 599719 [details] program.log
Created attachment 599720 [details] storage.log
Created attachment 599721 [details] syslog from anaconda
Ok, that sounds like something going wrong in dracut land. I'll toy a bit more to see what's really going on.
Just tried Fedora 18, where Anaconda does set vendor class. But there is something else going on. The install (in this case kickstart) queries DHCP a third time, this time without a vendor class, making the install fail. Following this on the DHCP side, this is what happens: 1. Booting via PXE, vendor-class "PXEClient-something", gets an address 2. Starts Anaconda, vendor-class "anaconda-something", gets an address 3. Queries the DHCP server yet again, no vendor-class, no address After step 3, the install no longer is connected to the network and fails.
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.
I'm seeing this on F21. It's not currently causing me any trouble, but it is kind of odd. I have kickstart files which specify static network configuration, but the hosts must DHCP (not PXE; I either boot from USB or a vmlinuz/initrd.img pair via GRUB). The first DHCP request, I suppose made by dracut in order to download the rest of the installer, has a class ID set (anaconda-Linux followed by a kernel version and arch) but then once anaconda is running something else renews the lease and passes no class ID.
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. 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 EOL if it remains open with a Fedora 'version' of '21'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 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 this bug is closed as described in the policy above. 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.
Created attachment 1090594 [details] Fedora 23: tcpdump This issue still exists in Fedora 23. Attached pcap file shows that second DHCP run with DHCP transaction ID 0xc94fab59 does not contain Option 61 - Client identifier.
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. 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 EOL if it remains open with a Fedora 'version' of '23'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 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 this bug is closed as described in the policy above. 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 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 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. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.