From Bugzilla Helper: User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.4.0-0.99.11 i586) Installed system on a machine which the DNS properly identified it (mark.hou.us.ray.com). The installation script displayed that name - entered OK to confirm it. After completing the install and rebooting, the system name was "localhost.localdomain". Had to use linuxconf to reset it. Reproducible: Sometimes Steps to Reproduce: 1.Install system 2.Reboot after install - look at host name on X display 3. Actual Results: System name should have matched the value entered during installation. Did a reinstall later (had to repartition the disk) - worked the second time. Did not do anything apparently differently. Expected Results: System name is set per the installation process.
*** Bug 25813 has been marked as a duplicate of this bug. ***
Greetings, I too experienced the behavior that Mark documented. My clients use DHCP to configure themselves. I think that pump is not setting the hostname correctly in /etc/hosts and /etc/sysconfig/network. Regards, Joe Kotran
We (Red Hat) should really try hard to fix this before next release.
Can you both send the contents of /etc/sysconfig/network-scripts ifcfg-eth0 and /etc/sysconfig/network?
I see this too. /etc/sysconfig/network: NETWORKING=yes HOSTNAME=localhost.localdomain /etc/sysconfig/network-scripts/ifcfg-eth0: DEVICE=eth0 BOOTPROTO=dhcp ONBOOT=yes On boot: [root@localhost /root]# hostname localhost.localdomain [root@localhost /root]# service network restart (... it succeeds ...) [root@localhost /root]# hostname myhostname.surrey.redhat.com
I've not seen this recently, but now it's a different DHCP server. Perhaps it was a DHCP server configuration thing?
I couldn't reproduce the problem here in our test lab testing both the fisher public beta and a more recent internal test tree (qa0301.0) ... :(
Does the DHCP server use 'use-host-decl-names on' or 'option host-name ...'? I think it might be to do with that.
Hmm, I just tried an install against a DHCP server without those options but I can't reproduce this with Wolverine. Maybe it really is fixed already.
We also tried to reproduce with a post-Wolverine tree, and could not. Seems to be fixed.
On a fresh 7.1 installation, a very similar problem occurred, which meant sendmail was very slow in delivering mail. /etc/hosts had: 127.0.0.1 my.local.fqdn my locallost.localdomaon localhost sendmail log messages had the relay as my.local.fqdn instead of localhost.localdomain (which it had been in Fisher and Wolverine) When I added a line in /etc/hosts with my internal LAN address and private hostname, sendmail started working at normal speed.