Hostname change on interface causes raspberry os lite to fail on boot

[GloriousGloria23]

Describe the bug Installed omv on Raspberry os lite. After setup, I changed the hostname in the UI. System went into reboot but got stuck and did not finish. ssh failed to connect. Even after directly connecting monitor, system was not responsive and screen turned black after initial boot sequence. Mounted the drive on another linux machine, manually reverting the hostname in the /etc/hostname file solved the issue and system rebooted normally.

To Reproduce

Steps to reproduce the behavior:

1. Go to omv -> Network -> General -> Hostname
2. Change Hostname
3. click Save
4. automated reboot failed

Expected behavior

successful reboot with new hostname

openmediavault Server (please complete the following information):

• OS version: Linux 6.6.20+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.6.20-1+rpt1 (2024-03-07) aarch64 GNU/Linux
• openmediavault version: 7.0.5-1

Client (please complete the following information):

• Device: PC
• OS: Win 11
• Browser firefox
• Version 124

[votdev]

OMV is more or less exactly doing the same like raspi-config.

• https://github.com/RPi-Distro/raspi-config/blob/351366eaf28416fce1253a7a2569457e3d7570a4/raspi-config#L855
• https://github.com/openmediavault/openmediavault/blob/0a326a200927cce1c333ee561537882bee86fc0b/deb/openmediavault/srv/salt/omv/deploy/hostname/default.sls#L25
• https://github.com/openmediavault/openmediavault/blob/0a326a200927cce1c333ee561537882bee86fc0b/deb/openmediavault/srv/salt/omv/deploy/hosts/10default.sls#L34

If the problem is only on Raspi hardware, then it will be hard for me to reproduce and fix it without having such hardware. In that case the community must provide a fix.

[votdev]

Can not reproduce this issue. So it seems to me that this problem is specific to your system or Raspi OS based systems in special.

[votdev]

Where exactly does the system hang? What service is not starting or reports an error?

[GloriousGloria23]

