NetworkManager will change my system's hostname whenever I use it to successfully connect to a wireless network. It does not change it when I use NetworkManager to connect to a wired network. This change of hostname breaks X. e.g. Battle for Wesnoth v1.2.4 Started on Wed May 2 22:24:04 2007 started game: 1338004991 Xlib: connection to ":0.0" refused by server Xlib: No protocol specified error display: Could not initialize SDL: No available video device Could not initialize video. Exiting. until such time as I manually change my hostname back to what it originally was. When I do that, the wireless connection continues to function properly. The wired and wireless connections both use dhcp. Reproducible: Always Steps to Reproduce: 0.Open a terminal (so it's still open after the X breakage) 1.Select a wireless network via NetworkManager. 2.Wait for connection to complete. 3.Open a new tab in the terminal to verify the name change. Actual Results: My hostname changed from what I had set, eddard, to something along the lines of dhcp392. Expected Results: Brought up the wireless network while keeping my hostname intact.
Created attachment 118007 [details] make.conf
Created attachment 118008 [details] worldfile
Created attachment 118009 [details] package.keywords
Created attachment 118011 [details] emerge --info
From the 0.6.5 ebuild... elog "Problems with your hostname getting changed?" elog "" elog "Add the following to /etc/dhcp/dhclient.conf" elog 'send host-name "YOURHOSTNAME";' elog 'supersede host-name "YOURHOSTNAME";'
I have a connected Problem: I don't use dhcp for my wired interface (eth0) but a static ip when I'm in the office, so dhclient never gets called and the setting in dhclient.conf is not used. The Gentoo backend of NetworkManager from the networkmanager-updatedbackend patch thus makes a reverse dns lookup and sets the hostname to whatever it gets. At home when I use my wlan interface with dhclient everything works as expected. IMHO networkmanager should not try to set the hostname. It breaks X and Gnome sessions for users mobile laptop users.
Patches accepted... proper static IP support is planned for 0.7
*** Bug 184905 has been marked as a duplicate of this bug. ***
Created attachment 124584 [details, diff] This patch fixes the problem for me Copied from duplicate bug #184905 (sorry, and I did search for it ... 8^): It's just that in NetworkManagerGentoo.c, the variable sys_data->config is initialized after being used, or not initialized at all, so reading the hostname from the config file and putting it into the config hash table fails. This patch seems to fix it, i.e., the hostname in /etc/conf.d/hostname is loaded and used properly.
(In reply to comment #9) > This patch seems to fix it, i.e., the hostname in /etc/conf.d/hostname is > loaded and used properly. Ok, sorry, it doesn't really fix it ... it fixes a null pointer bug though, but the hostname is still set to something else when the device is activated. I'll use the dhclient.conf workaround in the meantime.
(In reply to comment #10) > (In reply to comment #9) > > This patch seems to fix it, i.e., the hostname in /etc/conf.d/hostname is > > loaded and used properly. > Ok, sorry, it doesn't really fix it ... it fixes a null pointer bug though, but > the hostname is still set to something else when the device is activated. > I'll use the dhclient.conf workaround in the meantime. > it still changes hostname for me (0.6.5_p20070823). it's unpleasant because this hostname change feature (a bug for me though) is enabled by gentoo patch (networkmanager-updatedbackend.patch). I will drop the patch for the time being hope 0.7 will work it out. BTW, I never understand dhclient.conf enough to play with hostname tricks, "dhcpcd -h" is easy.
can someone reopen this bug? leaving it "resolved" leaves it out of the default search. or, we should submit another bug report?
The instructions for dhclient.conf are in the output of emerging NetworkManager - there is an elog entry for how to do it. If you can't follow those, I really can't help you
(In reply to comment #13) > The instructions for dhclient.conf are in the output of emerging NetworkManager > - there is an elog entry for how to do it. If you can't follow those, I really > can't help you > I would request that this bug is reopened. The default is not sensible for users with Wifi and the workaround is only that since it involves duplicating the hostname unless the dhclient config file is updated on startup when the hostname init script is run. I use NetworkManager so that I may connect to various wireless networks, on a laptop, as a normal user and not have to do some funky stuff with sudo. Altering the hostname is not sensible as a default, although it would be appropriate as an option.
(In reply to comment #14) > > I would request that this bug is reopened. The default is not sensible for > users with Wifi and the workaround is only that since it involves duplicating > the hostname unless the dhclient config file is updated on startup when the > hostname init script is run. > I agree. I had originally set my laptop's hostname in both /etc/conf.d/hostname and /etc/dhcp/dhclient.conf. Later I had the bright idea of changing the hostname, and set the hostname file appropriately, and was dumbfounded when the machine still stubbornly used the old hostname. I had totally forgotten about the dhclient.conf file. It took me several days to figure out what was wrong... There should be an option to sync the /etc/dhcp/dhclient.conf file with /etc/conf.d/hostname, when the latter is changed.
This does not work for GSM (Mobile Broadband) networks. I have set * /etc/hosts * /etc/dhcp/dhclient.conf * /etc/dhcpcd.conf and it is chaing my hostname and my dnsdomainname to localhost.localdomain using 0.7.1-r6
(In reply to comment #14) > The default is not sensible for > users with Wifi and the workaround is only that since it involves duplicating > the hostname unless the dhclient config file is updated on startup when the > hostname init script is run. > > I use NetworkManager so that I may connect to various wireless networks, on a > laptop, as a normal user and not have to do some funky stuff with sudo. > Altering the hostname is not sensible as a default, although it would be > appropriate as an option. > I agree. The default should be a behavior that won't break X.
I have 0.7.1-r6, and the issue is slightly different: hostname gets changed as soon as /etc/init.d/NetworkManager starts, as in gdm greeter I already see hostname being "localhost.localdomain", while it should be what I set in /etc/conf.d/hostname
(In reply to comment #18) > I have 0.7.1-r6, and the issue is slightly different: > > hostname gets changed as soon as /etc/init.d/NetworkManager starts, as in gdm > greeter I already see hostname being "localhost.localdomain", while it should > be what I set in /etc/conf.d/hostname > Same behaviour here. katu ~ # cat /etc/dhcp/dhclient.conf send host-name "katu"; supersede host-name "katu"; katu ~ # cat /etc/hosts 127.0.0.1 katu.imag.fr localhost.localdomain localhost 127.0.1.1 katu katu ~ # cat /etc/conf.d/hostname # /etc/conf.d/hostname # Set to the hostname of this machine HOSTNAME="katu" However, when I starts the machine
> However, when I starts the machine I get localhost.localdomain
The same here. I'm using networkmanager 0.7.2 for broadband connection, and even though I got: cat /etc/NetworkManager/nm-system-settings.conf [main] plugins=keyfile [keyfile] hostname = o0o0o ...after successfull broadband connection I get: public-gprs107914 ~ # This results in broken X sesssion!
A hackish fix for this has been committed to tree with 0.7.999 (p.masked)
*** Bug 214634 has been marked as a duplicate of this bug. ***
0.8 has been released with the patch, and is in ~arch. Closing FIXED.
*** Bug 259634 has been marked as a duplicate of this bug. ***
Created attachment 260873 [details, diff] fixed read-hostname-patch for net-misc/networkmanager-0.8-r1 This is a fixed patch for current stable net-misc/networkmanager-0.8-r1 It uses the correct variable "HOSTNAME" instead of "hostname" read from /etc/conf.d/hostname Moreover it fixes build errors when compiling without TARGET_GENTOO caused by misplaced #ifdef's.
(In reply to comment #26) forgot to mention: I additionally added a file-monitor for /etc/conf.d/hostname, so changes to it get honored immediately
