Home Assistant OS 17.0

[sairon]

Changes

Home Assistant OS 17.0 is a major release bringing significant updates to all platforms. This release also drops support for 32-bit armv7 targets (Raspberry Pi 2/3/4 32-bit, ODROID-XU4, and ASUS Tinker Board) as announced in May 2025. The Linux kernel has been updated to the latest version across all targets, and Docker has been upgraded to v29.1.3 with containerd v2.2.0. New installations now use the Docker containerd snapshotter by default. Console keyboard layouts can now be configured through localectl, making it easier to use non-US keyboard layouts when accessing the system console directly. All users on supported platforms are recommended to update.

⚠️ Breaking Changes

This release removes support for the following 32-bit armv7 targets:

• Raspberry Pi 2 (rpi2)
• Raspberry Pi 3 32-bit (rpi3)
• Raspberry Pi 4 32-bit (rpi4)
• ODROID-XU4 (odroid-xu4)
• ASUS Tinker Board (tinker)

Users of these devices will no longer receive updates. If you are using one of these boards, your device will no longer receive updates, please consider migrating to a supported 64-bit platform.

Docker Containerd Snapshotter

Starting with this release, new installations use the Docker containerd snapshotter by default, which provides improved performance and stability. Existing users can migrate to the new storage driver using the following command:

ha docker migrate-storage-driver

Before migrating, please note:

• Create a full Home Assistant backup before proceeding
• Internet connectivity is required for re-downloading all container images, this make take some time, especially with many installed add-ons or with slow internet connection
• At least 50% free storage space is recommended before starting the migration (note that the new snapshotter has slightly higher storage requirements)
• The migration will be applied on the next system reboot
• After the migration completes, another Supervisor or system restart may be needed to clear any add-on warnings

Note: This migration is optional and not required for your system to function properly after the update. It is recommended to perform an attended migration yet not immediately after updating, but once you have verified the system works correctly before the migration. Additionally, ensure you have reliable access (such as physical device access or access to a VM console) in case recovery is needed.

Home Assistant Operating System