I wish I knew, the problem is that as soon as it happened I completely lost access to the device. Ping would not respond (and therefore I couldn't SSH into the machine), and hooking it up to a monitor ended up with a blank screen (I tried two different monitor). I tried taking a video to see where it would hang but it went so fast it came out blurry.

Is there a way to find out where it hangs by reading a log file? I can try to reproduce it again on a new SD card sometimes next week (I dare not do it again on my running NAS :D )

[votdev]

You can use journalctl -b to get the last boot log or use journalctl --since today for the whole day.

[jochman]

I'm joining here. Same on RPI5 with PI OS Lite and OMV6.

[flmaxey]

Are you building your devices in accordance with -> this process?

In the essentials, after installing an R-PI Lite image with SSH enabled, the build is as follows:

sudo apt-get update

sudo apt-get upgrade -y

wget -O - https://github.com/OpenMediaVault-Plugin-Developers/installScript/raw/master/preinstall | sudo bash

sudo reboot

wget -O - https://github.com/OpenMediaVault-Plugin-Developers/installScript/raw/master/install | sudo bash

[rvegele]

Seems like I just ran into the same issue.

Pi4, RPI lite (headless), with SSH.

Can't connect (boot up?) after performing hostname change / save.

[ryecoaaron]

if you are using dhcp, it might have changed ip address. Sometimes, you have to plugin a monitor in to see what is going on.

[rvegele]

Right, I see no pi in my router device list.

Here's where it stopped:

And afterwards:

Not sure why address is 172... was 192.168... beforehand. So it's not communicating with the router somewhere any more as far as I can tell.

[ryecoaaron]

172. is the docker address not the system's address. The login message isn't always up to date because dhcp can take too long sometimes. Login and type: ip a

[rvegele]

hm... I'm connected through cable to my router :/

[ryecoaaron]

end0 is the network interface and it does not have an address. I would run omv-firstaid

[rvegele]

running 1 - network config in ovm-firstaid produces

[votdev]

You need to run it as root user.

# sudo omv-firstaid

[rvegele]

You need to run it as root user.

# sudo omv-firstaid

This seems to have fixed it. Not sure for how long 😅 Also not sure why the network got 'bumped' requiring me to do this.

[ryecoaaron]

It shouldn't break again unless you change the hostname again. Some routers do dumb things when a mac address gets a new name.

[rvegele]

interestingly enough this has also knocked down my docker setup with jellyfin :(

[ryecoaaron]

You should post on the forum for help. Many more people see posts there and I don't use jellyfin.

[rvegele]

You should post on the forum for help. Many more people see posts there and I don't use jellyfin.

thank you for your help

[roblatour]

I recently had a similar problem, when I change the host name on the Pi running OMV I could no longer access it using ssh from my windows machine. To correct, I issued the following command from the windows cmd window:

ssh-keygen -R x.x.x.x (where x.x.x.x was the ip address of the Pi running OMV)

after that I could ssh into it again. May be related (/may not be related)?

[ryecoaaron]

ssh-keygen -R just removes that ip from the known_hosts file on the client. This shouldn't prevent logging in via ssh.

[votdev]

ssh-keygen -R just removes that ip from the known_hosts file on the client. This shouldn't prevent logging in via ssh.

This is what ChatGPT says about this. It might be related to not logging into SSH IMO. But I didn’t have checked the SSH man pages about that, so ChatGPT might be wrong and hides his ignorance creatively :-)

But ssh-keygen -R x.x.x.x seems to remove the IP.

The SSH known_hosts file does not explicitly contain the hostname alone; rather, it contains a hash of the hostname (or IP address) and the corresponding public key of the remote host. The purpose of this file is to prevent man-in-the-middle attacks by ensuring that the server you are connecting to is indeed the one you have connected to previously.

Here's how it works:

1. Host Identification: The known_hosts file typically includes the hostname or IP address (hashed or unhashed) and the server's public key. When you connect to a remote server, SSH checks this file to verify the server's identity.

2. Hostname Change: If the hostname changes, SSH will not find a matching entry in the known_hosts file because the hash of the new hostname does not match any existing entries. This mismatch will prompt a warning, and SSH will ask you to confirm the new host's identity, potentially adding the new hostname and its public key to the known_hosts file if you accept it.

3. Server Key Change: If the hostname remains the same but the server's public key changes (for example, if the server is rebuilt or its SSH keys are regenerated), SSH will detect a mismatch between the known public key for that hostname and the new key. This also results in a warning, and SSH will prevent the connection until you resolve the discrepancy, typically by updating the known_hosts file.

In summary, the known_hosts file helps ensure that you are connecting to the same server you connected to previously by matching both the hostname and the server's public key. If either the hostname or the server's public key changes, SSH will raise a warning and may prevent the connection until the change is acknowledged and accepted by the user.

[roblatour]

@votdev yes, that is right. For more background, after changing the hostname on the Pi, when I tried to connect via ssh from my Windows machine I got the error message "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!" followed by further explanation.
I've since done a little more searching and found this article ... https://forums.raspberrypi.com/viewtopic.php?t=362325 which offers more detail as as well as the same ssh-keygen -R x.x.x.x solution. All to say, there may be a tie to changing the host name and other issues such as this one. As I said in my original post "May be related (/may not be related)?" Regardless, hope this is helpful.

[ryecoaaron]

All to say, there may be a tie to changing the host name and other issues such as this one.

If you change the name of your OMV system, it can't change the client though. So, you are forced to clean up the known_hosts file manually or with ssh-keygan.

[FPedrocas]

same thing just happened to me on a fresh install Using Raspberry Pi OS Lite (64 bit) on a Pi 4 model B

[joaquinmartis]

I faced the same error after changing the hostname on the omv workbench. The webpage turned black with a red sign telling me about an error in the system. Restarting the RPi showed that a service related to networking was failing to start, thats why the RPi was not accesible through SSH.

Using sudo omv-firstaid and using the first option i was able to reconnect the RPi to my home network and to get it to work.

As someone said it is probably a problem within the router and not OMV or the RPi

I wanted to add the prior to this problem I had(when I first installed OMV on my RPi), i could change the hostname flawlessly. But after changing it to "archivos-compartidos" i started getting 500 internal error when I tried to change any configuration. I copied one of those errors and it said that "archivos-compartidos" is not a valid hostname. If thats the case then it would be necessary to make a check in the hostname field(in the webpage) to prevent that kind of errors.

[votdev]

The hostname is validated:

• https://github.com/openmediavault/openmediavault/blob/cb5010451521237239b33986291d6fc03cfbf088/deb/openmediavault/workbench/src/app/shared/forms/custom-validators.ts#L53
• https://github.com/openmediavault/openmediavault/blob/cb5010451521237239b33986291d6fc03cfbf088/deb/openmediavault/workbench/src/app/pages/network/general/general-network-form-page.component.ts#L45
• https://github.com/openmediavault/openmediavault/blob/cb5010451521237239b33986291d6fc03cfbf088/deb/openmediavault/usr/share/php/openmediavault/json/schema.inc#L521
• https://github.com/openmediavault/openmediavault/blob/cb5010451521237239b33986291d6fc03cfbf088/deb/openmediavault/usr/share/openmediavault/datamodels/conf.system.network.dns.json#L12
• https://github.com/openmediavault/openmediavault/blob/cb5010451521237239b33986291d6fc03cfbf088/deb/openmediavault/usr/share/openmediavault/datamodels/rpc.network.json#L535

The hostname spec can be found here: https://en.wikipedia.org/wiki/Hostname

According to this specs the hostname archivos-compartidos is valid.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs for another 30 days.

[laleeroy]

Describe the bug Installed omv on Raspberry os lite. After setup, I changed the hostname in the UI. System went into reboot but got stuck and did not finish. ssh failed to connect. Even after directly connecting monitor, system was not responsive and screen turned black after initial boot sequence. Mounted the drive on another linux machine, manually reverting the hostname in the /etc/hostname file solved the issue and system rebooted normally.

To Reproduce

Steps to reproduce the behavior:

1. Go to omv -> Network -> General -> Hostname
2. Change Hostname
3. click Save
4. automated reboot failed

Expected behavior

successful reboot with new hostname

openmediavault Server (please complete the following information):

• OS version: Linux 6.6.20+rpt-rpi-v8 Prevent fatal error in autoloader #1 SMP PREEMPT Debian 1:6.6.20-1+rpt1 (2024-03-07) aarch64 GNU/Linux
• openmediavault version: 7.0.5-1

Client (please complete the following information):

• Device: PC
• OS: Win 11
• Browser firefox
• Version 124

Have the same error just now, I can't access it since I don't have mini hdmi cable 😞

[Johboh]

Got the same issue now on 7.4.11-1 (Debian 12). After changing hostname in the web UI (Network -> General), the machine was no longer accessible (not via web UI or SSH). After connecting a screen, I could see that the ethernet card was no longer setup for DCHP, and thus not receiving any IP address. After re-enabling this I was able to access the machine again, but on reboot, I would loose DHCP.

I have two Ethernet ports on my machine (but only one connected), and when I installed OMV initially, I could see both listed under OMV -> Network -> Interfaces. Now after hostname change, one was missing (the connected one). After re-adding it in OMV and enabling DHCP, it does work again even after reboot.

So I don't know what happen here, if changing hostname for some reason removed/cleared/reset the configured network interfaces.

[fredtep]

Same here. Just for the record here is a fix. On a raspberry pi you can just plug hdmi and running omv-firstaid will help you rebuild the network. On a rockpi it was a bit more tricky. Hdmi won't work so I had to use the console. For that you need a USB to TTL usb cable. This site will help : https://wiki.radxa.com/Rockpi4/dev/serial-console

[votdev]

INFO: Using the domain name local is denied because this is reserved for mDNS. Use internal instead.