Is it possible to do the update mentioned in the HassOS 3 announcement or do you have to download a new vmdk file, convert to qcow2, and restore the config?
Are you running the stable version currently (2.12)? You should see the “update” button available in the host system card at some point on the Hassio > System page.
Or you can use the custom command within one of the ssh addons or the terminal in VSC:
hassio hassos update --version=3.7
Make sure you have a snapshot made and downloaded just in case.
Yes the update button is available. I guess my question is it safe to update or has someone tried it without bricking their system? I have Unraid 6.8 and stable 2.12 HassOs.
I’ve updated mine that way (both HassOS and Unraid) through several versions without issue. I am currently on latest of both.
I’m running Hass.io on unraid VM for over a year now.
Only thing that I tried to get working a lot and still does not work is the Bluetooth Dongle.
I now bought 2 Esp32.
Anyone else try and have no issues? Im scared.
I would try turning IPv6 off for troubleshooting purposes.
My server hard a hard crash the other day for seemingly no reason as well. Since then, my HassOS vmdk will not boot either, it just crashes. I created a second VM with a fresh download straight from the site and same thing.
2020-01-08 03:43:10.065+0000: Domain id=9 is tainted: high-privileges 2020-01-08 03:43:10.065+0000: Domain id=9 is tainted: host-cpu char device redirected to /dev/pts/1 (label charserial0) qemu: qemu_thread_create: Resource temporarily unavailable 2020-01-08 03:43:17.190+0000: shutting down, reason=crashed`
I doubt they are related in cause, but I haven’t had had much time to look into your problem yet
New error message this time on the original VM and its gotten worse. I’m afraid she’s destroyed now…
> 2020-01-08 04:30:37.784+0000: Domain id=1 is tainted: high-privileges > 2020-01-08 04:30:37.784+0000: Domain id=1 is tainted: host-cpu > char device redirected to /dev/pts/0 (label charserial0) > 2020-01-08T04:38:03.252924Z qemu-system-x86_64: terminating on signal 15 from pid 6968 (/usr/sbin/libvirtd) > 2020-01-08 04:38:03.453+0000: shutting down, reason=destroyed
Hi guys, I’m using hassos (3.7) and I notice that it takes quite awhile to restart HA and top reveals very high load averages >5. I’m running it as a VM under unRAID (KVM) (2cpus/2gb ram). As per the OP specifications. Thoughts here?
I think many people here are in a similar situation. And no visible solution to date.
Oh really, didn’t notice that. Are others suffering from poor performance as well? I somewhat improved the situation by doubling ram and cores (4gb/4cores).
Any thoughts on how to use the Fresco Logic FL1100 USB3.0 controller via passthrough in unRAID with HassOS? I passed through the device but I don’t believe HassOS has support for it?
I disagree. I don’t see many people here in the same situation.
I am now on 3.8 and everything is the same speed as usual.
But still there are people experiencing extremely long restart times.
Yeah I agree, the system takes an enormously long amount of time to restart HA, event after allocating more resources…Normal operation, the system barely breaks a sweat - just restarts.
Anyone here have issues with Lifx and Unraid 6.8X? On 6.7 bulb control and discovery worked fine, something has changed in 6.8 and this no longer works. For a long time I just stayed on 6.7 figuring it would work out in one of the point releases.
Could be networking related, I think Lifx is using UDP.
For some reason UDP discovery doesn’t seem to work on Unraid 6.8. I have to create a broadcast address for each Lifx bulb manually in the configuration. Luckily I already had static IP’s for everything Lifx.
I can manually downgrade to 6.7 all day and have this work but something related to UDP discovery is definitely different. I figure I can ask over on the Unraid forums and perhaps someone over there knows the answer.
I just moved my Home Assistant (hass.io) from Synology to unraid using a snapshot and I have some issue with some add-on (deconz) and principally with hassio_supervisor who crash few minutes after start with error 137.
Did anyone had same issue and knows to solve it?
Has anyone had any issues with Home Assistant doing a ton of writing? I’ve averaging 15-40MBps of writes to my cache drive that I have the VM installed on. When I stop Home Assistant and turn the VM off, that drops to a few KBps. Also, the drive has seen 119TB of writes to it since I installed it in October and the vast majority of that has been Home Assistant related.
I’m concerned I’m going to wear out my cache drive as it does so much writing. I’ve gone down the whole route of limiting what the Recorder actually writes, but it doesn’t seem to help much. I’m running a decent amount of add-ons, like Node-Red and VSCode, but nothing that I can specifically find is writing a ton of data…
Have some of you migrated to an external DB or put the VM on a ramdisk?
Will there ever be a solution for the long restarts? Feels like it’s around 30 min now.