My Home assistant installation was working fine until Friday, I gut an OS upgrade notification fro 9.6 (I think) to 10 and now I get this eror and it wont start
What should I do?
Thks
Jorge
I am having the exact same issue with my HA VMWare VM since I updated to OS 10.1. It is causing all kinds of issues. Hoping to find a fix so that I don’t have to rebuild and restore from backup.
This message is usually associated with networking being inoperable. Check LAN cable, or something which could affect communication of HA to the rest of the network. For example DHCP or a static IP conflict or netmask or router not accessible, etc.
I originally thought this may be the case after doing a lot of google diving, but I checked the IP and no conflicts. I also checked that I could reach the router, also able to do that. I saw there was an issue in 10.0 that was fixed for proxmox in OS 10.1, but it appears to still possibly be an issue for some other hypervisors. I’ve tried the troubleshooting tips for proxmox, but those did not work for my HASSOS on VMWare ESX.
Try to use another hypervisor using same HA installation steps to see if you can get it working. If it does not work on another hypervisor problem is most likely network related.
Also you can try to install Debian and using paravirtualisation just follow the below guide to use KVM.
Alternatively use Proxmox inside a VM in ESX.
Not necroing here, but other still may run into this. My issue and fix was the DNS address in HAOS network settings. Point it to a valid DNS Server, and all is great now! I just used 1.1.1.1 (Cloudflair) I’m going to test with 127.0.0.1 as I am running AdGuard addon.
1 Like
That worked a treat. Boots about 5x faster too!!!
Can you explain in more detail what you did here?
The solution involves:
instead of Network > Adapter 1 > Bridged Adapter, choose:
Adapter 1 > NAT &
Adapter 2 > Host-only Network
3 Likes
The OP is/was showing issues with the Guest Agent. I had this issue in the beginning (Note: for me, this issue did not stop the boot process for HAOS and things worked fine).
Here are some notes I made when I worked on this issue (some time ago), that will hopefully help.
QEMU Guest Agent -
Runs inside the guest and allows the host machine
to issue commands to the guest operating system using libvirt.
It supports many functions for example, getting details
about guest file systems, freezing and thawing file systems,
or suspending or rebooting a guest.
The Guest Agent on the HAOS VM wants to talk to the Host over a “Channel” which is an internal socket using virtio. There has to be IP networking connectivity between the Host and the VM. I use a kernel bridge on the Host and have the VM’s network interface connect to the kernel bridge. he kernel bridge in turn is connected to the Host’s physical networking interface (Ethernet). The Host also uses this kernel bridge as its networking “Interface” (i.e. the Host uses this kernel bridge to get its Home LAN IP address) and not its physical Ethernet.
For the Guest, add the “Channel” using virt-manager:
Add Hardware->Channel
Name: org.qemu-guest_agent.0
Device Type: Unix socket
You should now see in virt-manager a channel named “channel qemu-ga”.
Then restart the VM.
To test this out, in virt-manager, do a “Shutdown” on the VM, and on the console window for the HAOS VM, you should see HAOS going through a shutdown process.
I should also add that my Host is Ubuntu.
Hello,
I resently started to face the same issue as the OP having the same messages appear during the startup process. For me this does not halt the startup, it fails and continues until it boots but apparently something is wrong and i would like to fix it. Here are a few more details:
Operating System: Windows 11
Home Assistant installation method: OVA (VirtualBox)
Supervisor version: 2024.04.0
HA Core Version: 2024.4.2
Operating System: 12.1
I am having AdGuard addon so my DNS settings in HA points to the HA IP address but i have also tried the 127.0.0.1 as suggested in post 6 without positive results.
I also tried the suggestion of the post 9 above setting 2 adapters in Virtual Box one with NAT and the second with Host-only Network also with not possitive results.
Please for your support.
If you are talking about the lines concerning the QEMU Guest Agent, my understanding is that Windows-Host/VirtualBox do not use QEMU for emulation, so I kinda doubt they support a QEMU Guest Agent.
Hi, thanks for your comment. Yes that’s what what i was talking about.
Something must have changed then because i use Home Assistant on Windows Virtual Box since 2021 and i never had this issue before.
Edit: I changed the DNS settings from 192.168.100.62 (which is my HA local IP) to my router’s IP and now it works without this error. I was using the HA IP because i have the AdGuard Addon
I’m a bit curious … I don’t think the QEMU Guest Agent relies on DNS, however there is another error in the log, the error “Wait Until Kernel Time Synchronized” probably does rely on DNS as I would think HA kernel uses NTP with an timed server over the internet. So once you changed the DNS setting, that would have fixed the Time Synchronized error, but don’t you still get the QEMU Guest Agent dependency warning?
No i dont get any error any more. The process goes very fast all succesful and it boots in a few seconds. Before it was taking about half a minute before time syncronization and it was written that it failed. But it was booting even with that
I fixed this by activating the first 2 network adapters with NAT configuration, the second was host only
1 Like
I run into the same issue.
Adding the NAT configurations on Port1 did not solved the qemu time server error but made it possible to start the server again.
In addition I run into the condition hat the supervisor is still starting up when the banner already is shown. This confuses some user, so I want to explain this habit:
From other topics I saw the “solution” type in banner in the HA console.
I want to answer this. It is not a sloution. Banner just refreshes the console and rebuild the “picture of home assistant” called banner. This means it pretends to be a solution when the server needs more time to start up than the console can show the banner. When in the meantime the supervisor started the core and essential parts of the system are up and you type in banner it looks like banner fixed something. (on the other hand this explains why banner often did not fix anything…)
A more qualified method to test the server is running with minimal conditions is when the login screen appears on the browser or app.
I hope this makes it clearer.