I installed, did an update, selected the HiFiBerry Pro board and was working my way down the settings list.
I changed the hostname (RoonPlayLiving) and upon reboot, the boot list displays, the diskcheck completes and a couple more lines display (too quickly to read) and then the screen blanks.
The system is NOT visible via lanscan, but the lights are on.
Any suggestions?
You are going to have to pull the card, plug it into a Linux machine…then manually change 2 files with correct hostname…then use dietpi-config to change the hostname where it changes those files itself (on a running machine). Due to the mismatch in what dietpi.txt says and what is written in those files causes it to lock…only way to edit them is have a Linux machine that can mount then edit as root the files you need to file
I believe the files are /etc/hostname and /etc/hosts
However the dev’s of the script can tell you exactly which files need to be updated
Thanks. That seems like a major bug…
gbb
Just so be sure:
The script behind this is quite trivial: https://github.com/Fourdee/DietPi/blob/dev/dietpi/func/change_hostname
Indeed the new hostname is added to /etc/hostname and /etc/hosts to the default internal host IP 127.0.1.1.
This is a quite trivial and should not break any reboot.
Did you change other settings. Especially if you choose (on RPi) screen resolution “headless” or set “CONFIG_HDMI_OUTPUT=0” to dietpi.txt, then on boot the screen will blank. This is for SSH-only setups. But this should not effect network connectivity.
Your router/DHCP server cannot see the device at all? After changing hostname, of course potentially assigned IPs can be lost and you might need to re-add the device respectively re-assign an IP to it. It depends a bid I think, sometimes the hostname is just handled visually and if it’s about IP reservation etc. just the MAC counts.
I did try editing the hosts files, as in the earlier suggestion. I removed the line form each, but no change.
I ended up reinstalling from the .img and running through the setup again.
Removing the lines will definitely cause problem. You always need to have a /etc/hostname assigned and a related entry within /etc/hosts. This IP there can be changed, if the client has a fixed IP, but leaving as 127.0.1.1 is an always working default.
On first boot, if for some reasons you want to revert, the entries are:
/etc/hostname => DietPi
/etc/hosts =>
127.0.0.1 localhost
127.0.1.1 DietPi
The hostname itself can be changed without major effect, but the lines always need to be present.
Just not sure if SSH keys need or should be recreated when changing the hostname? However I never faced an issue, besides PuTTY asked me to again trust the host. I guess regeneration is done automatically, if after reboot (SSH service start) hostname and keys do not match. And anyway this should never break network connectivity.
OK, I left localhost in.
I’ll have to redo more as I cannot update my existing Roon endpoints (dietpi tells me they are too old). Hmm.
Cheers
Interestingly, I just hit this exact same problem again on a new install on Rpi 3B+ and DietPi_v6.17_RPi-ARMv6-Stretch.
Here are the /etc/hostname file:
127.0.0.1 localhost
127.0.1.1 RPiDAC
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
and hosts:
RPiDAC
The name is changed as I wanted, but the boot starts, then I get a ‘No Signal’ message on the screen and the light stays on but no network activity.
Seems like a hard bug!
I think you have to change it in two places or it causes issues
Core networking
Update /etc/hostname
Update /etc/hosts, so local address(es) resolves with the new system name.
Reload the network configuration. You have two options:
Reload configuration files
<!> This will temporarily disconnect your system from the network (ssh usually resists short disconnection)
<!> This might definitively disconnect your system from the network because networking might not restore connections; please reboot, which is not lazy, but ensures that your setup is really correct
invoke-rc.d hostname.sh start
invoke-rc.d networking force-reload
invoke-rc.d network-manager force-reload
ToDo: is it useful to reload network-manager?
or the lazy way: Restart the system.
Well, I believe that I’ve found the problem. Somehow the deitpi-config script is ALSO setting the display to headless under some circumstances.
I did not explicitly change that. However my way of working IS to step through each of the options in the menu, slecting and changing those I need to change as appropriate.
I’ve now experienced this problem twice, months apart, and the only consistent thing is my methodology in seting up a new installation.
Thanks to WarHawk for the comment. I now have a [nother] working Roon endpoint to sub for my blownup Freya preamp (don’t ask 
((( ).
As a PS, I would sya that the networking setup in this release is a significant step backwards. It used to be simple to set up wireless and rto determine what was going on. This display is frankly awful and doen’t detect SSIDs a all. The only way I got wireless to work at all was to edit the files before booting.
I’ve been setting up a headless pi4 for datalogging with a piplate this evening.
First attempt, I edited dietpi.txt to do a bunch of stuff and it failed to boot. One of those things was changing the hostname. I just burned a fresh image and started again, but without a lot of the stuff in dietpi.txt.
I had a lot of fun getting piplates to play. it needs python2 to run…
polishing things up after doing that, I get to changing the hostname, this time in dietpi-config.
I can no longer find it with nmap or log in to the ip it usually has.
I pull the card and put it in my laptop. etc/hosts and etc/hostname have both been changed to my new hostname. dietpi.txt has not. i change hosts and hostname back to DietPi.
Still no login
I’m not looking forward to redoing the piplates installation.
I did all this on a pi zero a few days ago only to discover it wasn’t fast enough. The hostname change i put in dietpi.txt worked just fine, though. Something is different with the arm64 version?
Any tips on tracking this down? I have ramlog…
Hi,
the hostname change done on dietpi.txt is applicable on first initial boot only. The value is marked with AUTO_SETUP
#------------------------------------------------------------------------------------------------------
##### DietPi-Automation settings, applied on first boot of DietPi only, ONCE! #####
#------------------------------------------------------------------------------------------------------
# Hostname
AUTO_SETUP_NET_HOSTNAME=DietPi
Means it is fully correct that this was not changed while using dietpi-config
It might be best to connect a screen if your system did not boot after you have done some changes. This way we could see what happen. I doubt changing the hostname will breake your system.
I’ve tried it two ways now. Both ways broke the system
1st was changing dietpi.txt before first boot. I also changed a bunch of other stuff so it could have been something else that broke that one. Though it was stuff that worked fine on a pi zero…
2nd attempt I left dietpi.txt mostly alone and used the dietpi-config utility after setting up everything else. That left DietPi as the hostname in dietpi.txt and changed it in etc/hosts and etc/hostname. I tried changing it back, but still no ssh on boot 
the green led flickers for a while when starting up, then goes off, leaving the red one on. What else does it change other than etc/hosts and etc/hostname?
I don’t have a way to hook up a screen to a pi4
I need this running for Monday, so looks like I need to do another clean install.
Part of getting the piplate to install was purging python3. Related?
Curiouser and curiouser, said Alice.
I think I changed ramlog to ramlog + 1 hour save while setting up, so thought it would be worth plugging it in and leaving it. Damn thing came up this time, with no changes since last attempt! Seems a good time to take an image of the card before trying anything else…
Without screen it will be quite hard to find out what the issue of the system is.
Are you sure python 2 is needed? Because on the PiPlate docs they describe the installation for python 3 as follow
For Python3, type: sudo pip3 install pi-plates and hit
The logging software throws a bunch of syntax errors when tried with python3. I’m no python coder, so don’t want to try fixing them all.
well you should report it to PiPlate developer if there are error using Python3. This way they probably have the chance to fix it.
And furthermore purging Python 3 should not be required to run Python 2. Both can coexist and be used beside each other without issues. And Python 3 is not required for any core features or system startup, so removing it is not the reason for your boot issues. For those to investigate we need some logs. If you have a chance to access the ext4 partition from another system, have a look at /var/tmp/dietpi/logs/ for first boot setup logs.