HassOS Won't Function without DHCP (not even attached ZWave)

[neil1111]

Describe the issue you are experiencing

EDIT: This issue was originally opened as "HassOS Hanging on Boot then no DHCP". However, based on the additional comment here, below, I've renamed it as the issue is "Bigger".

Original entry continues... When booting in RPI 4b 4GB, it hangs as described here:

Wasn’t able to reboot from the app or ssh to reboot, so I did a hard reset. Now during the boot process I’m stuck on a seemingly infinite wait for a start job to finish.

A start job is running for Wait Until Kernel Time Synchronized (1h 58min 55s / no limit)

Eventually did the solution described here: https://community.home-assistant.io/t/hassos-hanging-on-boot-stuck-at-wait-until-kernel-time-synchronized/207921/16? to get DHCP assigned. Also needed to SAVE and then ACTIVATE.

What operating system image do you use?

rpi4-64 (Raspberry Pi 4/400 64-bit OS)

What version of Home Assistant Operating System is installed?

8.1

Did you upgrade the Operating System.

No

Steps to reproduce the issue

1. Cold Start RPi (I haven't tested it via simple restart, but happy to test this if it would be helpful)
2. Monitor the launch with a connected screen & keyboard

...

Anything in the Supervisor logs that might be useful for us?

Not sure, but happy to provide. There are no Errors, but there are several warnings that state: 
22-05-29 07:58:50 WARNING (MainThread) [supervisor.api.ingress] No valid ingress session

Anything in the Host logs that might be useful for us?

[    5.093133] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.bin failed with error -2

System Health information

No response

Additional information

After the initial restart (but before adding the commands in the comments), using FING app does not find any DHCP IP address assigned to the RPi. The IP address only appeared after running the CLI commands described in the linked Forum article.

[neil1111]

I'm running on an SSD.

[zamog]

Some here - to reproduce it make sure the DHCP server is offline (and then cold start the PI)

[agners]

So it seems that the network configuration got changed to disabled in all cases? The Supervisor handles the network configuration, so this is likely caused by the Supervisor.

[neil1111]

Some here - to reproduce it make sure the DHCP server is offline (and then cold start the PI)

In my case, each time it occurred following a cold start (power cycle).

So it seems that the network configuration got changed to disabled in all cases? The Supervisor handles the network configuration, so this is likely caused by the Supervisor. This highlights a good point. It is possible (and I will test), that one of the instances when this didn't work I had power cycled the power strip into which both the router (to which the RPi is connected and provides DHCP) and the RPi are plugged. That could mean that DHCP wasn't running when the HA looked for the Network, and then ran out of time (I think it was a 90 second count-down).

Perhaps the solution is, in the absence of an IP (DHCP, a disconnection, or otherwise) for Supervisor to try again every (say) 10 seconds.

[neil1111]

Hi everyone. I (unfortunately) encountered another use case for this problem. I encountered hardware problems with my router, and as a result had no ability for the RPi to get an IP address. Therefore, I couldn't even use the terminal to "force" it to look for it again. HA simply would not run.

While in that situation, naturally there would be no Alexa, Google Home, or Nabu Casa connectivity, I VERY MUCH could have used ZWave to be up & running with the related Node-Red functionality running under HA. Many of my lights only use logical switches (not connected as a "load"), so it is important for HA to run without DHCP, much less external IP access.

[agners]

Just to be clear on how the system should behave in absence of network (e.g. DHCP server not reachable):

• The network will continue to try to wait for network to become online and try to synchronize network time up to 90s
• If that fails, the system will continue to boot regularly.

Any other behavior is unexpected and needs investigation.

A start job is running for Wait Until Kernel Time Synchronized (1h 58min 55s / no limit)

It definitely should not wait for that long. HAOS in my virtual test environment has a ~90s timeout on that (xx / 1min 29s). Once that counted down it continues booting.

On the Raspberry Pi 4 installation the same service also has a timeout of 90s configured (from the OS shell):

# systemctl show systemd-time-wait-sync.service | grep Timeout
TimeoutStartUSec=1min 30s

What some might be seeing is a related issue where Supervisor causes network to remain disabled after a DHCP outage (see https://github.com/home-assistant/supervisor/issues/3674).

[neil1111]

Hi Stefan,

Thank you for the clear summary of expected behavior. I can confirm that following the ~90 second timeout in the absence of DHCP, the system continues to hang, and I needed to use the HA commands referenced in the "workaround" linked in my OP. I hope that clarifies.

On Wed, Jun 8, 2022 at 9:32 AM Stefan Agner @.***> wrote:

Just to be clear on how the system should behave in absence of network (e.g. DHCP server not reachable):

• The network will continue to try to wait for network to become online and try to synchronize network time up to 90s
• If that fails, the system will continue to boot regularly.

Any other behavior is unexpected and needs investigation.

A start job is running for Wait Until Kernel Time Synchronized (1h 58min 55s / no limit)

It definitely should not wait for that long. HAOS in my virtual test environment has a ~90s timeout on that (xx / 1min 29s). Once that counted down it continues booting.

On the Raspberry Pi 4 installation the same service also has a timeout of 90s configured (from the OS shell):

systemctl show systemd-time-wait-sync.service | grep Timeout

TimeoutStartUSec=1min 30s

What some might be seeing is a related issue where Supervisor causes network to remain disabled after a DHCP outage (see home-assistant/supervisor#3674 https://github.com/home-assistant/supervisor/issues/3674).

— Reply to this email directly, view it on GitHub https://github.com/home-assistant/operating-system/issues/1949#issuecomment-1149921752, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG4HWXZA342KWSYF2YEGDU3VOCOH7ANCNFSM5XIFXV6Q . You are receiving this because you authored the thread.Message ID: @.***>

[Sesshoumaru-sama]

I had the same issue today. After reboot of my HA instance it did not get an IP address anymore. Turned out that the entire ehternet connection had been dropped. As I run HA on Promox I was able to get to the CLI and add a new connection.

nmcli con edit activate

Please investiagate. Got me a scare!

[github-actions[bot]]

There hasn't been any activity on this issue recently. To keep our backlog manageable we have to clean old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant OS version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[stuaxo]

Reproduced this, waited for 17m and turned off, will try re flashing this is just so I can evaluate the OS

[c11umw]

I had the same issue today. After reboot of my HA instance it did not get an IP address anymore. Turned out that the entire ethernet connection had been dropped. As I run HA on Promox I was able to get to the CLI and add a new connection.

nmcli con edit activate

Please investiagate. Got me a scare!

Interesting that it still affected you even using Proxmox. I've not seen the issue in a while - probably 'cos I now run multiple PiHoles across my network and they're all DHCP enabled (split the shared IPs between them to prevent conflicts). My primary PiHole is in a Proxmox LXC next to HomeAssistant, so even if the local switch is offline then hopefully the Proxmox PiHole should still be able to manage the DHCP request.

[lakaassekoo]

Yes, same problem today with fresh install virtual box with "haos_ova-11.4.vdi"

[TommiG1]

I had the same problem today after making several attempts to migrate a HomeAssistant vm to Unraid. At some point I ran into the error that DHCP was no longer possible and the host didn't get an IP. The reason was that there were several identical host names (homeassistant) with different MAC addresses on the DHCP (Fritz! Box). With the 6th doublet, the DHCP service on the router stopped. The solution was to delete all hostname duplicates and generate a new MAC address for the vm.

[Sim1Chin]

Experienced this same issue with HA running on VirtualBox VM on a NUC. I've configured my mesh (TPLink Deco) to reboot nightly and would notice that my HA instance becomes inaccessible over the network in the morning. Satic IPs are also configured for the NUC and HA in the mesh config. I've attempted to configure an automation that would trigger once my mesh has rebooted that would reboot the HA host. But this still doesn't allow HA to come back online and I can only access HA locally on the NUC the VM is running on. I have to resort to shutting down the VM running HA and starting it back up to be able to access across the network. As this can become tedious every day, I've now resorted to disabling the scheduled reboots on my mesh to maintain connectivity to HA.

[Billybangleballs]

I would like to be able to install home-assistant, but because my network does not use dhcp (intentionally), and there is no facility for manually assigning a network configuration, it seems impossible to do.

[Impact123]

Give this a read: https://github.com/home-assistant/operating-system/blob/dev/Documentation/network.md

[Billybangleballs]

Give this a read: https://github.com/home-assistant/operating-system/blob/dev/Documentation/network.md

That did the trick, it ought to be in the installation instructions so people can find it ;)