I understand your point about auto updates not being recommended. But Home Assistant has garnered a large folllowing of people that want “just home automation” and that don’t see Home Assistant as a system they need to maintain.
The point about integrations being unavailable could be just as easily be diminished if Home Assistant supported a simple maintenance/auto-update period, like “tuesday at 4am” for basic/safe add-on and Home Assistant/Supervisor updates and reboots.
This would really alleviate most of the concerns and make sure that the less savy users keep up with the security and stability updates.
Some boards can’t directly boot u-boot from nvme. Odroid M1 instead use workaround - boot u-bot from SPI and after boot from nvme. It’s possible to store only loader and A/B but required external work and support. So not in priority. Just use SD and NVME as Data Drive
It would need at very least be organized around timezones. If it would be 4am local time, then an update would be spread out over 24h.
The post is about add-on updates in particular. Add-ons are maintained by various developers, so not every developer might prefer the same update time.
In the end, in a way, the users are still responsible for their instance. It is possible to update add-on using hassio.addon_update service call. So creating a blueprint which updates add-on on a particular day would be rather straight forward.
In fact, we have discussed to remove the auto update feature as it stands today and promote a solution using Core automation and service calls. But currently it isn’t as easy to automate such updates, so we kept the current feature set.
This reminds me: The current hassio.addon_update service call has essentially the same problem as the built-in auto update: How-to deal with add-on updates which have breaking changes There probably should be a flag weather to execute such an update or not.
The RK3568 ROM can’t but it can via SPL/U-Boot from SPI EEPROM yes. However, HAOS’ A/B fallback boot requires control over the boot process so we can’t reuse that boot flow
The documentation indeed was still missing, I’ve just merged the PR updating the docs. See breaking_versions configuration option in the Add-On Configuration section.
So how would one go about following the guidance of installing HA OS on an SD card and then connecting to a NVMe drive using the data disk feature? I bought the Argon ONE V3 M.2 NVME PCIE Case and didn’t have any problems getting HA OS installed on an SD card and restoring my instance from a backup, but I can’t get it to detect the attached NVMe drive. The instructions that came with the Argon case say to run some scripts that mess with the Pi 5 eeprom and config.txt (seems to be true for other NVMe “hats” as well), but that doesn’t seem possible on HA OS as it doesn’t have any of the necessary packages to run the scripts, let alone even download them, even when accessing HA OS over SSH.
As an aside, Assuming I figured out how to run the scripts for my Argon case or figured out how to manually make the same changes that the scripts are making, I’m concerned that a future HA OS update would overwrite those changes. Is that a valid concern?
I would appreciate some guidance here! For now I’ll just keep my Pi 4 HA host live…
Just off the top of my head, maybe you could use a fresh SD card with Raspberry Pi OS to do the eeprom and config.txt changes. Make note of the config.txt changes. Then boot from your HA SD card and reference this post for applying the same changes to the HA config.txt: How to access config.txt in Hassio? - #7 by flamingm0e
I am facing issues when creating big backups on my NAS. They are 3GB in size. the backups work when created on the local disk of my NUC, but when I point my backup device to the NAS, the backup fails.
�[31m24-03-16 09:33:53 ERROR (MainThread) [supervisor.backups.manager] Backup c73bb3da error
Traceback (most recent call last):
File "/usr/src/supervisor/supervisor/backups/manager.py", line 261, in _do_backup
async with backup:
File "/usr/src/supervisor/supervisor/backups/backup.py", line 363, in __aexit__
self._outer_secure_tarfile.__exit__(
File "/usr/local/lib/python3.12/site-packages/securetar/__init__.py", line 140, in __exit__
self._tar.close()
File "/usr/local/lib/python3.12/tarfile.py", line 1975, in close
self.fileobj.close()
OSError: [Errno 5] I/O error�[0m
I got this working now where HA OS is installed on the SD card and the NVMe drive is used as a data disk, per the official recommendation. Here’s what I did:
Flash Raspberry Pi OS Lite 64-bit to my SD card, configure it to enable SSH prior to flashing.
Install the SD card into the Raspberry Pil, which is installed in the Argon ONE V# NVME PCIE case along with a NVMe SSD.
Boot into Raspberry Pi OS and the SSH into it once it’s up
Run the relevant scripts for the Argon ONE V3 NVME PCIE (there are two of them listed in the instructions and they both require a reboot after executing).
SSH back into the pi and confirm that the NVMe drive is available by running lsblk
Take a look at /boot/firmware/config.txt, copy its contents somewhere for reference. The relevant entries were: dtparam=uart0=on dtparam=nvme dtparam=pciex1_gen=3 max_usb_current=1
Shutdown the pi, remove the SD card, flash with HA OS.
Insert the SD card with HA OS, boot the pi
Restore from HA OS backup (I’m migrating from an existing installation on a Pi 4, you could also just install from scratch)
SSH into HA OS (the actual OS, not where you get with the Terminal addon)
Edit to /mnt/boot/config.txt and add the 4 settings saved from earlier (step 6).
Reboot.
SSH into HA OS again, confirm NVMe drive is visible via lsblk
Login to home assistant via browser, then go to Settings > System > Storage and Click “MOVE DATA DISK”, select your NVMe drive, and continue through the wizard to migrate most of the install to the NVMe drive.
For reference, I’m using a Western Digital 500GB WD Blue SN580 NVMe SSD, which is not on the list of compatible drives for the Argon ONE V3 NVME PCIE case, but seems to be working nonetheless.
I have a fresh Raspberry Pi 5 /4GB straight from the box as well as a newly bought SanDisk Extreme 64GB. Used Pi Imager v1.8.5 insalled HA OS 12.1. The Pi is connected to LAN, keyboard and screen. Nothing happens? Have tried with 12.1/12.2 and 11.5 via imager. I installed Raspian OS Lite on the card and the Pi starts. Is there an issue with Pi5/4GB and HAOS 12? ( I have the original 27W power supply)
Thanks for replying! Yes, of course, I selected the Pi5 image in the imager and used the Rpi5 image from GitHub as well. I would appreciate it if this could be followed up. However, I managed to get it to work. Determining the exact solution will be challenging and I’m out of my league here. Nonetheless, I installed the Raspberry Pi OS, Bookworm release (orignal OS choice via Imager) and then performed all necessary upgrades using ‘sudo apt-get update & upgrade’ and ‘sudo rpi-update,’ with a strong belief that the latter resolved the issue. Reinstalling OS version 12.1 and it started. My connected screen was still black but I found the HA in my network.
There probably should be a flag weather to execute such an update or not.