• Add eq3_char_loop patch for termios2/glibc 2.42+ compatibility (Add eq3_char_loop patch for termios2/glibc 2.42+ compatibility #4471) @jens-maus
• Update generic_raw_uart package to c377d91 (Update generic_raw_uart package to c377d91 #4472) @jens-maus
• Update Docker to v29.1.3 (Update Docker to v29.1.3 #4458) @sairon
• Update BlueZ to v5.85 (Update BlueZ to v5.85 #4457) @sairon
• Bump kbd to v2.9.0, remove no longer needed gzip binary (Bump kbd to v2.9.0, remove no longer needed gzip binary #4456) @sairon
• Bump Buildroot to 2025.02.9 (Bump Buildroot to 2025.02.9 #4455) @sairon
• Bump OS Agent to v1.8.1 (Bump OS Agent to v1.8.1 #4433) @sairon
• Update to Docker v29.1.2, runC v1.3.4, containerd v2.2.0 (Update to Docker v29.1.2, runC v1.3.4, containerd v2.2.0 #4429) @sairon
• Make console keymaps configurable through localectl (Make console keymaps configurable through localectl #4424) @sairon
• Bump OS Agent to v1.8.0 (Bump OS Agent to v1.8.0 #4420) @sairon
• Bump Buildroot to 2025.02.8 (Bump Buildroot to 2025.02.8 #4415) @sairon
• Add support for QingHeng CH9200 USB ethernet adapters (Add support for QingHeng CH9200 USB ethernet adapters #4400) @jmarshallnz
• Remove Docker patch already included in v28.5.2 (Remove Docker patch already included in v28.5.2 #4398) @sairon
• Use correct per-channel AppArmor profile on clean installs (Use correct per-channel AppArmor profile on clean installs #4396) @sairon
• Update to Docker v28.5.2, runC v1.3.3, containerd v2.1.5 (Update to Docker v28.5.2, runC v1.3.3, containerd v2.1.5 #4395) @sairon
• Update Go to v1.25 (Update Go to v1.25 #4392) @sairon
• Enable iptables comments for all targets (Enable iptables comments for all targets #4391) @monosoul
• Remove support of armv7 targets (Remove support of armv7 targets #4374) @sairon
• Remove handling of Docker key.json (Remove handling of Docker key.json #4361) @sairon
• Use Docker containerd snapshotter for new and wiped installs (Use Docker containerd snapshotter for new and wiped installs #4360) @sairon

Raspberry Pi

• Remove support of armv7 targets (Remove support of armv7 targets #4374) @sairon

Home Assistant Green

• Linux: Update kernel to 6.12.63 (Linux: Update kernel to 6.12.63 #4474) @sairon

Open Virtual Appliance

• Linux: Update kernel to 6.12.63 (Linux: Update kernel to 6.12.63 #4474) @sairon

Generic x86-64

• Linux: Update kernel to 6.12.63 (Linux: Update kernel to 6.12.63 #4474) @sairon
• Enable support of i2c-based touchscreens for x86 and aarch64 (Enable support of i2c-based touchscreens for x86 and aarch64 #4463) @puterboy

Hardkernel ODROID

• Linux: Update kernel to 6.12.63 (Linux: Update kernel to 6.12.63 #4474) @sairon
• Remove support of armv7 targets (Remove support of armv7 targets #4374) @sairon

Khadas VIM Series

• Linux: Update kernel to 6.12.63 (Linux: Update kernel to 6.12.63 #4474) @sairon

Generic aarch64

• Linux: Update kernel to 6.12.63 (Linux: Update kernel to 6.12.63 #4474) @sairon
• Enable support of i2c-based touchscreens for x86 and aarch64 (Enable support of i2c-based touchscreens for x86 and aarch64 #4463) @puterboy

Build System

• Remove deprecated boards from build matrix and .github templates (Remove deprecated boards from build matrix and .github templates #4399) @sairon
• Clean up hassio build scripts (Clean up hassio build scripts #4394) @sairon
• Use OCI archive in hassio import to fix Containerd snapshotter issues (Use OCI archive in hassio import to fix Containerd snapshotter issues #4393) @sairon
• Fix tests to accommodate wait for container re-download on downgrade (Fix tests to accommodate wait for container re-download on downgrade #4368) @sairon

Dependencies

• Bump mikepenz/action-junit-report from 6.0.1 to 6.1.0 (Bump mikepenz/action-junit-report from 6.0.1 to 6.1.0 #4473) @dependabot[bot]
• Bump docker/setup-buildx-action from 3.11.1 to 3.12.0 (Bump docker/setup-buildx-action from 3.11.1 to 3.12.0 #4461) @dependabot[bot]
• Bump shogo82148/actions-upload-release-asset from 1.9.1 to 1.9.2 (Bump shogo82148/actions-upload-release-asset from 1.9.1 to 1.9.2 #4466) @dependabot[bot]
• Bump dessant/label-actions from 4.0.1 to 5.0.0 (Bump dessant/label-actions from 4.0.1 to 5.0.0 #4453) @dependabot[bot]
• Bump actions/upload-artifact from 5.0.0 to 6.0.0 (Bump actions/upload-artifact from 5.0.0 to 6.0.0 #4452) @dependabot[bot]
• Bump actions/download-artifact from 6.0.0 to 7.0.0 (Bump actions/download-artifact from 6.0.0 to 7.0.0 #4451) @dependabot[bot]
• Bump dessant/lock-threads from 5.0.1 to 6.0.0 (Bump dessant/lock-threads from 5.0.1 to 6.0.0 #4450) @dependabot[bot]
• Bump actions/cache from 4.3.0 to 5.0.1 (Bump actions/cache from 4.3.0 to 5.0.1 #4449) @dependabot[bot]
• Bump actions/checkout from 6.0.0 to 6.0.1 (Bump actions/checkout from 6.0.0 to 6.0.1 #4438) @dependabot[bot]
• Bump actions/setup-python from 6.0.0 to 6.1.0 (Bump actions/setup-python from 6.0.0 to 6.1.0 #4437) @dependabot[bot]
• Bump actions/stale from 10.1.0 to 10.1.1 (Bump actions/stale from 10.1.0 to 10.1.1 #4439) @dependabot[bot]
• Bump actions/checkout from 5.0.0 to 6.0.0 (Bump actions/checkout from 5.0.0 to 6.0.0 #4413) @dependabot[bot]
• Bump mikepenz/action-junit-report from 6.0.0 to 6.0.1 (Bump mikepenz/action-junit-report from 6.0.0 to 6.0.1 #4379) @dependabot[bot]
• Bump actions/upload-artifact from 4.6.2 to 5.0.0 (Bump actions/upload-artifact from 4.6.2 to 5.0.0 #4364) @dependabot[bot]
• Bump actions/download-artifact from 5.0.0 to 6.0.0 (Bump actions/download-artifact from 5.0.0 to 6.0.0 #4365) @dependabot[bot]
• Bump mikepenz/action-junit-report from 5.6.2 to 6.0.0 (Bump mikepenz/action-junit-report from 5.6.2 to 6.0.0 #4352) @dependabot[bot]

---

This discussion was created from the release Home Assistant OS 17.0.

[TheEragon]

Is it normal that my System uses 16.6GB (before it was 12GB) our of 28GB on HA Green after update? I did ha docker migrate-storage-driver and after that 3 reboots, all addons work but the system usage remains high.

[sairon]

The slightly higher storage usage is expected, as explained in RC feedback thread here: #4440 (reply in thread)

The actual difference may vary depending on what add-ons you have installed.

[Anto79-ops]

All good bare-metal NUC and RPi4.

[Juggler00]

Do you recommend migrating to the new storage driver?

[ralfbergs]

Is there a command to check if the storage driver migration worked correctly?

login, then docker info gives the below in case it was successful:

[Sebazzz]

Has anyone migrated to the new storage driver when also running AdGuard as the primary DNS server using the AdGuard add-on? What are the correct precautions, because I assume a working DNS server is a requirement for doing the migration.

[TRON4R]

What are the advantages of migrating to the new docker driver vs. the disadvantages if you stay with the current one?
I am not doing any snapshots (mostly for performance reasons, because HA runs in a VM on my Synology) and am simply relying on my regular backups in case I should ever need to roll back a change.
So what would be the recommended action after upgrading to HAOS 17.0? Staying with what works or migrate?

[TRON4R]

So no one here who has an opinion on the topic?

[kepstin]

What are the advantages of migrating to the new docker driver vs. the disadvantages if you stay with the current one?

Advantages of migrating:

• Maybe at some point in the future the old storage driver will be discontinued and the migration will be forced, so you're getting ahead of the curve by migrating now.

Disadvantages of migrating:

• Uses more disk space. (This might be improved in a future docker version.) Potentially a lot more space if you use add-ons.

At this point my recommendation for most people would be to leave the storage as-is on their existing installs. If a migration is needed in the future, I'm sure the HAOS devs will either handle the migration automatically or give you plenty of warning about it.

[jacques-rebiscoul]

It's good to have localectl, but how to make AltGr key active ?
On the fr keymap, we need it to generate #, {, [, |, , @, ], }.

[ralfbergs]

Works for me, using de-latin1-nodeadkeys.

[apydo]

Works for me even with 'localectl set-keymap fr'

[jacques-rebiscoul]

'localectl set-keymap fr' does not work for me, maybe because it'a a virtual machine in a synology NAS.

[uschindler]

It would really be good to have an easy (and documented) way to figure out after the first reboot that ha docker migrate-storage-driver has done its work and it is safe to reboot.

I waited until there were no active jobs anymore and rebooted finally.

My VM installation took approx 1 Gig more space after the migration. I only had the standard containers plus Mosquitto, File Editor, Esphome-Builder, Sonoff Flasher, and Samba installed.

[sairon]

The second reboot shouldn't be needed unless you get any errors about add-ons failing to start (also - as stated in the release notes, doesn't have to be reboot, ha su restart should suffice). We are still investigating causes of that and it might not be necessary in the future.

[ABEIDO]

Im could be doing something wrong but running the command in terminal doesnt seem to be accepted as a true command. I have updated to 17.0 and restarted several times. Using default terminal.

I just get (i ran info to show present state):

[ralfbergs]

IIRC, you shouldn't issue login first -- run the command in the ha > mode.

[ABEIDO]

thx, always something easy to miss.

[sairon]

login shouldn't be needed, and actually in this case (using the SSH add-on) it wouldn't work. It seems though that your SSH add-on hasn't been updated in a while, you need at least version 9.21.0 which supports the migrate command.

[neponn]

containerd 2.2.0 introduced a nasty log spam bug. This bug caused a huge blowout in my syslog / journal log sizes (multiple GBs) on other Debian servers (not HA related) until it was corrected in containerd 2.2.1. It depends a bit on system config as to how badly the bug bites.

I would be curious to know whether the impact of this bug has been considered in HAOS 17.0. Might also be good for people to keep an eye on syslog / journal log sizes.

[Anto79-ops]

here's the storage breakdown

Does rebooting Host clear the logs? At this rate, my system may crash within 5 days.

EDIT:

might have been a false alarm. Cleaned up ESPHome addon files and got about 4.5 G back

[sairon]

@Anto79-ops The Journal size is capped at 500MB. This means that once it reaches this size, the old records are purged, and on any long(er) running system, the storage wouldn't be affected by the current log traffic - it will only affect the time span of available logs.

[Anto79-ops]

Awesome. False alarm for me. It was ESPHome. Thank you @sairon

[ratatonga]

My disk usage is growing daily since migrating to docker containered. Will this stop at some point or is this a bug?
It is the containered snapshots directory that is growing, not a log file:

My proxmox backups are already more than three times the size they were before...

[mariogrip]

I have the same issue, each update to any container causes disk increase, system is using all my data...

System 25.3 GB
Add-on data 0 GB
Share 0 GB
Backups 1.2 GB
Home Assistant 0.9 GB
Free space 0.4 GB

[wfrank21]

Runs great on Proxmox, Storage Migration went through fast and without issues. Thanks!

[godoto]

Be careful with Wi-Fi adapters. My RTL8188FTV stopped working after the update. Maybe other cards RTL will have the problem too. So irritating.

[sairon]

If you've confirmed it wasn't fluke and the issue persists across reboots, could you share kernel/host logs? If the card doesn't initialize or fails in other way, there should be some messages indicating what's caused it.

[godoto]

Thanks for the reply. I restarted the entire server and the problem is still there. This is what I noticed in the logs.

2026-01-20 09:25:33.108 homeassistant kernel: usb 2-1: RTL8188FU rev B (SMIC) romver 0, 1T1R, TX queues 2, WiFi=1, BT=0, GPS=0, HI PA=0
2026-01-20 09:25:33.108 homeassistant kernel: usb 2-1: RTL8188FU MAC: 04:0c:73:80:70:67
2026-01-20 09:25:33.108 homeassistant kernel: usb 2-1: rtl8xxxu: Loading firmware rtlwifi/rtl8188fufw.bin
2026-01-20 09:25:33.111 homeassistant kernel: usb 2-1: Firmware revision 4.0 (signature 0x88f1)

(…)

2026-01-20 09:25:34.071 homeassistant kernel: audit: type=1327 audit(1768901134.069:45): proctitle="/sbin/auditd"
2026-01-20 09:25:34.077 homeassistant kernel: usb 2-1: rtl8xxxu_init_device: Failed power on
2026-01-20 09:25:34.078 homeassistant kernel: rtl8xxxu 2-1:1.0: probe with driver rtl8xxxu failed with error -16
2026-01-20 09:25:34.079 homeassistant kernel: usbcore: registered new interface driver rtl8xxxu

[back-2-95]

I just updated to this on  Apple Mac Mini 2012 Intel - no problems so far.

[apydo]

Console keyboard layouts can now be configured through localectl, making it easier to use non-US keyboard layouts when accessing the system console directly.

Thanks a lot @sairon for this one. It works fine.

Reminder : To change the keyboard layout go to the HAOS host console and in the Home Assistant CLI type 'login' then 'localectl set-keymap fr'. 'fr' here is an example for french keyboard layout (azerty).
You can leave root shell with 'exit' as usual.
You can check available layouts with 'localectl list-keymaps'.
The changes applied with localectl are immediate and persistent through reboots.

[sebastdelmotte-prog]

HI while update process i have this error

Enregistreur: homeassistant.components.websocket_api.http.connection
Source: components/websocket_api/commands.py:331
intégration: Home Assistant WebSocket API (documentation, problèmes)
S'est produit pour la première fois: 11:52:24 (1 occurrence)
Dernier enregistrement: 11:52:24

[546451914816] Error during service call to update.install: Error updating Home Assistant Operating System: Error raised from OTA Webserver: 504

RPI5 64bits HAOS 16.3 -> 17.0 update failed

2026-01-20 18:19 -> update ok version 17 great thank's for you :-)

Too process today the result of great success :-) ?

[puterboy]

Is there any way to tell if the conversion completed successfully? partially? not at all?
My biggest concern is that it got stuck halfway or that only some containers were successfully converted

[ralfbergs]

When I run the following, I get 'overlayfs'

sudo docker ps -aq | xargs -n1 sudo docker inspect --format '{{.Name}} -> {{.GraphDriver.Name}}'
/addon_local_haoskiosk -> overlayfs
/addon_a0d7b954_sqlite-web -> overlayfs
/addon_a0d7b954_nodered -> overlayfs
/addon_cebe7a76_hassio_google_drive_backup -> overlayfs
/addon_9cf1ea8f_mqtt_explorer -> overlayfs
/addon_core_nginx_proxy -> overlayfs
/addon_a0d7b954_ssh -> overlayfs
/addon_a0d7b954_vscode -> overlayfs
/addon_5c53de3b_esphome -> overlayfs
/addon_core_mosquitto -> overlayfs
/hassio_multicast -> overlayfs
/hassio_audio -> overlayfs
/hassio_dns -> overlayfs
/hassio_cli -> overlayfs
/homeassistant -> overlayfs
/hassio_observer -> overlayfs
/hassio_supervisor -> overlayfs

IIUC, this means that the low-level storage driver utilized for the container is overlayfs -- which seems to be part of what you wanted to achieve.

But when I run the following I get all 'null's

sudo docker container ls --format='{{.ID}}' | xargs -r -n1 sudo docker inspect | jq '.[] | .Storage.RootFS.Snapshot.Name'

This info seems to indicate information about the specific snapshot being used for the container's writable layer. So maybe the low-level storage driver has been changed, but the migration was not fully successful?

We really need someone with a clue to help us here, I will now keep quiet because I'm pretty much clueless...

[ralfbergs]

My install is a HAOS install, what about you guys? Maybe you have a fundamentally different setup, which could explain the different container Storage details?

I am running HAOS with standard install on bare metal Ace Magician Vista Mini V1 Mini PC (Intel).

So we all use HAOS -- whether on bare metal or virtualized shouldn't matter...

[ABEIDO]

Just to add: I just tested to set up a brand new vm with latest 17.0 HAOS image as my present test image has been running since HAOS 11.0, getting same results there. No restore, nothing just default HA.

[sairon]

There's no reason to overthink this - Docker can use only a single storage driver at a time - if the daemon configuration (reported through ha docker info) tells it uses overlayfs, it means all images are using the overlayfs storage backend. If an image were not migrated, it won't be present in docker images, as simple as that. You can also see that after the migration, /mnt/data/docker/overlay2/ (where overlay2 graph driver saves the data) doesn't exist anymore.

[puterboy]

Thanks @sairon!!!! -- that confirms it and solves my issues.
Just was being a little "paranoid" without explicit feedback/confirmation that the migration worked

[keithr59]

Successfully migrated a Home Assistant Green with 8 addons installed.

Whole process took 11 minutes with no additional reboots/restarts necessary. Disc usage increased by 1.3 GiB.

[trex2000]

Still the issue persists since 16.0 . The last successful image that boots is 15.2. Tried all 16.x, same issue, reported it here. HA Yellow CM5, OS running on NVME. Tried several NVME, so we can exclude physical issue with nvme. Installing on the same nvme 15.2 works without I/O errors.

[sairon]

Please don't spam the discussion, I've removed your other posts. Open an issue instead and describe your hardware setup. Also, have you tried if Raspberry Pi OS works on this hardware without issues?

[chrismochinski]

I've been unable to migrate to NVMe since early January 2026 because the system thinks I'm "in the future." Any idea if this might help? The assembly/disassembly process is a bit of an undertaking and I'd like to avoid unnecessarily tearing stuff apart any more than I have to.

Also, Voice Preview bug fix?

[jimrkerry]

I ran "ha docker migrate-storage-driver" on x86_64.

After the reboot to do the migration, it unexpectedly had updated me from Core 2025.12.5 to 2026.1.2.
I had 7 repairs. Six for addons and one for the system being in an unhealthy state.

A second reboot removed all the repairs and everything looked OK.

These are the Supervisor error messages:
2026-01-21 23:31:00.983 ERROR (MainThread) [supervisor.jobs] Unhandled exception: Cannot update a job that is done
2026-01-21 23:31:00.989 CRITICAL (MainThread) [supervisor.core] Fatal error happening on load Task <coroutine object AddonManager.load at 0x7fddaebef840>:
2026-01-21 23:31:01.329 CRITICAL (MainThread) [supervisor.core] System is running in an unhealthy state and needs manual intervention!
2026-01-21 23:31:01.636 ERROR (MainThread) [supervisor.addons.addon] Could not start container for addon a0d7b954_nut: Another job is running for job group container_addon_a0d7b954_nut
2026-01-21 23:31:07.361 ERROR (MainThread) [supervisor.addons.addon] Could not start container for addon core_samba: Another job is running for job group container_addon_core_samba
2026-01-21 23:31:07.558 ERROR (MainThread) [supervisor.addons.addon] Could not start container for addon 5c53de3b_esphome: Another job is running for job group container_addon_5c53de3b_esphome
2026-01-21 23:31:13.134 ERROR (MainThread) [supervisor.addons.addon] Could not start container for addon core_openwakeword: Another job is running for job group container_addon_core_openwakeword
2026-01-21 23:31:13.149 ERROR (MainThread) [supervisor.addons.addon] Could not start container for addon core_piper: Another job is running for job group container_addon_core_piper
2026-01-21 23:31:13.160 ERROR (MainThread) [supervisor.addons.addon] Could not start container for addon core_whisper: Another job is running for job group container_addon_core_whisper

[DobrCr]

For me to. Running the command automatically updated Core to the latest (currently 2026.2.3) which was unexpected.

[uschindler]

The problem with the migration is that it basically uninstalls all docker containers and reinstalls them from network. This has the side effect that it downloads the newest version, so the forceful upgrade is unavoidable (the way how the migration is setup at moment).

[DobrCr]

Thanks for a prompt reply. It's not a problem, it was just unexpected. It would be helpful to make note about it in the release notes. But it might just be my lack of knowledge not knowing it would forcefully update Core too so such a note is unneeded.

[darkguset]

Successfully upgraded both the OS and the driver on a QNAP NAS system. No issues so far - it took about 30 minutes in total. Only the one reboot required to initiate the driver upgrade.

[z-master42]

As stated in the information dialogue box in the console, the migration takes place during a restart, i.e. the migration is complete once Home Assistant has finished restarting.

[sofkaski]

Update went smoothly in my Pi4 environment and everything seems to work. Only related thing that I noticed is the following warning in logs after the final reboot:

Logger: homeassistant.components.recorder.util
Source: components/recorder/util.py:273
integration: Recorder (documentation, issues)
First occurred: 16:45:41 (1 occurrence)
Last logged: 16:45:41

The system could not validate that the sqlite3 database at //config/home-assistant_v2.db was shutdown cleanly

[gfn256]

I am also seeing an increase in disk usage post HAOS 17 & storage migration.
See here another user suffering the same apparently.

[agners]

The reason is most likely that containerd snapshotter stores the uncompressed layers as well. This is documented in the Docker documentation about containerd image store with Docker Engine. For pure image consumption, maybe these uncompressed layers could be purged. But it doesn't seem there is an option to disable this behavior 😢

[MEKadan]

Just for info, to monitor the migration process, you can (at least with HAOS/ Rpi) always use your base address, eg. 192.168.x.y:8123 to connect to HA, where you should see this soon after required restart:

[GuyHarg]

Was offered update to Core 2026.1.3 and OS 17.0 yesterday. Core updated successfully but OS 17.0 is giving me a range of errors. Pi5 setup.

First error is:

Failed to perform the action update/install. Error updating Home Assistant Operating System:
'OSManager.update' blocked from execution, no supervisor internet

Then when I try again I get:

Failed to perform the action update/install. Error updating Home Assistant Operating System: Can't fetch OTA update from https://os-artifacts.home-assistant.io/17.0/haos_rpi5-64-17.0.raucb: Cannot connect to host
github.com:443 sslidefault [Timeout while contacting DNS]

Still on OS 16.3 which seems to be operating normally. Have restarted and rebooted multiple times.

[GuyHarg]

Thx when I click the link it downloads immediately. I’ve had the odd issue that I’ve left and returned to successfully but this has been → 24hrs. More recently I started having trouple resolving http://homeassistant.local:8123/ which I’d never had and had to revert to using IP addresses. Bit lost on it tbh.

[TRON4R]

Sounds like you have general DNS resolution issues. But please take into account that clicking on a link on your computer only verifies that your computer can resolve DNS correctly. The server / VM / docker your HA is running on could still have DNS problems!

[GuyHarg]

No science in this but I just kept updating and the error message changed three times and on the fourth the update went through. I need to fix my general DNS resolution issues, but that was a little strange.

[dangel666]

I've learnt to leave a 'stuck' update and walk away and try later. 95% of the time I don't see this problem though.

[fishhy]

I was very stable on HAOS 16 on Proxmox- after the upgrade to HAOS 17 I'm experiencing a lot of DNS issues that are causing the supervisor to panic and restart various stuff (veth interface). I've done a TON of research on it to make sure it wasn't my router causing the issue. I've basically bypassed my router but still see a bunch of DNS and network issues on the docker network interface. I am able to test from inside the VM as well as using python inside of the container but don't see an actual issue (seems to have something to do with plugin's interface).

Unfortunately my snapshot of HAOS16 has already rolled off so I'm stuck for now, but the problem still seems to be there (panic about once per 10 minutes in HAOS17).
Even though I can python in and test DNS from inside the container, I'm still seeing a bunch of DNS/Network issues. They all seem to deal with IPV4 and DoT (DNS over TLS on port 853).

[ericyew]

Feels like everything is now a bit laggy since upgrading to haos 17. Switching between dashboard view tab takes a few extra second. Animation isn't smooth anymore.

[dangel666]

I've noticed no difference - definitely no lag here..

[clangren]

We also run on Proxmox (V9.1.4). Storage Migration went through without excitement.

FWIW -> Supervisor messaged re: "..taking longer than expected" and went back to a ">ha" prompt when (I believe) the migration was still ongoing. We reran "supervisor logs" to check status until the log output appeared to be completely settled before rebooting.

Thanks for all your excellent work!

[sfskipperjim]

I'm running 16.3 on a p400 and several attempts to upgrade to 17.0 have all failed. There is a problem with influxDB:

error msg="Cannot read corrupt tsm file, renaming" log_id=10rSs2ml000 engine=tsm1 service=filestore path=/data/influxdb/data/homeassistant/autogen/546/000000005-000000002.tsm id=0 error="init: read tombstones: open /data/influxdb/data/homeassistant/autogen/546/000000005-000000002.tombstone: too many open files"

This is followed by continual 'too many open files' and eventual system reboots.

[madtownchris]

Tried upgrade to 17 yesterday on a Proxmox VM and encountered severe slowness. I didn't have a lot of time to diagnose as this was "production" but I did notice that uptime showed a very large load. I tried waiting patiently for whatever it was to finish but after about 10-15 minutes I gave up.

It was really abysmally slow. I rolled back to 16.3 and no problems.

[t9001]

Maybe a dumb question... I don't use docker, just the normal installation on an rPi 5. Do I need to migrate?

[z-master42]

Home Assistant uses Docker. And you can do whatever you want.

[brandonee916]

Completely broke my Pi 5 after I did the migration... I highly recommend you download a Backup file before hand... unlike me. Now I'm rebuilding my HA from scratch because the after the migration the backups on the SD card were corrupt.

[pepijndevos]

@sairon you mentioned the plan that the next HAOS release would make it easier to maintain a fork, any news on that?

#4335 (review)

[ckhordiasma]

Did the migration command and then immediately restarted. On reboot, was greeted with system not ready with state setup which was a little concerning, but then by going to

ha> login
journalctl -f

I could see that it was still trying to download containers and stuff. so I just waited some more and it was able to proceed