Opening as an initscripts bug but I the problem may be elsewhere. Please reassign as you see fit. I suspect that this may be related to the fact that NetworkManager is now managing the network interfaces and not /etc/init.d/network. In earlier versions of Fedora and in RHEL, when I get an address on a machine with dhcp, the initscripts set the hostname on the machine to the unqualified result of a reverse lookup of that address. I recently did a rawhide install and now this no longer works. The hostname remains stuck at either "localhost.localdomain" or "(none)" if I comment out the HOSTNAME variable in /etc/sysconfig/network. The host has: initscripts-9.30-1.fc16.x86_64 NetworkManager-0.8.999-1.fc16.x86_64 systemd-26-1.fc15.x86_64
http://blogs.gnome.org/dcbw/2010/12/16/good-touch-bad-touch-etchosts/ *may* be relevant here.
Can you provide some logs from /var/log/messages showing the issue? That would help figure out what's going on.
Created attachment 500894 [details] tail end of /var/log/messages Here's the tail end of /var/log/messages. This is with NetworkManager enabled and "network" disabled (both via chkconfig). Earlier today, I disabled NetworkManager and enabled "network" and the hostname got set correctly on reboot. So this might not be a regression as much as a piece of unimplemented functionality in NM.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
So it looks like in your configuration, the DHCP server isn't actually sending a hostname back to the client. I'll assume then that the hostname is supposed to be created from the reverse-lookup of the client's IP address, which used to have a bug. We've fixed that in F17+. Please test and see if it now works, if not, re-open the bug and we can try to explicitly request a hostname from the DHCP server.
I believe it does work now (and has for some time).