Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
I wish to install RHEL, via kickstart, using DHCP. To do this in my environment I need a custom dhcp vendor identifier. There are options, "dhcpclass", to do this but it doesn't reach the highest level of anaconda properly.
Process from my perspective:
Server starts.
PXEClient DHCPs a public ip in a build range by matching on vendor identifier.
It uses the configuration file:
```
DEFAULT linux
LABEL linux
KERNEL boot/Fedora-23-x86_64-vmlinuz
APPEND initrd=boot/Fedora-23-x86_64-initrd.img ks=http://build00.internal.ntoggle.com:80/unattended/provision ks.device=bootif network ks.sendmac inst.dhcpclass=foreman
IPAPPEND 2
```
This then starts (dracut?).
Dracut does a DHCP request with the foreman dhcpclass correctly, and gets the same lease.
At this point the automated install is started and we proceed until we reach:
network --onboot=no --bootproto dhcp --hostname node00.internal.ntoggle.com --device=fc:aa:14:ae:f8:d2 --dhcpclass=foreman
This then initiates another DHCP request with -no vendor identifier- as verified with Wireshark. It gets DHCPNAKed and fails to install at this point.
From the DHCPd perspective:
DHCPDISCOVER from fc:aa:14:ae:f8:d2 via enp2s0f0
DHCPOFFER on 66.150.120.242 to fc:aa:14:ae:f8:d2 via enp2s0f0
DHCPREQUEST for 66.150.120.242 (66.150.120.241) from fc:aa:14:ae:f8:d2 via enp2s0f0
DHCPACK on 66.150.120.242 to fc:aa:14:ae:f8:d2 via enp2s0f0
reuse_lease: lease age 22 (secs) under 25% threshold, reply with unaltered, existing lease
DHCPDISCOVER from fc:aa:14:ae:f8:d2 via enp2s0f0
DHCPOFFER on 66.150.120.242 to fc:aa:14:ae:f8:d2 via enp2s0f0
reuse_lease: lease age 22 (secs) under 25% threshold, reply with unaltered, existing lease
DHCPREQUEST for 66.150.120.242 (66.150.120.241) from fc:aa:14:ae:f8:d2 via enp2s0f0
DHCPACK on 66.150.120.242 to fc:aa:14:ae:f8:d2 via enp2s0f0
DHCPREQUEST for 66.150.120.242 from fc:aa:14:ae:f8:d2 via enp2s0f0: lease 66.150.120.242 unavailable.
DHCPNAK on 66.150.120.242 to fc:aa:14:ae:f8:d2 via enp2s0f0
Version-Release number of selected component (if applicable):
I have tested this against RHEL7.2 and Fedora 23.
How reproducible:
Well, every time? :)
Steps to Reproduce:
1. Set inst.dhcpclass=something in a pxeboot
2. Set --dhcpclass=something in a kickstart
3. Watch it fail to make it to dhcpd.
Actual results:
A failed lease attempt.
Expected results:
The lease is picked back up.
Additional info:
I've been banging my head against this problem for the last couple of days - until I found this BZ ...
For what it's worth, I've managed to work round the problem by using an Anaconda updates image containing just the file /etc/dhcp/dhclient.conf - which contains the line:
send vendor-class-identifier "myclass";
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://rhn.redhat.com/errata/RHEA-2016-2158.html
Description of problem: I wish to install RHEL, via kickstart, using DHCP. To do this in my environment I need a custom dhcp vendor identifier. There are options, "dhcpclass", to do this but it doesn't reach the highest level of anaconda properly. Process from my perspective: Server starts. PXEClient DHCPs a public ip in a build range by matching on vendor identifier. It uses the configuration file: ``` DEFAULT linux LABEL linux KERNEL boot/Fedora-23-x86_64-vmlinuz APPEND initrd=boot/Fedora-23-x86_64-initrd.img ks=http://build00.internal.ntoggle.com:80/unattended/provision ks.device=bootif network ks.sendmac inst.dhcpclass=foreman IPAPPEND 2 ``` This then starts (dracut?). Dracut does a DHCP request with the foreman dhcpclass correctly, and gets the same lease. At this point the automated install is started and we proceed until we reach: network --onboot=no --bootproto dhcp --hostname node00.internal.ntoggle.com --device=fc:aa:14:ae:f8:d2 --dhcpclass=foreman This then initiates another DHCP request with -no vendor identifier- as verified with Wireshark. It gets DHCPNAKed and fails to install at this point. From the DHCPd perspective: DHCPDISCOVER from fc:aa:14:ae:f8:d2 via enp2s0f0 DHCPOFFER on 66.150.120.242 to fc:aa:14:ae:f8:d2 via enp2s0f0 DHCPREQUEST for 66.150.120.242 (66.150.120.241) from fc:aa:14:ae:f8:d2 via enp2s0f0 DHCPACK on 66.150.120.242 to fc:aa:14:ae:f8:d2 via enp2s0f0 reuse_lease: lease age 22 (secs) under 25% threshold, reply with unaltered, existing lease DHCPDISCOVER from fc:aa:14:ae:f8:d2 via enp2s0f0 DHCPOFFER on 66.150.120.242 to fc:aa:14:ae:f8:d2 via enp2s0f0 reuse_lease: lease age 22 (secs) under 25% threshold, reply with unaltered, existing lease DHCPREQUEST for 66.150.120.242 (66.150.120.241) from fc:aa:14:ae:f8:d2 via enp2s0f0 DHCPACK on 66.150.120.242 to fc:aa:14:ae:f8:d2 via enp2s0f0 DHCPREQUEST for 66.150.120.242 from fc:aa:14:ae:f8:d2 via enp2s0f0: lease 66.150.120.242 unavailable. DHCPNAK on 66.150.120.242 to fc:aa:14:ae:f8:d2 via enp2s0f0 Version-Release number of selected component (if applicable): I have tested this against RHEL7.2 and Fedora 23. How reproducible: Well, every time? :) Steps to Reproduce: 1. Set inst.dhcpclass=something in a pxeboot 2. Set --dhcpclass=something in a kickstart 3. Watch it fail to make it to dhcpd. Actual results: A failed lease attempt. Expected results: The lease is picked back up. Additional info: