Bug 638634

The name you enter gets written out to a file on the installed system so when you reboot post-installation, it should be fine.  It's not meant to modify the hostname on the running live system.  If you reboot, do you see the proper hostname?

>        If you reboot, do you see the proper hostname?

No.

---
My bug description could be improved. My second attempt:

Steps to Reproduce:
1. During installation choose a computer name other than the default.
2. Reboot
3. Enter "uname -n" on a terminal
4. See what happens

Actually you don't need even uname. When I started a terminal after reboot the prompt was       
  my_name@localhost 
instead of 
  my_name@the_name_i_gave_to_my_computer_durint_install

I am not able to reproduce.
Could you post content of /etc/sysconfig/network, and attach /var/log/anaconda.syslog and /var/log/anaconda.log from installed ststem?

Today I created a brand new partition, reinstalled the same OS as before (I have it in a USB stick), and got exactly the same issue. So it is reproducible for me (or so it seems after two tests).

---------------

/etc/sysconfig/network:

NETWORKING=yes
NETWORKING_IPV6=no
HOSTNAME=localhost.localdomain
NTPSERVERARGS=iburst

OK, so there is a little inconsistency in my bug description. If I do "uname -n" I get "localhost.localdomain" but the prompt still says for example "root@localhost" as I reported.

------------

/var/log/anaconda.syslog - there is no such file
/var/log/anaconda.log - attached, plus I attached another another log.

------------

I looked at anaconda.log (attached) and found the following line:

==
19:20:10,135 DEBUG anaconda: Exception caught trying to get host name of 192.168.1.3: [Errno 2] Host name lookup failure
==

This might be related to the issue at hand. I looked at the same file in my F13 install and there is no such error message. 192.168.1.3 is the IP address of the PC (the next available from the DNS server which happens to be my DSL router at home).

Created attachment 450842 [details]
anaconda.log

see comment #4

Created attachment 450844 [details]
anaconda.program.log

see comment #4

> This might be related to the issue at hand. I looked at the same file in my F13
> install and there is no such error message. 192.168.1.3 is the IP address of
> the PC (the next available from the DNS server which happens to be my DSL
> router at home).

Oops, I meant _DHCP_ server, obviously.

This is on Live CDs only, I sent a patch with fix to anaconda-devel-list.

I was seeing this too (hostname entered during install from Live media was ignored) and I'm glad to see both a bug report and a fix already available.

Fixed in master (anaconda-15.1-1). For F14, the bug would need to be approved as F14 Blocker.

I don't think this is a show stopper as it is easily corrected, however it might be worthwhile to mention it in the F14 release notes as a known issue, just so that people don't lose time on it. 

Alternatively it could be worthwhile to post a note about it on one of the mailing lists (devel or test) to see if sysadmins would consider this an important bug, because I think they would be most affected by it (I am not a sysadmin so I cannot judge that).

"For F14, the bug would need to be approved as F14 Blocker."

No, it doesn't, you can put the fix in 14.18 or 14.19 if you think it's a good thing to have in F14, we are not yet at the point where we only accept blocker fixes.

Please backport the fix if at all possible because if the live media installer can't set a hostname it will reflect very poorly on Fedora and make it appear that it can't do even a simple, basic function properly.

(In reply to comment #12)
> "For F14, the bug would need to be approved as F14 Blocker."
> 
> No, it doesn't, you can put the fix in 14.18 or 14.19 if you think it's a good
> thing to have in F14, we are not yet at the point where we only accept blocker
> fixes.

Ok, I probably confused it with internal anaconda policy. Anyway I'll ask David Lehman the F14 anaconda gatekeeper if we can get it into the release.

radek: sure, I know anaconda team has its own policies, let me know if you have one which would block taking this fix. we can propose the bug as a nice-to-have if necessary.

Proposing as F14 Blocker with hope for Nice To Have.

The patch in master:

http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=5161a324ad2cf2be636a6cd330390e7f05971

Proposing as nice-to-have.

+1 from me.

Discussed at 2010-10-08 blocker/NTH review meeting, accepted as NTH. Please take the fix into the F14 anaconda branch.

I am also experiencing this bug, it's good to know a fix is in the works!

Is there any way to fix the problem on an already installed system? I tried using the hostname command to change the computer name, but on reboot this still reverted back to localhost.

Best wishes
Nathan

system-config-network , DNS tab.

(In reply to comment #21)
> system-config-network , DNS tab.

Besides the above I would suggest taking a look at /etc/hosts, due to a bug in NetworkManager (I am not sure if it has been fixed yet).

This should be fixed in anaconda 14.19-1.

(In reply to comment #23)
> This should be fixed in anaconda 14.19-1.

Good that it was fixed. As the saying goes, one has only one chance to make a good first impression, and if something goes funny in anaconda that's not nice for first time users, even if it is just a minority that chooses a host name.

And thanks to Adam for taking the issue to the bug review meeting and taking care of it.

anaconda-14.19-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/anaconda-14.19-1.fc14

anaconda-14.19-1.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update anaconda'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/anaconda-14.19-1.fc14

I can confirm this is fixed in the F14 Final TC1.1 x86_64 KDE LiveCD. uname -n returns the hostname I set manually within anaconda.

anaconda-14.20-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/anaconda-14.20-1.fc14

anaconda-14.20-1.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update anaconda'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/anaconda-14.20-1.fc14

The fix is confirmed, setting VERIFIED, can be closed when anaconda goes stable.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

anaconda-14.21-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/anaconda-14.21-1.fc14

anaconda-14.21-1.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update anaconda'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/anaconda-14.21-1.fc14

anaconda-14.21-1.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

Just rebuilt my Fedora 14 (devel) remix with all of the updates and noticed that the bug is fixed... and works for me.  Also noticed a number other other bug fixes (default background in KDE is no longer solid black).  Good job.

Thanks for fixing this bug in time for release!