My system is also doing this, and the two solutions suggested above will not work on a pi…, you cant login to a system to do a downgrade that reboots 30 seconds after it’s started
Why the hell was this update pushed out in the first place ???
Any other solution for RPI then start from scratch again?
Short answer, NO…, I flashed a new 12.4 image and restored from backup
I had this on my pi4 with SSD. I never saw HA come up at all, so I had to retrieve the pi from where it lives on top of a cupboard and plug a screen and keyboard in so I could see what it was doing. It was actually rebooting every 2-3 minutes. The CLI was coming up on the screen, so I had time to issue “ha os boot-slot other” command to force it to revert to the previous 12.4.
You can downgrade by selecting the other boot slot in the GRUB2 boot loader.
I’m having a similar sounding problem with every version above 11.1.
I can boot into recovery slot A which has 11.1 but not boot slot A or B which have 11.5.
This started with 11.2 and I’ve not been able to boot into anything but recovery slot A since then.
Did you ever get this fixed?
I’ve been having this since 11.2. It boots three times into slot A, then three times into slot B, before failing over to Recovery Slot A.
It only happened when I upgraded from 12.4 to 13.0 a couple of days ago, I never had any problem like this before that. I have not done anything since, it stays on 12.4, I’m waiting for 13.1 (or whatever) - 13.0 seems to have caused a weird variety of different problems for a minority of people, judging from issues on github etc.
It is supposed to swap slots after 3 failed boots, this wasn’t happening for me, I assume the system was coming up far enough to count as a successful boot before something caused it to reboot, so the 3-count was not kicking in. I don’t know what your problem is, it’s weird that it tries A 3 times, then B 3 times, then works on A.
EDIT - I don’t know anything about recovery slots separate to the A and B boot slots… “ha os info” just shows me this
board: rpi4-64
boot: A
boot_slots:
A:
state: booted
status: good
version: "12.4"
B:
state: inactive
status: good
version: "13.0"
data_disk: PNY-CS900-120GB-SSD-PNY2216220421010087C
update_available: true
version: "12.4"
version_latest: "13.0"
With me it started at 11.1, every version from there to the current version has failed.
My slot B says that it’s 11.5 but whenever I try to boot it fails and tries A, then B again, then it goes to the recovery which is back at 11.1.
There is no special “recovery slot”, there is just A and B. But if both don’t boot, it will just flip back and forth.
I am not aware of a known issue with Raspberry Pi 4 right now, and the changes queued up in 13.1 are unlikely to help here. Did the boot log show something? After an (failed) update attempt, when your system booted back in the other slot, you can get the logs using ha host logs --boot -1 --lines 10000.
@agners Thanks for the info. I am going to be out all day today but I will try and look at this tonight. EDIT - regarding slots, I only knew of A and B so I didn’t understand the reference to a recovery slot. I think they must be on other hardware…
I’m not sure if this is what everybody is thinking of, but mine has two slots that are marked “Rescue shell”.
I presume that they’re a “safe mode” of slot A or B, rather than separate slots entirely?
Well I have been busy past couple of days with having our grandsons to stay, any spare computer moment was spent in Minecraft 
…
I have tried upgrading to 13.1 this morning, still not working, it was getting as far as HA just starting to come up and then rebooting, over and over. Luckily terminal/ssh was also starting up, so I managed to get in to that and issue the boot-slot other without having to plug the pi in to a screen again.
Back on 12.4 again I have been looking at the “ha host logs” command mentioned above, can someone please explain what the boot id in the command is? I get this
ha host logs boots
boots:
"-1": cba967e42ec148f3bfbcc2019f2504a0
"-2": 99ab37cc7861492da105287cf289d3b4
"-3": 191eb985c4f948dbbcb5bd0042f82492
"-4": b1f1c688d113473db6f26822fb454126
"-5": eeb94567b5784fc58f2a6a3425fbdd46
"0": dd608421e0304d8e8cb9f226813f00f9
and when I try various ids in the command (-1, -2 etc.) I get various different logs starting with some quite old stuff (EG: from May or even February) followed by some data from different times this morning, but I cannot spot anything conclusive in any of them.
Well, on a hunch, I have been playing around turning off “start at boot” for some addons. I turned off esphome, plex server, wireguard, samba and chose to install 13.1 again. It booted ok. I started esphome and samba manually, all ok. I turned on start at boot for esphome and samba, and rebooted, again came up ok. I started wireguard manually, it started ok. I started plex manually, system immediately stopped responding and then rebooted. Came up OK as I hadn’t set those to start. I started plex manually first this time, started ok. Started wireguard manually, came up ok. Go figure…
I don’t use plex or wireguard at the moment, so leaving start at boot for those turned off seems to have alleviated the problem. Whether this is due to an actual problem in one of those, or it’s just some sort of resource issue during a full boot (maybe the order things happen has changed?) - I have no idea.
EDIT - ok, forget that, after 30-40 minutes running fine, it rebooted… back to 12.4 again.
I used the ha os update --version 12.4 command line suggestion.
Still no Home Assistant Web UI available for me. HA is running though because I can see my HA Cloudflared plugin IS serving certain web apps of mine via https which I’ve only configured through that plugin.
Hello,
I have a Pi 3B with an SSD.
My solution was to flash the 12.4 image and restore the backup.
I tried using a better power supply, increasing the swap memory, and updating all the add-ons before the update, but everything failed. If the RPi 4 has the same issue, it seems to be a software problem.
So, I decided to stay on 12.4 and wait for a future fix.
Just tried 14.0, same behaviour, still stuck on 12.4 with no hope of ever getting a fix
I’m getting the same behaviour OS version 13.1 when trying to update to version 14.
When running
ha os info
in the terminal plugin, it shows:
board: generic-x86-64
boot: A
boot_slots:
A:
state: booted
status: good
version: "13.1"
B:
state: inactive
status: good
version: "14.0"
So it looks like the update works but unfortunately installs on Boot Slot B.
On another thread some users have tried to update the grub config file but it reverst to Slot A after the reboot:
Same issue exactly with 12.4
Looks like no solution for now?
I saw this on the github issue for HAOS:
The approach according to Patrice3122 was:
1. Downgrade Slot B: On the localhost, I first downgraded Slot B to an earlier version using the command: ha os update --version 13.1.
NB: Any attempt to update directly to version 13.2 returned the message: Version already installed.
2. Manual Boot Selection: During the startup process, I manually selected Slot B from the boot menu. Note that the boot menu appears briefly during startup. To select Slot B, you must press the down arrow key, and once highlighted, press the Enter key to confirm.
3. Update Slot A: With the system booted from Slot B, I ran the CLI command: ha os update --version 14.0. Since the system was running on Slot B, the update process applied to Slot A.
4. Final Verification: After a host reboot, Home Assistant OS 14.0 was successfully running, booted from Slot A.
I’m going to try this method to see if it works.
Confirmed this method worked for me.
board: generic-x86-64
boot: A
boot_slots:
A:
state: booted
status: good
version: "14.0"
B:
state: inactive
status: good
version: "13.0"