Cool, then join the beta channel and report issues when you experience them.
The reason this issue affected so many people is that it wasn’t caught during beta, otherwise it would have been fixed before it was rolled out to the general public.
If you don’t want to do that, then either wait for .1 releases or read the forums to see if there are any issues before updating.
Same here! Thank you so much!
I have the greatest respect for the people behind HA, but I happen to agree with CHTHSCH. We should not to have to join the beta channel etc and they should not roll out an update without fixing this issue.
I’ve argued this before for core releases, but I’ll say it again: there’s not enough people in the beta channel to catch enough of the bugs. .0 releases should be released to the general public with a disclaimer and with a beta name, current beta should be renamed to alfa. Stable will be whatever is the last release of the month. Hot take maybe but I think it makes sense. Or call it a gamma if you want.
I’m on the beta channel but I don’t engage in all the OS beta tests since it is more involved than core beta testing. With core beta, some functionality might not work as expected, that’s the worst that ever happened to me, and reverting is fairly easy.
With OS beta, I once went through the experience of not being able to boot and not having a recent backup available because I stored them locally. Not funny. So I only do this when I am physically at home and my kids are at their mother’s for the week.
It’s better now with daily offsite backups but still a full restore from scratch is a nuisance.
I am sorry, but my capabilities are not sufficient to do so, otherwise I would.
@ [CHTHSCH I am not technical and this is quite easy:
install this addon
http://homeassistant.local:8123/hassio/addon/core_ssh/info
after install and start open
http://homeassistant.local:8123/hassio/ingress/core_ssh
then enter
ha os update --version 15.2
Thanks, done that already. Got my system back to work after the upgrade to 16. What annoyed me was, that HA OS 16 caused the same problem before, was pulled back. I expected the problem to be fixed when it was released again.
So idk if this is mostly people reporting issues with Zigbee here, but the upgrade actually killed my bluetooth.
I followed your recommendation to revert to 15.2 because it seems even if you backup when performing the OS upgrade it doesn’t allow you to restore to the previous OS?
However after reverting to 15.2 my bluetooth is still not working.
Update: after downgrading to 15.2 and then accidentally “downgrading” to 16 bluetooth is back, it seems the bluetooth address was reset to all 0s?
Strange
Thanks, I expected the same.
I have a HA Yellow, and I was having issues with Zigbee not working after installing OS 16. Thanks for posting the command to downgrade the OS
ha os update --version 15.2
This worked, and now I have Zigbee working again.
I also had do downgrade are there any news what is wrong?
The new version of the ha os is killing the ha hardware is sad.
I finally got around to digging into why ‘Advanced SSH & Web Terminal’ was crashing. I hadn’t edited the config and given it a username and password. Duh! It’s amazing home much you forget from one install to another if you’re not doing it all the time.
Thank you.
Switching to another slot was a key to recovery.
I just connected a screen to my mini PC and once system logo appeared hit ESC to enter boot menu, where another slot could be selected. System started in rescue mode and asked if I wanted to perform maintenance (Enter) or continue (CTRL+D). After selecting continue previous version (15.2) started successfully.
My HW: ASUS Chromebox 3 (Intel core i7 8th gen with SSD).
In a meantime I tried also both options with the slot containing 16.0 and system stopped to boot just after selecting rescue mode (never mind which path maintenance or continue), so CLI hasn’t even started.
Was also having same issue for 16 and 16.1, but changing to slot b on the boot screen has allowed the update to succeed. Thanks majstermod
16.1 bricked again my HA Yellow with CM5. Is there a recovery partition for that as well? How can I switch to irlt from the recovery console?
HA doesn’t boot, so i cannot get to HA console.
Hey, despite all of the discussion, I unfortunately still haven’t found a solution to the original issue that started this whole thread 
If anyone can help me I’d be very grateful. (In the meantime I’d caution any user of home assistant to NOT TRUST HOME ASSISTANT OS UPDATES, as they are clearly not adequately QAed before being released – as the number of replies to this thread and the lack of follow-up from developers clearly demonstrates )
Here’s where I stand:
System configuration:
Other computers available at my disposal for use in troubleshooting: multiple late model Macs and Raspberry Pis. (No windows computer or non-Raspberry/non-HA linux boxes.)
History/summary:
Here’s what I’ve tried in more detail:
Tried connecting to console, hoping to use the “ha os update” command others in this thread have had luck with. First tried doing this using a Mac (with Mac OS’s built-in screen command). The instructions linked by @agners above do not work. (See details.) Confirmed jumper is set to UART. Confirmed RPi is connected to the internet (via PoE ethernet). Was able to see that a USB device was connected to the Mac. Connecting to it with screen yielded a blank screen with a solid cursor. Then tried with a Raspberry Pi. Repeatedly. One time I was able to see some diagnostic messages that scrolled past too quickly for me to capture… then it froze and was unresponsive/blank. All other times I just saw blank screens. Right.
Tried making a clean install using a new NVMe and the Raspberry Pi imager. Installed in the the HA Yellow and went through the initial setup. Fine. Tried restoring from backup (auto backup pulled from the original MVNe)… and it would not accept the “Emergency Kit” key I had dutifully copied down a few months ago. Another Home Assistant fail.
Tried making a clean install again on the new NVMe and then manually copying select configuration files from the old MVNe to the new MVNe. Unfortunately these are EXT4fs with the “meta_bg” and “meta_csum” feature flags, so not only are they unreadable on a Mac (no EXT4fs support), but the one commercial package I’ve found for EXT4fs support on macs will not read them due to these feature flags. So I tried copying using a Raspberry Pi, but unfortunately every attempt fails. Basically there is one large (~20Gb) configuration file and the RPi ungracefully disconnects the target disk mid-write of this file(!). I’m using a brand new Samsung NVMe and have tried 2 different USB NVMe enclosures with no luck. This is bizarre!
Any advice would be much appreciated!
You can fix the lack of QA issue by signing up to the betas & reporting issues before they make it to the public release.
Dude! C’mon now. That is not a helpful response whatsoever. If @mike15 had been part of the Beta testing, his HA Yellow would have simply locked up weeks earlier. While having more users actively participating in Beta testing would be ideal, some things are going to still slip through and cause end-users issues. When that happens, as in this case, let’s focus on providing information that helps resolve the issue. Berating the end-user for not being part of the Beta testing is not helpful.
Hypothesis: By any chance, did you simply image the new NVME drive in a USB enclosure and have not yet installed it in the HA Yellow board? If so, the partitions on the new NVME drive may have not yet been expanded to filll the new drive. This usually happens during the first boot of HAOS. So, perhaps the target drive simply cannot yet hold a 20GB file? Just a hypothesis… 