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. 
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 
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.
hm…
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)