Hm, yes this looks like you are running 6.0.rc1 indeed. Not sure why the front-end did not catch up yet. Maybe Supervisor → System → Reload Supervisor helps?
Would this be a good place to post a bug I noticed? To be fair, it’s not this release but maybe a few releases back but still not fixed in this rc.
I have a 5 years old Samsung smartTV. I was able to control it on/off via HA. But for now, these buttons do nothing:
For now, I can only see the status if the TV is on/off.
Just installed RC1 on my RPI 3, snapshot, migrated to my new Odroid C4 and have these logs:
WARN: buffer overrun event for slot 9 ep 8 on endpoint
But everything seems to be working fine, thanks. Just if I can get rid of this warning.
For info, also use usb ssd for data, maybe causing the warning??
Edit: this morning host was not reachable by ping…
This is most likely not related to Home Assistant OS but Home Assistant Core and its integration with Samsung TV.
I haven’t tested USB SSD on ODROID-C4 really. What would be interesting is if this also happens when using 5.13 and USB SSD (e.g. is this a new bug or is this a regression).
What could cause the problem is using a USB SSD which makes use of the new USB mass storage protocol called “UAS”. You can check if your drive is using UAS by executing lsmod, if you find uas in the list of modules your drive is most likely making use of UAS. You can disable UAS by editing config.txt (in the first partition of the boot SD/eMMC) and add usb-storage.quirks=0xXXXX:0xYYYY:u, where XXXX is the vendor ID of your USB SSD, and YYYY the product id. The command lsusb shows this information.
I checked with lsmod:
Module Size Used by Not tainted
xfrm_user 45056 1
xfrm_algo 16384 1 xfrm_user
cfg80211 364544 0
rfkill 32768 1 cfg80211
dw_hdmi_cec 16384 0
dw_hdmi_i2s_audio 16384 0
snd_usb_audio 245760 0
snd_hwdep 20480 1 snd_usb_audio
snd_usbmidi_lib 36864 1 snd_usb_audio
snd_rawmidi 40960 1 snd_usbmidi_lib
gspca_ov534 24576 0
cdc_acm 36864 4
gspca_main 32768 1 gspca_ov534
videobuf2_vmalloc 20480 1 gspca_main
videobuf2_memops 20480 1 videobuf2_vmalloc
videobuf2_v4l2 28672 1 gspca_main
videobuf2_common 53248 2 gspca_main,videobuf2_v4l2
dwmac_generic 16384 0
rc_odroid 16384 0
realtek 20480 1
meson_ir 16384 0
meson_dw_hdmi 24576 0
rc_core 36864 3 rc_odroid,meson_ir
meson_drm 61440 1 meson_dw_hdmi
rtc_meson_vrtc 16384 1
dwmac_meson8b 16384 0
dw_hdmi 40960 2 dw_hdmi_i2s_audio,meson_dw_hdmi
meson_canvas 16384 1 meson_drm
stmmac_platform 20480 2 dwmac_generic,dwmac_meson8b
cec 53248 2 dw_hdmi_cec,dw_hdmi
stmmac 192512 3 dwmac_generic,dwmac_meson8b,stmmac_platform
drm_kms_helper 196608 5 meson_dw_hdmi,meson_drm,dw_hdmi
mdio_xpcs 20480 1 stmmac
panfrost 65536 0
gpu_sched 32768 1 panfrost
crct10dif_ce 20480 1
fuse 126976 1
drm 483328 7 meson_dw_hdmi,meson_drm,dw_hdmi,drm_kms_helper,panfrost,gpu_sched
I don’t see UAS
I installed today to my Nuc (D34010WYK) with generic-x86-64 from the scratch.
In few hours HA is not accessible.
I connected hdmi and found, that wifi is lost.
message: iwlwifi no beacon heard and the time event is over already
My wifi module: Intel 7260HMW
aha, RC2 , that will fix my HA cloud issue, since now it waits untill it gets sycnhed with correct NTP!!
good job
1 Like
Yes, RC2 will explicitly wait until the RTC clock is considered synchronized by systemd-timesyncd. It might lead to a slight delay, but its preferred over surprises afterwards 
If synchronizing isn’t successful boot will continue after 90s, so that the instance will boot even in absence of Internet.
@AndreyShpilevoy so you did connect your host through WiFi? This seems to be a known problem in upstream Linux, see https://bugzilla.kernel.org/show_bug.cgi?id=203709.
Best would be if you can open an issue in the HAOS repo along with additional information (e.g. type of router, 5GHz/2.4GHz Wi-Fi etc.).
yeah, i had issues connection to nabucasa cloud, with invalid token
it always happened after a complete HassOS reboot … if i just restarted HA afterwards i had no issues
i fixed it by changing the NTP server in HassOS, they were default set to time.google
i changed them to 0.be.ntp.pool.org
no idea why the one from google wasnt working, but after the change, i didnt had the issue anymore
1 Like
Hm, I see, updating from 5.13 on Intel NUC tries to download the 6.0.rc1 image
. I uploaded a renamed version for the update file so that the Supervisor is able to download the update file. Can you try again?
When trying to update to rc2 from 5.13
21-05-21 12:39:15 INFO (MainThread) [supervisor.hassos] Fetch OTA update from https://github.com/home-assistant/operating-system/releases/download/6.0.rc2/haos_intel-nuc-6.0.rc2.raucb
21-05-21 12:39:15 ERROR (MainThread) [supervisor.hassos] Error raise form OTA Webserver: 404
Instead of working around by renaming the release this will be addressed in the next Supervisor version, PR is pending:
1 Like
You need to switch in Supervisor: join the beta channel.
I’m on the beta channel.
I had that issue sometimes too when I was trying development releases, a reboot of HassOs cleared that 404 issue
Not this time if you run the Intel NUC release.
Update went perfectly on virtualbox VM for both rc1 and rc2. Thanks for the great work and continued improvements!
Edit: rc3 also stable
updated to rc 3.0 , vmware system, all stable
good work guys
1 Like
This error should be gone with supervisor-2021.05.3. Can you try updating again?