Bug 107241

Summary: empty resolv.conf after installation (no primary dns)
Product: [Fedora] Fedora Reporter: Erno Härkönen <vjih>
Component: anacondaAssignee: Jeremy Katz <katzj>
Status: CLOSED NEXTRELEASE QA Contact: Mike McLean <mikem>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: a.t.meinen, dgj
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-08-15 15:45:28 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:
Attachments:
Description Flags
Anaconda kick start file
none
patch against network.py I used none

Description Erno Härkönen 2003-10-16 01:51:54 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031009

Description of problem:
During the installation I selected fixed IP for my network card and manual
configuration ip/netmask, hostname, gateway and primary dns (not DHCP).
After installation resolv.conf file was empty and I had to run
redhat-config-network to add primary dns.


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. run installation
2. enter values for fixed ip address/netmask, hostname, gateway and primary dns
in network configuration


Actual Results:  dns is not working after the installation

Expected Results:  resolv.conf should contain correct primary dns address

Additional info:

"/root/anaconda-ks.cfg" contains the following lines about network configuration
after installation:

network --device eth0 --bootproto static --ip 192.168.55.254 --netmask
255.255.255.0 --gateway 192.168.55.1 --hostname deepspace
network --device eth1 --onboot no --bootproto dhcp --hostname deepspace

I used 192.168.0.5 as primary dns during the installation and I did installation
twice to check that I entered correct value the first time.

Comment 1 Jeremy Katz 2003-10-16 02:32:46 UTC
This has been reported before, but I've yet to get it to occur...  what metho
did you use for installation and was this a graphical or text mode install?

Comment 2 Erno Härkönen 2003-10-16 02:46:51 UTC
Created attachment 95219 [details]
Anaconda kick start file

Full anaconda-ks.cfg file

Comment 3 Erno Härkönen 2003-10-16 02:49:25 UTC
I used graphical installation with Fedora test3 cds. I press enter to the first
prompt and during the installation I selected custom and manual partitions with
disk druid.

I clicked back and forward buttons to check that I had entered the correct
values during the installation if that makes any difference.


Comment 4 Erno Härkönen 2003-10-16 16:38:21 UTC
In source file "anaconda-9.0.95/network.py" function lookupHostname uses dhcp to
get primaryNS. It shouldn't do this as I don't have eth1 activated on the boot
and eth0 is configured not to use dhcp.

I changed this function so that it first tries lookup with manual ip settings
and dhcp after that. (dictionary values self.netdevices.values() might be in
random order and it made eth1 to be the first in for loop)

I tried my updated network.py with "linux updates" boot option, but it seems
that isys.configNetDevice() call in network.py function lookupHostname somehow
changes module configuration and I get both eth0 and eth1 pointing to via-rhine.
"resolv.conf" file is now as it should be but "modules.conf" isn't.

from modules.conf:
alias eth0 via-rhine
alias eth1 via-rhine

as it should be like:
alias eth0 8139too
alias eth1 via-rhine


Comment 5 Erno Härkönen 2003-10-16 16:40:42 UTC
Created attachment 95229 [details]
patch against network.py I used

These are the modifications I used during testing. resolv.conf is working now,
but modules.conf isn't.

Comment 6 Tino Meinen 2003-10-16 17:13:30 UTC
I think I have the same problem. This occured with Fedora Core test2 and test3,
graphical install.
I have two network cards:
eth0 is a Realtek needing the 8139too driver
eth1 is a 3Com needing the 3c59x driver. This one is conneted to the 'internet'
I let the installer set it up with DHCP
I put the firewall on, and checked ssh-connections allowed.

After installation, modules.conf reads:
alias eth0 8139too
alias eht1 3c59x
alias eth2 8139too 

(note that it has configured 3 eth-devices, while I only have two cards)

resolv.conf is empty

I've been playing around to try to get networking to work post-install, but have
not succeeded yet, so I'm reporting this from my old Red Hat 9.
(RedHat 9 and previous RedHats had no problems getting networking to work during
install)

Hope this info helps, I will try to get more information on this, but I'm not a
hacker.


