EEPROM updated
Pi-hole disabled
All addons stopped
Zigbee dongle removed
HDMI connected during boot
Slot B still marked bad every time
Open one of the ssh add-ons, then
ha os update --version 17.2
Supervisor will try to update 3 times, then it will revert to the working version if it keeps failing FYI.
Also disabling PIhole can be really messy, make sure you haven’t lost DNS completely doing that.
Hi, I’m having a similar issue with my RPi 4 (installed on SD card rather than NVMe, but essentially the same problem, and it’s unclear if your suggestion resolved it for j2clegg).
I’ve repeatedly tried upgrading 17.1 to 17.2, both via UI and ha os update --version 17.2 but has failed at least 10 times, reverting to 17.1 after about 15 minutes of unavailability.
Is there some way to repair the bad boot slot, other than a complete re-image and restore from backup?
Not sure if it’s relevant, but a while ago I had a similar problem where HA frequently reverted from 17.1 to 16.3 after restarts; eventually after repeatedly trying to install it got from 16.3&17.1 slots to the current 17.1&17.2 slots.
I saw a recommendation for a different upgrade problem to try ha supervisor repair, but that this can only be done with a keyboard and monitor connected, which is quite a pain for me to do – but willing to do so if it’s likely to resolve.
(I’m aware that there are issues with SD lifetime when running HA from an SD card, but that is the best solution for me right now.)
Thanks for any advice.
> ha os info
board: rpi4-64
boot: A
boot_slots:
A:
state: booted
status: good
version: "17.1"
B:
state: inactive
status: bad
version: "17.2"
data_disk: LX32G-0x41115170
update_available: true
version: "17.1"
version_latest: "17.2"
I too got this problem on rip4b. I’ve read others reporting it. It seems to have started with the upgrade to 17.2 and originally reported by people using USB connected disks.
I only use SDcards and have made sure I have the latest available eeprom from raspberry before attempting the update, sadly still failed. Cannot get to HAOS only access i have is to root but don’t know if there’s any commands there I can enter to try and repair it.
Connected monitor and keyboard but it just goes as far as ‘Waiting for the Home Assistant cli to be ready’ and dong control-C i get to the # prompt. Typing ‘ha supervisor repair’ at this # prompt just gives …Error response from daemon…
The issue was closed as ‘solved’ citing eeprom update but clearly that is not the case.
1 Like
There has been some issue with Pi’s and old versions of the EEprom code in the Pi itself that may be affecting you.
Thanks for the advice, this now seems to be fixed. Here’s what I went through in case other people are still having problems.
I updated the EEPROM as suggested (I had a 2023 version rather than 2020 FWIW) – this was a pain as I had to buy an HDMI-Micro cable. I then rebooted and ran ha supervisor repair from the local shell.
I then tried ha os upgrade --version 17.2 but got Error: ‘OSManager.update’ blocked from execution, system is not running -startup. I rebooted and tried it again from both the local shell and the UI and got the same error.
I then tried fully powering down the HA box and restarted, then ran an upgrade from the UI. This time the upgrade succeeded and I verified that I have two good boot slots.
➜ ~ ha os info
board: rpi4-64
boot: B
boot_slots:
A:
state: inactive
status: good
version: "17.1"
B:
state: booted
status: good
version: "17.2"
data_disk: LX32G-0x41115170
update_available: false
version: "17.2"
version_latest: "17.2"
Sounds like I spoke to soon. After a reboot it’s reverted to 17.1, even though both slots are listed as good. What the heck?
➜ ~ ha os info
board: rpi4-64
boot: A
boot_slots:
A:
state: booted
status: good
version: "17.1"
B:
state: inactive
status: good
version: "17.2"
data_disk: LX32G-0x41115170
update_available: true
version: "17.1"
version_latest: "17.2"