Red Hat Bugzilla – Bug 469110
Anaconda fails to write hostname for DHCP kickstart installs
Last modified: 2008-11-03 17:48:58 EST
Created attachment 321878 [details]
Kickstart with DHCP networking
Description of problem:
When anaconda gets a hostname assigned from DHCP in F8 it writes this host name to /etc/sysconfig/network on the installed system. The version currently in rawhide doesn't do this, leaving the installed system with a host name of localhost.localdomain.
Version-Release number of selected component (if applicable):
Kickstart install with this network configuration:
network --bootproto=dhcp --onboot=on --noipv6
Steps to Reproduce:
1. Install a system using a kickstart with DHCP
2. Reboot into the newly-installed system
3. Hostname at login prompt is localhost.localdomain
Hostname at login prompt is localhost.localdomain
Hostname at login prompt is testmachine.mydomain.com
The names have been changed to protect the innocent.
The kickstart is attached.
We use cobbler, but DHCP is on a separate server.
Are you netbooting or CD booting? Where is the kickstart file located that you are providing to anaconda (net location, local media, etc)?
Using your kickstart file as a base and performing two types of installs, I cannot reproduce this issue. I have performed the following types of kickstart installs:
1) PXE boot, kickstart file provided by ks=http://tenon.honolulu.burdell.org/ks/mortise.cfg
2) CD boot, kickstart file provided by USB flash drive as ks=hd:sdb1:/mortise.cfg
Both installs succeeded and wrote:
to the /etc/sysconfig/network file. Both installs were using this network line in the kickstart file:
network --device-eth0 --bootproto=dhcp --onboot=on
We're using the PXE kernel, but booting it off a CD since we don't actually use PXE. This CD, created by ``cobbler buildiso'', simply boots using that kernel, pulls down the stages and kickstart from the cobbler server, and proceeds as a regular net-based installation.
The fact that it's cobbler shouldn't really make a difference here since ultimately what's running is a kickstart install through anaconda.
Are you using the latest rawhide tree available? If you can run through it again with the latest rawhide tree and see if it happens again, that would be useful to me. If it does happen with the latest rawhide tree, attach logs from the install (in root's home directory on the installed system) to this bug report.
I'm going to leave it as CLOSED WORKSFORME. If you can verify that it's still happening, attach the log and reopen the bug.
It turns out our DHCP server wasn't actually handing out hostnames, so maybe anaconda was calling gethostbyname or the like to get the hostname in F8 but not doing so any more. On Monday I'll try doing an install with DHCP set up correctly and see if that fixes the issue for us.
Anaconda relies on DNS now to guess your hostname. Assuming you provide DNS servers for a manual configuration or the DHCP server hands out DNS servers, /etc/resolv.conf is updated and we do lookups using that. If we get something back for your IP, we use it. The DHCP server does not have to hand out a hostname, just DNS servers that have a record for your IP address.
If anaconda can't figure out what to do, we fall back on localhost.localdomain. For more details on what anaconda does, see getDefaultHostname() in network.py.
Then there might still be a problem of some sort. Every host I have tried installing so far has had both forward and reverse DNS working correctly, and the DHCP server has handed out the addresses for the DNS servers as well.
We fixed our DHCP server so it hands out hostnames and now it works! Perhaps all is not as it seems as far as solely using DNS is concerned.