Comment 7 Jeremy Katz 2003-10-16 21:11:46 UTC
Can you try with the updates.img at http://people.redhat.com/~katzj/fedora/fc1t3/?

Based off of the patch here, but done a little differently.

Comment 8 Tino Meinen 2003-10-16 21:27:45 UTC
I will gladly help,
What should I do with the image?
I'm rather blond-haired in this.

Comment 9 Jeremy Katz 2003-10-16 21:34:01 UTC
Instructions for using update disks are at
http://rhlinux.redhat.com/anaconda/updatedisks.html

Comment 10 Tino Meinen 2003-10-16 22:53:05 UTC
OK, I used the severn-t3-updates.img on the floppy during the install.
Install went fine, but the configuration files modules.conf and resolv.conf show
up with the same information (resolv.conf empty)

During the anaconda install, configuration of the /dev/eth0 and /dev/eth1 
I had a look what happens when you press the edit button. This is what it shows
for the devices:

Configure eth0

Configure eth1 - 3ComCorporation | 3c900B- TPO [Etherlink XL TPO]


After install, I brought up the Hardware browser. This shows:

3c900B - TPO [Etherlink XL TPO] /dev/eth1
RTL-8139/8139C/8139C+           /dev/eth2

When I do a Network configuration with the wizard it shows

RTL-8139/8139C/8139C+             (eth2)
3c900B - TPO [Etherlink XL TPO]   (eth1)
RTL8139, SMC EZ Card FastEthernet (eth0)

Ok
I hope this helps.
Thanks



Comment 11 Erno Härkönen 2003-10-17 11:05:49 UTC
I tried severn-t3-updates.img and I got working resolv.conf file, but
modules.conf was not as it should have been.

During the installation the file /tmp/modules.conf contains:
alias eth0 8139too
alias eth1 via-rhine

And /mnt/sysimage/etc/modules.conf gets written with:
alias eth0 via-rhine
alias eth1 via-rhine
...

This brings kudzu up on the first boot as eth0 should be 8139too.
As I previously mentioned that isys.configNetDevice() which now gets called
probably has something to do with this as I had working modules.conf without
this updates image.


Comment 12 Erno Härkönen 2003-10-17 13:45:17 UTC
Ok, kudzu (packages.py doPostInstall) is reponsible for writing the final
modules.conf in /mnt/sysimage/etc/ directory. This will fail if network
interface is up. I made installation to pause after lookupHostname and manually
run "/usr/sbin/ifconfig eth0 down" after which kudzu made correct values in
modules.conf.

So lookupHostname should turn network interface down before returning ip
address, or kudzu should be fixed to handle situation where network interface is
active.


Comment 13 Jeremy Katz 2003-10-20 19:40:53 UTC
kudzu should handle this case -- please file another bug against kudzu for it
(because if I just move this one over, it'll get far too confusing with the
number of things going on).

Initial issue seems to be fixed, though.

Comment 14 Tino Meinen 2003-10-23 03:31:29 UTC
I removed the Realtek card and let the 3Com in as the only card.
I reinstalled FCtest3 with the anaconda-updates mentioned in this bug.
Modules.conf looks good now (the same as in RH9), sadly: resolv.conf is still empty.

However. I think my particular problem lies somewhere else. (don't know where)
Even when copying over resolv.conf over from my working RH9 install, or
manually, configuring the ethernet device: I am not able to get the network
activated at all.
Networking was always a non-configuration thing with linux installs. I didn't
know networking could be so difficult when it doesn't work.

I guess I have to file a bug, but I don't know to wich module.
Surely anaconda is not the only problem as I can't get network configuration
right with redhat-config-network as well.
(btw I tried both setting the firewall on or off; no difference)

Any suggestions gladly accepted.



Comment 15 Tino Meinen 2003-10-25 04:36:32 UTC
bug 107389 showed me what the problem was; if I disable kudzu during startup,
everything gets configured correctly and I am able to network.


Comment 16 Jeremy Katz 2003-11-28 02:50:30 UTC
*** Bug 110973 has been marked as a duplicate of this bug. ***