System repair warning on HAOS

Im getting system repair warings and I have no clue on how to get rid of them.
I’m running HAOS on a RPi4:

  • Home Assistant 2023.3.3
  • Supervisor 2023.03.1
  • Frontend 20230309.0 - latest


If there are any relevant logs to provide, just let me know.

Are you really running HA OS?
I can’t imagine any reason that the HA OS itself would be reported as “not supported”… except, if you have updated the Core, but not the underlying OS for some time.

I think, it is more likely that you are running a Supervised installation on your own OS?

Thank you for your quick response @CChris .
I don’t want to seem ungrateful, but believe me: I use HAOS.
I set up my Raspberry Pi 4 with M.2 HDD via USB3 and an SD card with the HAOS image over a year ago. Before that, I used HASSOS since version 0.6x on a Pi2 and then a Pi3. So I’m quite sure that I didn’t accidentally install Raspbian and then set up the supervisor. :wink:

ok, sorry for my doubts - but usually “not supported os” isn’t something you would see on HA OS - in my opinion…

What I notice here:
Have a look at the information:

ha info
hasos: null
hostname: null
operating_system: null

ha os info
board: null
version: null

I’m not sure if that’s supposed on a RPI… running HA OS on a VM on my Server is providing the following information:


That is exactly the point:
The message should not appear at all on a Pi with a continuously updated HAOS.

I can of course do a new installation. The backups are safely on my NAS. I would also have a Proxmox cluster on which I could give HA a new home.

But I don’t want to make more work for myself than necessary and that’s why I actually wanted to stay with my setup.

I’ll restart the HA host. Let’s see if that does anything.

After rebooting the host, everything looks as it should:

It’s terrible when the German nerd saying applies: “reboot tut gut”.
The error is not reproducible for me and can occur again at any time.

tbh: this reboot could have also made things even worse… but then, at least the next steps would be clear…

But unfortunately, I don’t really have any idea what could have caused this :frowning:
In my opinion, I would keep this in mind and prepare a replacement of the M2 just in case that issues could be caused by slowly failing hardware…

Or - I would consider the already available proxmox as an possible replacement if further occurances are happening.
Maybe, starting to implement a second HA instance which could then act as a “failover” ?

I don’t know your setup - but I think, I would create a dedicated machine on proxmox for the HA Recorder.
Then - clone the current instance and install it also on proxmox.

IT SHOULD be able to use the already existing database, in case the RPI installation will fail.

I don’t want to flood the thread with my individual way out. Maybe there are more users who share the problem and can’t/won’t change platforms.

But thank you for your offer to help me change my setup as well.
I’ve been thinking about a failover setup for a while now.

First I started to put individual addons on their own legs. deCONZ is already running on separate hardware (Pi Zero W with Ethernet-ShThis text will be hiddenield) because I didn’t want to make basics like light on/off, motion sensor, thermostat control etc dependent on HA not rebooting again. I have at least 10 HA restarts per month. deCONZ simply runs through and has a calculated availability of 99.99%.
I also run Frigate under Proxmox in an LXC for Docker to have enough beef for image analysis.

Because you mention a second HA instance:
I have been toying with the idea of dividing HA integrations into vital and non-vital. MQTT, ESPHome, automations for the blinds, the alarm system and door locks are important basic functions. In contrast, the integrations for the PS4, current fuel prices, Spotify and Grafana are more of a minor, pleasant extra. Regarding my setup: I’m using a MariaDB plus InfluxDB for Grafana.

I have seen that two HA instances can be connected to each other. Would I be entering an administrative nightmare if I split one HA instance into two? My update strategy would then also be to only carry out the major updates on the essential HA instance.

I’ve played around a bit with the “remote HomeAssistant” … it was pretty nice, but in fact shortly after I had some issues with my disk space, so I removed my current “test installation”.

personally, I don’t think that splitting the setup into two HA instances is worth the effort…

I am aiming the same approach as you: moving all “addons” to their own LXC or VM … to keep them running independend from HomeAssistant.
HA itself is then only the system providing a nice UI and interface for automation…(if not done in the corresponding LXC, for example Homematic (IP) / CCU, etc.)

the issue I do see with the approach of splitted HA instances:
It would be required to have at least the installation with critical components setup in a way that would allow failover or “easy recovery”…
But then, it would not be a big deal to use the other components within this installation as well.

Another approach for HighAvailability / Failover would be some kind of “configuration management”.
You would need to have a clone of your running HA instance…
Your configuration and other sources should be stored on a centralized storage, so that both instances could always access “the latest” config file or use the latest version of custom components etc.

I don’t think that HA is currently really built for such an approach and I don’t really know how it will behave with the database if two instances are using the same DB… (and trying to update states)