Bug 469110 - Anaconda fails to write hostname for DHCP kickstart installs
Summary: Anaconda fails to write hostname for DHCP kickstart installs
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: David Cantrell
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-10-29 22:32 UTC by Garrett Holmstrom
Modified: 2008-11-03 22:48 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-10-31 03:35:36 UTC
Type: ---
Embargoed:


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

Description Garrett Holmstrom 2008-10-29 22:32:27 UTC
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-31 02:19:57 UTC
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-31 03:35:36 UTC
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 16:30:57 UTC
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 04:27:55 UTC
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 18:02:22 UTC
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 23:17:13 UTC
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-02 02:20:46 UTC
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 22:48:58 UTC
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.