Bug 448096
| Summary: | Network installation stops at "Missing Nameserver" dialog | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Erik Heckers <erik.heckers> | ||||
| Component: | anaconda | Assignee: | Dave Cantrell <dcantrell> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 9 | CC: | hannsj_uhl | ||||
| Target Milestone: | --- | Keywords: | Reopened | ||||
| Target Release: | --- | ||||||
| Hardware: | i386 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2008-12-01 18:08:20 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | 458183 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
|
Description
Erik Heckers
2008-05-23 13:42:17 UTC
According to the documentation at http://fedoraproject.org/wiki/Anaconda/Kickstart: "The line for static networking is more complex, as you must include all network configuration information on one line. You must specify the IP address, netmask, gateway, and nameserver." Even if I provide a nameserver the installation fails the same way: network --device eth0 --bootproto static --ip __myip__ --netmask 255.255.255.0 --gateway ___mygw___ --hostname ___myhost___ --nameserver ___nameserver___ The problem is that it seems to be a mandatory requirement for Fedora 9 that the DHCP-Server (used temporarily during PXE boot procedure) provides a nameserver. The network installation should work even if the DHCP server does not provide name server data. Defining nameserver data is optional. (And all our RHEL 3,4,5 installation work without). Bye Erik Can you post the kickstart file you are using so I can try to duplicate the problem here? You can use the kickstart file from the first failing installation round:
1) Install your client via network (PXE).
It is important to use a DHCP server not providing a
name server (=DNS data).
I can provide the minimalistic config file we use here if needed!
(Every client gets his (static) IP, the IP of the next server and
the location of the bootstrap file (pxelinux.0)).
2) The "Missing Nameserver" dialog will appear. You leave that entry
empty.
The ks= parameter currently point to an empty or non-existing kickstart file,
so you have to run an interactive installation:
3) Run a default installation (configure static IP for eth0, e.g.
the same one that is provided by the DHCP server. If it asks for
a nameserver leave it empty again - I'm not sure it is asking at all).
To speed up installation you can unmark that "Productivity" software selection.
4) After installation you have a new kickstart file /root/anaconda-ks.cfg
I think this file doesn't list any name server data (e.g the "Use empty
name server" information is missing).
So if you now reinstall with this kickstart file it will ask again
for the missing nameserver, breaking the automated non-interactive installation
procedure for Fedora Core 9!
I think it doesn't look at the kickstart file at all before asking the
information, because it detects a missing kickstart file only after you
already answered the question.
I think the solution is simply to get rid of that dialog again,
e.g. by using an empty nameserver if none was provided via DHCP.
Bye
Erik
I have to apologize because not everything I stated above is correct.
I somehow messed up testing by changing kickstart file on the wrong
server (that wasn't active during the tests).
What I can confirm so far is this:
1) If the kickstart file is missing or empty, the installer asks for the
kickstart file. Only afterwards the "Missing Nameserver" comes up!
So my statement (about the flow of events) in the previous posting was wrong!
2) I reconfigure the DHCP-Server so that (for that one client only) a
nameserver was defined ("option domain-name-servers <nameserver IP>").
If I do this (and set "--bootproto dhcp" in kickstart file) the
dialog does not come up (No nameserver defined in kickstart file).
3) I still found no way of bypassing the "Missing Nameserver" dialog
when using the old DHCP configuraton by setting the nameserver in
the kickstart file (and what I want to achieve at the end is to
set an empty nameserver, like it is possible in the Missing Nameserver dialog.
4) The current kickstart file I use seems to be the one created as
/root/anaconda-ks.cfg by a previous installation with empty nameserver.
There is no "set nameserver to empty value" instruction in that file,
so when using that file the installation will ask again.
Bye
Erik
Created attachment 315643 [details]
Console output from two different installations
Hello! Finally I found something interesting! The attached output is from Console "Alt-F3" when the "missing Nameserver" dialog is active on Console "Alt-F1". The first installation has no nameserver defined in the "network" line of kickstart. Because the DHCP server doesn't send any information about a nameserver there is a WARNING at the end of the output. For the second installation I added "--nameserver <my_nameserver>" to the kickstart file. From the output you can see that it reads that data from the kickstart file, but later on it ignores that data and gives the same WARNING. So when using a DHCP-server that doesn't send a name server you always get that WARNING (and the missing nameserver dialog). Settings from kickstart are ignored! Erik About a billion things have changed in Network Manager since this was filed. Could you please retest with a recent rawhide and let us know if the problem still exists? The missing nameserver check is not present in the rawhide anaconda anymore and I can't seem to trigger this bug anymore, so I'm going to say it's fixed. I can confirm that this problem is gone with Fedora 10. (I haven't been able to test it with Fedora 9 as I do not know where to get updated "images" of needed files like minstg2 ...). Closing per comment #10 |