DescriptionBill Nottingham
2010-06-24 18:27:13 UTC
+++ This bug was initially created as a clone of Bug #607764 +++
+++ This bug was initially created as a clone of Bug #468436 +++
Apparently introduced with NetworkManager. Anaconda no longer generates a default vendor class id in DHCP request for network installs.
Additionally, the dhcpclass= option appears to have no affect.
--- Additional comment from dcantrell on 2008-10-24 18:11:34 EDT ---
Since we're using NetworkManager in anaconda now, the proper way to get the dhcpclass= parameter to dhclient is to add a line to /etc/dhclient-DEVICE.conf and let NetworkManager pick that up.
I've patched anaconda to do just this. This change will be in anaconda-11.4.1.51-1. Once that appears in rawhide, can you test it out and if it works, and report findings here?
Thanks.
--- Additional comment from fedora-triage-list on 2008-11-25 23:12:36 EST ---
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
--- Additional comment from curtis on 2008-11-28 20:54:49 EST ---
Verified fixed in f10. Now dhcpclass= works. And is *required* for legacy behavior of DHCP option 60.
--- Additional comment from curtis on 2009-10-11 22:30:45 EDT ---
Re-opening. This bug is back in Rawhide.
Even with dhcpclass=anaconda there is no more Option 60 in the lease request.
--- Additional comment from dcantrell on 2009-10-12 22:17:37 EDT ---
This is now a problem in NetworkManager. When NM builds /var/run/nm-dhclient-ethX.conf, it's not copying over the settings from /etc/dhcp/dhclient-ethX.conf. Here's a patch for NetworkManager:
diff --git a/src/dhcp-manager/nm-dhcp-dhclient.c b/src/dhcp-manager/nm-dhcp-dhcl
index ac7d9f5..c1f76c2 100644
--- a/src/dhcp-manager/nm-dhcp-dhclient.c
+++ b/src/dhcp-manager/nm-dhcp-dhclient.c
@@ -405,7 +405,9 @@ create_dhclient_config (NMDHCPDevice *device,
g_return_val_if_fail (device != NULL, FALSE);
-#if defined(TARGET_SUSE)
+#if defined(TARGET_REDHAT)
+ orig = g_strdup (SYSCONFDIR "/dhcp/dhclient-%s.conf", device->iface);
+#elif defined(TARGET_SUSE)
orig = g_strdup (SYSCONFDIR "/dhclient.conf");
#elif defined(TARGET_DEBIAN)
orig = g_strdup (SYSCONFDIR "/dhcp3/dhclient.conf");
This is my fault. When I owned the dhcp package, I reorganized it to keep all dhclient and dhcpd configuration files in /etc/dhcp rather than /etc. I did this to reduce clutter in /etc. Problem is, I needed to teach NetworkManager about this new location on Fedora.
Dan, fix should be simple enough for NM. In loader, I am writing out /etc/dhcp/dhclient-DEVICE.conf with a single line that is "send vendor-class-identifier ...;" based on what the user provides. Actually, there's always a vendor class identifier even if the user doesn't override it.
--- Additional comment from curtis on 2009-10-13 12:45:17 EDT ---
It would be nice if we went back to legacy behavior with "anaconda" in the default. Then we'd only need dhcpclass= option to override and set something else.
--- Additional comment from dcantrell on 2009-10-13 15:58:23 EDT ---
(In reply to comment #6)
> It would be nice if we went back to legacy behavior with "anaconda" in the
> default. Then we'd only need dhcpclass= option to override and set something
> else.
The interface in anaconda isn't changing. You will still just pass dhcpclass= on the boot line to override the vendor class identifier used during installation. How that works underneath the installer is where the bug is, hence reassigning it to anaconda.
--- Additional comment from fedora-triage-list on 2009-11-16 04:33:18 EST ---
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
--- Additional comment from dcbw on 2010-06-15 12:10:28 EDT ---
David, dhclient has afaik always used /etc/dhclient-ethX.conf. Does anaconda use a different location?
# allow users to use generic '/etc/dhcp/dhclient.conf' (as documented in manpage!)
# if per-device file doesn't exist or is empty
if [ -s /etc/dhclient-${DEVICE}.conf ]; then
DHCLIENTCONF="-cf /etc/dhclient-${DEVICE}.conf";
else
DHCLIENTCONF='';
fi;
is there some reason it's now /etc/dhcp/dhclient-<iface>.conf?
--- Additional comment from dcbw on 2010-06-23 18:29:48 EDT ---
Ok, is there any reason why the loader uses /etc/dhcp/dhclient-<iface>.conf while the rest of anaconda uses /etc/dhclient-<iface>.conf?
loader/net.c: /* remove dhclient-DEVICE.conf if we have it */
loader/net.c: if (asprintf(&ofile, "/etc/dhcp/dhclient-%s.conf", devs[i]->device) == -1) {
loader/net.c: if (asprintf(&ofile, "/etc/dhcp/dhclient-%s.conf", iface->device) == -1) {
network.py: # /etc/dhclient-DEVICE.conf
network.py: dhclientfile = os.path.join("/etc/dhclient-%s.conf" % devName)
network.py: self._copyFileToPath(dhclientfile, instPath)
packages.py: glob.glob('/etc/dhclient-*.conf')
I can make NM check both locations I guess...
--- Additional comment from dcantrell on 2010-06-24 13:13:46 EDT ---
(In reply to comment #10)
> Ok, is there any reason why the loader uses /etc/dhcp/dhclient-<iface>.conf
> while the rest of anaconda uses /etc/dhclient-<iface>.conf?
The dhcp package moved configuration files to /etc/dhcp at the end of 2008:
* Thu Dec 18 2008 David Cantrell <dcantrell> - 12:4.0.0-34
- Move /etc/dhclient.conf to /etc/dhcp/dhclient.conf
- Move /etc/dhcpd.conf to /etc/dhcp/dhcpd.conf
The incorrect references in anaconda need to be changed.
--- Additional comment from dcbw on 2010-06-24 14:11:48 EDT ---
And we need to make sure that initscripts are updated too.
Comment 3RHEL Program Management
2010-06-24 18:52:58 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release. Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release. This request is not yet committed for
inclusion.
Comment 6releng-rhel@redhat.com
2010-11-10 20:40:31 UTC
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.