Description of problem: With NetworkManager-0.9.4.0-7.git20120403.fc17.x86_64 : Nov 8 17:09:02 localhost NetworkManager[644]: <info> (p3p1): device state change: ip-config -> activated (reason 'none') [70 100 0] Nov 8 17:09:02 localhost NetworkManager[644]: <info> Policy set 'Boot Disk' (p3p1) as default for IPv4 routing and DNS. Nov 8 17:09:02 localhost NetworkManager[644]: <info> Setting system hostname to 'sedna' (from DHCPv4) Nov 8 17:09:02 localhost NetworkManager[644]: <info> Activation (p3p1) successful, device activated. Nov 8 17:09:02 localhost NetworkManager[644]: <info> Activation (p3p1) Stage 5 of 5 (IPv4 Commit) complete. so hostname is sedna After update with NetworkManager-0.9.6.4-1.fc17.x86_64 : Nov 9 10:41:31 localhost NetworkManager[645]: <info> (p3p1): device state change: ip-config -> activated (reason 'none') [70 100 0] Nov 9 10:41:31 localhost NetworkManager[645]: <info> Policy set 'Boot Disk' (p3p1) as default for IPv4 routing and DNS. Nov 9 10:41:31 localhost NetworkManager[645]: <info> Activation (p3p1) successful, device activated. Nov 9 10:41:31 localhost NetworkManager[645]: <info> Activation (p3p1) Stage 5 of 5 (IPv4 Commit) complete. and then hostname is localhost Version-Release number of selected component (if applicable): 0.9.6.4-1.fc17.x86_64 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
NM was always only ever supposed to set the hostname if you didn't already have a hostname set. However, at some point Fedora switched from storing the hostname in /etc/sysconfig/network to storing it in /etc/hostname instead, and NM hadn't been updated for this. Now it has been, and so the expected behavior is that if there is a hostname in /etc/hostname, then NM will not change it. Does that match what you're seeing? If so, this is NOTABUG.
[root@localhost (Fedora 17) ~]$ ls -l /etc/hostname ls: cannot access /etc/hostname: No such file or directory and HOSTNAME seems still to be in /etc/sysconfig/network
I have the same problem and have additional info. I've two PCs with Fedora 17 x86_64, one with NetworkManager 0.9.4.0-9.git20120521 (haven't updated) and one with NetworkManager 0.9.6.4-1. The newer one always fails to set the hostname retrieved by dhclient and reverts to localhost without domain name. I had enabled NetworkManager-wait-online.service, and there is no HOSTNAME entry in /etc/sysconfig/network, and no /etc/hostname file. The /etc/hosts only contains localhost related aliases, since all hostnames are resolved through DNS, which seems to work fine on both machines. The only problem is hostname is localhost with the newer NetworkManager. Of course this causes problems with autofs, sssd, openldap, etc. The old one works perfectly in all fronts.
It looks like hostname change slipped out from ACTIVATED policy change handler in this commit http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=500315329765831d242d51d6a46f1e05869c15d2
Created attachment 644903 [details] [PATCH] update hostname in ACTIVATED handler
Hm... why doesn't that code just use update_routing_and_dns() like everything else?
(In reply to comment #5) > Created attachment 644903 [details] > [PATCH] update hostname in ACTIVATED handler Diagnosis looks good but I think the update_system_hostname() call should be inside the nm_dns_manager_begin_updates()/nm_dns_manager_end_updates() block just above the routing update calls to ensure we batch up DNS changes. The hostname can affect the DNS configuration.
Created attachment 645519 [details] [PATCH] v2: update hostname in ACTIVATED handler
Created attachment 645529 [details] [PATCH] v3: update hostname in ACTIVATED handler (In reply to comment #6) > Hm... why doesn't that code just use update_routing_and_dns() like > everything else? I think the reason is that the code here adds new IP configs. But, I wonder if this patch could work. The difference against current code is that it calls update_ip4_dns()/update_ip6_dns() (via update_routing_and_dns()) even if no IP configs were added. Could that be a problem?
This is a serious difficulty for me since I have things running on my system that depend on knowing the hostname. Are these messages significant? They started showing up around the same time as the NetworkManager update and the hostname reverting to localhost. Nov 12 17:09:16 localhost NetworkManager[641]: <warn> error requesting auth for org.freedesktop.NetworkManager.settings.modify.own: (3) GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not get UID of name ':1.60': no such name Nov 12 17:09:16 localhost NetworkManager[641]: <warn> error requesting auth for org.freedesktop.NetworkManager.settings.modify.hostname: (3) GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not get UID of name ':1.60': no such name Nov 12 17:09:16 localhost NetworkManager[641]: <warn> error requesting auth for org.freedesktop.NetworkManager.enable-disable-network: (3) GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not get UID of name ':1.68': no such name Nov 12 17:09:16 localhost NetworkManager[641]: <warn> error requesting auth for org.freedesktop.NetworkManager.sleep-wake: (3) GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not get UID of name ':1.68': no such name Nov 12 17:09:16 localhost NetworkManager[641]: <warn> error requesting auth for org.freedesktop.NetworkManager.enable-disable-wifi: (3) GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not get UID of name ':1.68': no such name
Same problem here, even with version 0.9.6.4-2 which is in updates-testing repository. With new machines, sssd (with ldap config and SRV record use) cannot work because it cannot find the network domain name. Only "hostname -F" shows the "good" fqdn provided by the dhcp server. Other hostname options print only "localhost". This is a high problem in my company because the only workaround is to put a hostname manually in /etc/sysconfig/network
NetworkManager-0.9.6.4-3.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/NetworkManager-0.9.6.4-3.fc17
Works for me
NetworkManager-0.9.6.4-2.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/NetworkManager-0.9.6.4-2.fc16
(In reply to comment #13) > Works for me Great! Would you click the link and add a karma then? :)
(In reply to comment #10) > This is a serious difficulty for me since I have things running on my system > that depend on knowing the hostname. Are these messages significant? They > started showing up around the same time as the NetworkManager update and the > hostname reverting to localhost. > Guy, please try the update. As for the warning messages, they are unrelated. Probably, a short-lived process called a NM D-Bus call, but exited before NM had a chance to get its identity.
This did not fix the problem for me. I installed the new version and rebooted. [streeter@localhost ~]$ hostname localhost [streeter@localhost ~]$ rpm -qa NetworkManager\* NetworkManager-gtk-1:0.9.6.4-3.fc17.x86_64 NetworkManager-gnome-1:0.9.6.4-3.fc17.x86_64 NetworkManager-openconnect-0.9.4.0-7.git20120612.fc17.x86_64 NetworkManager-1:0.9.6.4-3.fc17.x86_64 NetworkManager-glib-1:0.9.6.4-3.fc17.x86_64 [streeter@localhost ~]$ cat /etc/hostname cat: /etc/hostname: No such file or directory [streeter@localhost ~]$ cat /etc/sysconfig/network NETWORKING=yes ##HOSTNAME=localhost.localdomain NTPSERVERARGS=iburst [streeter@localhost ~]$ ip a s 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000 link/ether 00:23:ae:ab:af:ce brd ff:ff:ff:ff:ff:ff inet 10.15.1.193/24 brd 10.15.1.255 scope global em1 inet6 fe80::223:aeff:feab:afce/64 scope link valid_lft forever preferred_lft forever 3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN link/ether 52:54:00:09:1c:cb brd ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc noop master virbr0 state DOWN qlen 500 link/ether 52:54:00:09:1c:cb brd ff:ff:ff:ff:ff:ff [streeter@localhost ~]$ host 10.15.1.193 193.1.15.10.in-addr.arpa domain name pointer baby.hsv.redhat.com.
Package NetworkManager-0.9.6.4-3.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing NetworkManager-0.9.6.4-3.fc17' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-18689/NetworkManager-0.9.6.4-3.fc17 then log in and leave karma (feedback).
(In reply to comment #17) > This did not fix the problem for me. I installed the new version and > rebooted. > Hmm, I re-tested again and it set hostname correctly for me. Guy, can you restart NetworkManager again, check whether hostanme is set with 'hostname' commnad and attach /var/log/messages (from the point where NetworkManager started)?
Problem is fixed for me with NetworkManager-0.9.6.4-3.fc17 Thanks
Jirka, Restarting NetworkManager sets the hostname. [root@localhost ~]# hostname localhost [root@localhost ~]# systemctl restart NetworkManager.service [root@localhost ~]# hostname baby.hsv.redhat.com But it doesn't get set on boot (it used to, before the NM update). I will attach the messages file including the bootup and the NM restart. thanks, --Guy
Created attachment 649275 [details] my /var/log/messages
(In reply to comment #3) > I have the same problem and have additional info. Confirming that NetworkManager-0.9.6.4-3.fc17 fixed for me.
NetworkManager-0.9.6.4-3.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
Do I need to open a separate BZ for my system that still won't set the hostname until I restart NM after bootup.?
Patch from comment #9 pushed to upstream master and nm-0-9-6 branch.
NetworkManager-0.9.7.0-8.git20121004.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/NetworkManager-0.9.7.0-8.git20121004.fc18
(In reply to comment #25) > Do I need to open a separate BZ for my system that still won't set the > hostname until I restart NM after bootup.? Well, it may be better to track it in a separate bug. Also, it would be good if you can enable debugging logs in NM, reboot and attach /var/log/messages to that bug report. To enable debugging, you can e.g. temporarily change ExecStart= in /usr/lib/systemd/system/NetworkManager.service to: ExecStart=/usr/sbin/NetworkManager --no-daemon --log-level=DEBUG and reboot.
NetworkManager-0.9.7.0-8.git20121004.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
NetworkManager-0.9.6.4-2.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.