Changing Hostname Not Working


#1

UPDATE: I have been able to test this rather extensively and have been able to replicate this problem many times and can workaround for now.

Hello,

We have 10 GoBox kits; our team is pretty sophisticated when it comes to manipulating command line and networking. Yet, we have had incredible trouble getting the hostnames set up correctly. There was a handwritten note in our shipping package that said that all of the SD cards were renamed and numbered. However, none of them have the hostname properly set up. When you boot with a monitor and keyboard/mouse attached, the hostname.sh script on boot fails.

For good measure, I’ve taken a box home (just in case the network at our site is an issue, which it shouldn’t be) AND even downloaded the fresh 2016-0105 image and did a fresh install. I changed the hostnames file in /boot and still the hostname is failing. We’re missing something small. here, I think, but as of this moment we are dead in the water and unable to continue our class.

I’m willing to switch to static IP addresses but it seems like the hostname issue will continue to plague the correct functioning of things even if static IPs allows us to use vnc properly.

Thanks for any thoughts. I’m happy to do some rapid testing of different ideas.

Best,

Christopher K. Sokolov


#2

Not an expert, just another user but this video helped me a lot https://www.youtube.com/watch?v=Nf78QMxuZkg


#3

Thanks Jeff; definitely followed that video as part of my research before writing here. Glad it worked for you!


#4

I’ve done a ton of more testing on this, on multiple SD cards (both pre-installed by Dexter and installed from image download). The bottom line, I think, is that /boot/hostnames must be set to the same value that is present in /etc/hostname and /etc/hosts. However, if you change /boot/hostnames (even at the factory, as ours were) then /etc/hostname will be EMPTY and /etc/hosts will be empty as well – even without the default information that is almost always present in /etc/hosts. This behavior can be easily replicated by changing /boot/hostnames and rebooting; /etc/hostname will become blank and /etc/hosts will get the hostname erased.

For /etc/hosts, I think the following values need to be present, right?

127.0.0.1     localhost
::1           ip6-localhost ip6-loopback
fe00::0       ip6-localnet
ff00::0       ip6-mcastprefix
ff02::1       ip6-allnodes
ff02::2       ip6-allrouters

127.0.1.1 dex62

Where “dex62” is the hostname you’d like.

So, at this point, I have a workaround, but it is very laborious. Is there a way to fix the script/mechanism that is reading /boot/hostnames in future images?

Finally, the documentation here (http://www.dexterindustries.com/howto/change-the-hostname-of-your-pi/) needs to be adjusted:

5. Change the /boot/hostnames file

Now we will check for one more file. If it is present, we need to edit it as well. Run the following command:

It shouldn’t say “If it is present” – rather, it must be present.

I hope this is helpful to Dexter and others,

Christopher.


#5

Hey Chris,

A couple of moving parts here, so I’ll try to write a thorough response all around.

First, I wrote those SD Cards myself by hand. I’m deeply sorry if they gave you trouble, and I truly appreciate you giving a thorough update to what’s going on with your reboot and rename. I hopefully can shed a little light into what’s going on.

First, I agree, I think there may be a problem with our boot script for changing hostnames. I’m not sure why some are having trouble with it, and some are not. I think you commented on another forum thread where they had successfully changed the hostname; I’m not sure exactly what’s different for you than for them. I will investigate, and I’ll get the script working. I think I have an idea of what’s going on, and I’ll make the update that gets pushed with our software updates.

Next, often the step that gets missed with the hostname change from SD card is rebooting. In short, you first change the name is /boot/hostnames then you reboot. After the first reboot, it will come back to life as the original hostname. Rebooting once more will bring the hostname on as the new hostname. It’s important to note: you have to reboot the Pi. Are you sure this step was done?


#6

And as for the documentation readjustment: I don’t think it needs to be updated. That line is true. If you have the file /boot/hostnames, you do need to change the name in there.

A little context: older versions (pre 2015.11) do not have that file present, and you can’t change the hostname except manually. So if you were using the older version, you would need to check for the file, not see it, fine, don’t change it. Does this reasoning make sense?


#7
This behavior can be easily replicated by changing /boot/hostnames and rebooting; /etc/hostname will become blank and /etc/hosts will get the hostname erased.

I was not able to replicate this behavior. Not to say that it’s not happening, but that something else must be happening as well. I just tested it on a fresh sd card, just to check; both the hosts and hostname changed automatically, no problems.


#8

Sorry to keep pounding you Chris, one more question though! I ran dmesg to try to see how things were going with the rc.sh script called at boot; I couldn’t see any errors on boot. Again, this is with a fresh image. Can you paste or type the error message you’re getting on bootup? It would greatly help me figure out what’s going on.


#9

John,

Thanks for looking into this. First, in answer to one of your questions, yes, I did note and comply with the double (and sometimes even more often) reboot to see if that made a a difference (this is just to force calling /etc/init.d/hostname.sh right?). I will have the opportunity, tomorrow, to try this about 8 more times or so – I will be able to get more data for you in that process in terms of error messages or patterns.

One question: is it worthwhile at this stage to reimage those SD cards with the 2016-0105 image you have posted on Sourceforge and essentially “start over” with the hostname challenge issue? That’s my inclination but time is always valuable, too. :slight_smile:

Christopher.


#10

Hi Chris, I have been using 6 GPGs to teach 16 kids. I changed the hostname on SD cards made from the 2016-0105 image.
I just changed the hostname in the “hostnames” file in a text editor on PC. Insert the SD card to a RPi, power on, then reboot.
After rebooting, the new hostname is there. You can verify it by opening a terminal or remotely connect the RPi with the new hostname through a browser.
Hope it helps.


#11

I have had this problem in the past, but have never been able to replicate it. However, once a card is “hit”, then it replicates it all the time. The hostname ends up being “none”. It’s that first trigger that I can’t figure out.

Last time it happened to me I was able to save my SD card by getting a sledgehammer out (figuratively speaking).
I changed the hostname in
/boot/hostnames
/etc/hostname
/etc/host
and through raspi-config
reboot
then try again (with the same hostname, of course) and reboot again.
Eventually it stuck (probably by the third reboot) and the card has been behaving since.


#12

Just a small update on this:
1). Nicole found that using any non-alphanumeric characters (such as “_” or “-” will create a void hostname (the dreaded “pi@”).
2). I just pushed out a new rc.sh, which should work much better in renaming the hostname from the /boot/hostnames file. Did this based on Nicole’s research, so thanks Nicole!
3). We’re working on a slightly more elaborate script right now to check for non-alphanumerics in the script and reject them. Just to make the software more robust. Stay tuned for that.

John