Supervised, current config - restarted and eth0 was disabled?

Configuration
1

I’m running an HAOS HA instance that is current 2025.6.1 supervisor 2025.05.05, os 15.2. It runs in a HyperV and has been that way for years. I recently (4 days ago) upgraded to 2025.6.1 from something with 2025.5 without incident and all is well.

I shut it down (from the develop menu) all the way in preparation to do windows updates on the Hypervisor, which i did, and rebooted it, and all looked good. I have another linux VM running (ubuntu) that started fine.

HA showed started by no connection. Nothing worked. The console was accessible from the Hypervisor, and I finally figured out that the ethernet interrface (eth0) was in a disabled state.

The actual virtual network interface was fine, it’s the same shared switch the other VM uses. Rebooting did no good. There’s no “–enable” argument in the update command. I finally figured out if I forced an IP on it (it has always been set to a static IP) that it would come up, and it did, and is back. I rebooted to make sure it would come back yet another time. It did.

I have no idea why this went to a disabled state. The physical NIC is fine (it is real ethernet, not wifi), the virtual shared instance appears fine since the other VM had no issues.

Once it went disabled, rebooting the VM did not help. Only manually adding an IP worked.

Does anyone have insight into what happened? Is there any thing I should do, or have set up differently, to handle this?

Could this be something flakey in the newer versions? This config has literally run for years with regular monthly updates, with never an issue.

Even if there was a network error, shouldn’t the eth0 stay enabled so a subsequent reboot would find it? Is it supposed to go disabled and never come back?

Is there anything in logs that will still be present that I can provide (recognizing two separate reboots have occurred since).

Again – I’m up now, but I would really like to understand why I was down.

Linwood

2

On a distantly related note if any of the developers are listening – it would sure be nice if HA commands had a “more” feature. I could only see about 25 lines, always the last lines, so showing things like “supervisor logs” and “core logs” was not all that helpful, it shows only the end, not the beginning where it probably went wrong. And an ssh login was obviously not possible.

3

Sometimes the hypervisor and the VM mess up the initialization of the NIC and the VM OS then marks the NIC as faulty and disables it.
Restarting the VM is not enough, because the hypervisor still have a messed up NIC, so that needs to be restarted too.

Regarding the logs, then in the HA CLI you can type login to get a standard Linux CLI.
In the GUI you have several options in the upper right corner, like see full logs and download logs.

4

I don’t follow that. The hypervisor didn’t have a messed up NIC, as it was a shared NIC and both the hypervisor and the other linux VM were working just fine.

Any initialization failure of the VM’s virtual NIC should have reset when the VM was restarted.

It seems to me that some error caused the VM (i.e. HAOS) to mark the NIC disabled and then did not try it again on subsequent reboots. Which seems wrong.

Well, with no network there’s no gui.

And apparently I’m an idiot. Well, sort of. The “login” info is on the HA help screen but it’s at the top, and instantly scrolls off as soon as you type anything. It’s not in the list of available commands, so I never noticed it. I must have typed Help 50 times trying to find a command to get me to a shell prompt.

If you happen to be a developer, please consider it a suggestion to add “login” to that list of available HA commands!

I think I’ll set up a forced failure and try this again; I can snapshot the working config so it’s easier to recover. But I THINK that a single failure is getting eth0 marked “disabled” and you apparently can only unmark it by setting something (there apparently being no “–enabled” option, which is odd as “-e” is shown as equivalent to “–disabled”; I wonder if there is some munging of that help screen?

5

I am just an user of HA, so you will have to make a feature request, but be sure to read the announcement on the forum here, since the feature request category is being removed and a GiyHub solution is taking its place.

6

Thanks. I just updated my post also. The “login” is there, but not in the list of available commands, it appears on the first line of the output and quickly scrolls off the screen if you are on a non-scroll-back monitor as HyperV has.

7

I found the logs, but the flavor of linux used and the sheer volume of logging has lost me. I see repeated lines like:

2025-06-19 04:33:38.353 ha kernel: docker0: port 1(vethe638795) entered disabled state
2025-06-19 04:33:38.353 ha kernel: veth188eed5: renamed from eth0
2025-06-19 04:33:38.368 ha NetworkManager[406]: <info>  [1750307618.3680] manager: (veth188eed5): new Veth device (/org/freedesktop/NetworkManager/Devices/18)
2025-06-19 04:33:38.384 ha kernel: docker0: port 1(vethe638795) entered disabled state

But some of those I think are just various docker images recognizing the underlying nic is down. I’m struggling to find where (on multiple reboots) it decides to disable the “main” interface (sorry, probably not the right name, but with virtual interfaces all the way down…).

I still think something happened to mark it disabled and subsequent restarts of the HyperV VM Guest (i.e. HAOS) did not clear it even though the HyperV virtual switch was fine.

8

HA rotate the log file at bootup, so the logs you see in the GUI will only be for the current session.
The old log file will be rename homeassistant.log.1 and it is found in the config folder.
This means you will only have the current and the previous session available in log files, unless you set something up to make backup of them.

9

I think the log most interesting is the “host” log which is available through multiple boots in the gui. That’s the one I was seeing lots of “eth0” activity. I just can’t figure it out.

The example above was from one of the failed boots.