Bug 469110 - Anaconda fails to write hostname for DHCP kickstart installs
Anaconda fails to write hostname for DHCP kickstart installs
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: David Cantrell
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-29 18:32 EDT by Garrett Holmstrom
Modified: 2008-11-03 17:48 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-30 23:35:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Kickstart with DHCP networking (6.47 KB, text/plain)
2008-10-29 18:32 EDT, Garrett Holmstrom
no flags Details

  None (edit)
Description Garrett Holmstrom 2008-10-29 18:32:27 EDT
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):
anaconda 11.4.1.50

How reproducible:
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
  
Actual results:
Hostname at login prompt is localhost.localdomain

Expected results:
Hostname at login prompt is testmachine.mydomain.com

Additional info:
The names have been changed to protect the innocent.
The kickstart is attached.
We use cobbler, but DHCP is on a separate server.
Comment 1 David Cantrell 2008-10-30 22:19:57 EDT
Are you netbooting or CD booting?  Where is the kickstart file located that you are providing to anaconda (net location, local media, etc)?
Comment 2 David Cantrell 2008-10-30 23:35:36 EDT
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:

    HOSTNAME=mortise

to the /etc/sysconfig/network file.  Both installs were using this network line in the kickstart file:

    network --device-eth0 --bootproto=dhcp --onboot=on
Comment 3 Garrett Holmstrom 2008-10-31 12:30:57 EDT
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.
Comment 4 David Cantrell 2008-11-01 00:27:55 EDT
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.

Thanks.
Comment 5 Garrett Holmstrom 2008-11-01 14:02:22 EDT
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.
Comment 6 David Cantrell 2008-11-01 19:17:13 EDT
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.
Comment 7 Garrett Holmstrom 2008-11-01 22:20:46 EDT
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.
Comment 8 Garrett Holmstrom 2008-11-03 17:48:58 EST
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.

Note You need to log in before you can comment on or make changes to this bug.