operating-system

[quick jay]

Oh hi there 👋

Welcome to #operating-system. The comms channel for the Home Assistant Supervisor and Operating System team at the Open Home Foundation.

Home Assistant is built in the open, and this channel is part of that. We use this channel for day-to-day communication from the Supervisor and OS team. OS/Supervisor/App developers, contributors, or anyone else, are welcome to join the conversation. You can follow along with what we are working on, what is changing, and the context behind technical decisions.

This channel focuses on development around the Home Assistant Operating System, the Supervisor, Supervisor plugins, and the official Home Assistant apps.

What this channel is not: General coding help or “how do I…?” support. Please use #1257019582112334014 .

If you want to contribute, ask questions about direction and decisions, or help sanity-check an approach, you are in the right place. Feel free to jump in! 🙌

../Frenck
Lead of Home Assistant

[sudden portal]

@quick jay I have a question! Do we have a audioserver like pipewire or older pulseaudio installed by default or just alsa support?

[quick jay]

Audio server of Home Assistant

[quick jay]

@brazen lava @uneven ruin Is https://github.com/home-assistant/core/pull/163907 something we still want to push for this beta?

[brazen lava]

@quick jay yes if possible. Sounds like @uneven ruin is ok with it. It won't be active immediately as Supervisor side is not yet merged. But it would allow us to work with it from Supervisor side.

[quick jay]

Alright 👍

[uneven ruin]

Merged and building a new nightly so we both can test it for side effects for the beta cut

[quick jay]

Nice! Thanks 👍

[reef goblet]

The supervisor tends to add to error messages "check logs with ha supervisor logs" https://github.com/search?q=repo:home-assistant/supervisor+"ha+supervisor+logs"&type=code. And those end up in the UI. I think that we should drop them from the error message. If this is something we want to show in the CLI, we can have the CLI add that message maybe?

And if people need to find the logs, this PR can help 🙂 https://github.com/home-assistant/frontend/pull/51259

[brazen lava]

@reef goblet support found this more useful, see https://github.com/home-assistant/supervisor/pull/6250. I've raised that UI location would probably be more helpful. But it fullfilled a particular pain point back then brought up by @quaint cave: When users used the console to reset auth, e.g. ha auth reset --username wronguser --password <newpw> they often didn't know the username. Using a wrong user lead to "Error: Unknown error, see Supervisor logs", which people did not know what to do next. The change directed people to the log command (the log then contained that the username is wrong 😅 ).

Meanwhile, we raise more specific errors in many places thanks to https://github.com/home-assistant/supervisor/pull/6303, this particular case now looks like this:

# ha auth reset --username wronguser --password test
Error: Username 'wronguser' does not exist. Check list of users using 'ha auth list'.

So the initial case which drove this message change is not even relevant anymore. I'll post a PR to remove the check logs part again.

[brazen lava]

PR: https://github.com/home-assistant/supervisor/pull/6684

[glad crypt]

oh! these come up in a nice pop-up now with a link to the supervisor logs at the bottom? That's great! yea we should totally toss the cli command instructions then

I only put that in because before it appeared in a little toast prompt that went away. And it was impossible to put a link to the Supervisor log like I wanted to in a toast prompt

but if these all come up in that nice pop-up now then the cli directions are easily droppable

[brazen lava]

Supervisor 2026.03.3 looks good on the beta channel from Sentry insights, so let's move it to stable channel: https://github.com/home-assistant/version/pull/503

[storm snow]

On a similar note, OS 17.2 is currently being built and on the way to the stable channel as well: https://github.com/home-assistant/operating-system/releases/tag/17.2

[brazen lava]

aaaand shipped 🚢

[stray bridge]

I installed on three instances, two of them complained about docker hub rate limiting, which was strange. Haven’t been able to figure a root cause. I don’t think my mom was abusing the rate limit 🙂

[brazen lava]

@stray bridge we did rollout a new Sueprvisor, which put some strain on the GitHub container registry. it should be rolled out at this point though.

[stray bridge]

Thanks. That's what I figured. I just wanted to note it - as HA (and HAOS) gets more "less technical" users, we'd have to try and sort that error to not be so ominous.

[reef goblet]

Yeah seeing more reports on the too many requests error, anything we can do there? https://mastodon.social/@ottaross/116363912948544312

[orchid orbit]

i wonder in the future if its best to somehow implement a "staged" rollout for people who dont manually force check for updates, to circumvent too many people hitting the registry at once and getting rate limited

[storm snow]

The rollout is already staged - it used to be ~7.5 hours, after encountering issues with rate limiting (again) we switched to 24 hours... but there was a bug. After this it should really be 24 hours: https://github.com/home-assistant/supervisor/pull/6705
CC @reef goblet

What also puts the strain on the registry is when an image has too many layers - it seems that every layer check and download counts as a request, so one user can easily do tens of requests per update. I'm planning on looking into that and making our images better optimized in that regard, which should help as well.

[reef goblet]

Any reason we don't flatten our image?

[storm snow]

The reasons were mostly build time optimization and layer reuse on updates. But with the recent builder refactoring, the first argument doesn't stand much anymore, and the reuse also isn't that big if early layers change. But in short it's exactly what I plan on doing.

[stray bridge]

a lifetime ago I worked on a system where a large number of clients had to get updates every day. We did a bit of work to randomize their access - sort of each client got a hash slot and then kept it (like a seed) so future updates were already smoothed over. Also though of mimicing exponential backoff like ethernet, but perhaps just smoothing over 24 hours is enough 🙂

[brazen lava]

Supervisor essentially schedules the task on startup. We've previously monitored a rollout, it seems that last restart/bootup is quite well randomized accross all systems out there 😅

(data taken from the public ghcr download stats)

That said, I'd like to have more control over our rollout. The beta channel is helpful, but there are only so many users (and typcally with quite similar setups) on it. I think it would make sense to rollout to say 5% stable users first, Before committing to full rollout.

[stray bridge]

that's an amazing distribution, no notes 🙂

[brazen lava]

New Supervisor release 2026.04.0 on beta channel: https://github.com/home-assistant/supervisor/releases/tag/2026.04.0

It now enabled IPv6 in the internal container network by default. Supervisor did enable it already by default on new installations since June 2025, no negative reports received, so I expect this to be quite unproblematic. The effective Docker network migration (hassio) will happen on reboot only, so after installing this new Supervisor version, a reboot will be required for this change to take effect. But we won't force user to reboot, it just will happen whenever users restart.

[sullen sentinel]

-# restarting...

[sullen sentinel]

it works, very exciting 😛

[stray bridge]

seems to work, is there anything you would like poked, let us know. I would say it took a while when doing the update to fetch everything, so my supervisor/instance stayed in the "set up" state for minutes...but otherwise all works!

[brazen lava]

If the hassio network has no ULA IPv6 address assigned (specifically fd0c:ac1e:2100::1), then the update likely printed this:

2026-04-09 22:23:35.557 INFO (MainThread) [supervisor.docker.network] Migrating Supervisor network to IPv4/IPv6 Dual-Stack
2026-04-09 22:23:35.557 WARNING (MainThread) [supervisor.docker.network] System appears to be running, not applying Supervisor network change. Reboot your system to apply the change.

After a OS restart it Supervisor should enable IPv6 on the internal hassio network.

[sullen sentinel]

yep I saw exactly that and indeed after reboot it has IPv6

[reef goblet]

On HAOS: in ha-config-backup-overview.ts, inside _newBackup() when generateBackup or the automatic one, raises an error, we do not show the error to the user. We just show "Failed to create backup" while we do log the error to the console. Error has code home_assistant_error and message: "Error creating backup: 'BackupManager.do_backup_partial' blocked from execution, not enough free space (1.0GB) left on the device."

We should not make this error a generic home_assistant_error but probably have a specific error for backups, and let the user know about the error

When adding a network storage in the UI, "Mounting X did not succeed. Check host logs for errors from mount or systemd unit mnt-data-supervisor-mounts-XX for details"

can we just include those logs in the UI ?

[reef goblet]

PR https://github.com/home-assistant/frontend/pull/51520

On my dads HA Blue, the core update is extremely slow when it gets to 81%. It's now on 86% and it took like 10 minutes or so to get there

[reef goblet]

Whenever there is a supervisor update, (which on dev is often), all updates break until I click supervisor update. Now when supervisor updates, the update entity for supervisor update will remain saying there is an update. And hitting update will fail. It's quite a poor experience. I can imagine that when supervisor is updated on stable, all users experience something similar?

[delicate fossil]

I may be wrong but on stable we don’t see separate supervisor updates, it just gets updated whenever there is a core update.

[terse scarab]

There are separate Supervisor updates.

[reef goblet]

You see the update entity go active, and then couple of hours later we do it

[river wraith]

● Opened PR #4652 — fixes CMA pool exhaustion on rpi4-64 / HA Yellow (CM4) during sustained TLS upload. vc_sm_cma
consumes the full 64 MiB pool at boot, leaving no headroom for bcmgenet DMA ring growth; under nightly cloud backup
the ethernet stalls silently after ~3 min and requires a power cycle.

Fix is cma=256M on the Broadcom boards. Validated on stock HAOS 17.2 — 20 min sustained workload, zero CMA drift,
zero link drops. Repro harness and before/after logs in the PR.

Would appreciate eyes from anyone with a Yellow or rpi4-64 who can run the harness.

https://github.com/home-assistant/operating-system/pull/4652

[brazen lava]

Uh yeah I this is something which annoys me since a long time 🙈 I have a fix locally, need to make it ready for submission again.

I wanted to wait for the coordinator splitup to be merged first (https://github.com/home-assistant/core/pull/167080), but now that this is in, let's get this sorted.

[brazen lava]

Typically you don't see them, since when Supervisor refreshes update information, we immediately update Supervisor if a new version is there.

But: If you manually update version information (via Settings -> three dot menu -> Check for updates), this forces Supervisor to update its version information as well. In this case we do not automatically update the Supervisor. If we would, and then you press update on a app update, you'd see some weird error (Supervisor not running or something). So after a forced update refresh, we simply present you the Supervisor update separately.

There is one wrinkle: So far, if you update any app, it forces a Supervisor update information refresh as well. This is unnecessary and changed with the above PR (so with Core 2026.5.0). With this behavior, if you update an app, we won't force update the Supervisor information. This will reduce the amount of Supervisor update users see a lot.

[brazen lava]

This improves the Supervisor update entity handling: https://github.com/home-assistant/core/pull/168712

[rose tapir]

Hi! Hope you don’t mind me asking a couple weeks after the fact here. I’ve been curious about this concept for a while but don’t know quite where the line is drawn on optimal state.

In my head, I imagine one of the “more ideal” cases for an end user updating a docker image is to download the least amount of data. Less data transmitted, less energy used generally speaking, etc.

In terms of an equitable and accessible experience, I’d like to think the “more layers” approach favors users with lower- or limited-bandwidth or data-capped connections; only download new things, not the same things (again, totally speaking off the cuff here, and I’m probably glazing over a ton of things that I know only a little bit about)

Then on the flip side of that coin is the docker image optimizations balancing number of layers with complexity of pipelines (and just sheer feasibility on what can even be separated into different layers, and as it turns out, also balancing that with requests and load limiting for a widely used project)

I guess when I hear “flattening the image”, my first thought is that end user case. I don’t think I’ve ever personally been ultra concerned with this as an end user, but I figured I would post this and see if I’m totally off base here, or more likely than not “only a little bit correct but mostly not super critical” 🤣

Anyway, thanks for entertaining this thought if you would!

[storm snow]

The images shouldn't be straight out flattened, and the layers should represent some architectural blocks. That's what was done in https://github.com/home-assistant/docker-base/pull/358 already. In case of plain Alpine base, the official Alpine base image is now a single layer, the extra stuff added by us another one. It was in general never true that more layers could be reused between base releases - the base image digest changes from time to time and then invalidates all following layers.

For more complex images like Core, the same logic should be applied. Since the Python dependencies change between every release, this invalidates all following layers, so there's no point in creating many layers. OTOH if there's something we don't expect to change between releases, it should be kept in a separate layer indeed, but currently it's probably only the go2rtc binary -- and that layer is still invalidated if the base image changes (currently - wouldn't be if --link was used which would be probably fair). So that's basically where the line is drawn :)

[rose tapir]

Ahh I see, I see! Thanks for the notes and link too. From what I saw with the base and python images, they all seemed to make sense. By no means do I have any complaints here, so thanks again for the kind reply! 😄

[reef goblet]

Can confirm it works !

[hexed viper]

Anyone know what the status of HAOS with the CVE-2026-31431 ”Copy Fail” also affecting across containerization?

Scary that the only thing it takes is a 732 byte python script😳

[lyric plover]

There's a commit that updates Home Assistant OS to a patched version of the linux kernel, but it's not in any release yet. So it's still vulnerable until the release I guess: https://github.com/home-assistant/operating-system/commit/c8ec98f2dded701d68b1ffeaaeca9bb06329c3d8

[molten atlas]

Ha! I just watched your video Theolingo Jovio and came here to ask the same question.

[brazen lava]

Supervisor can use Unix domain socket to communicate with Core. This is not yet enabled by default, but can be enabled via Supervisor feature flags:

ha supervisor options --feature-flag unix_socket_core_api=true

This will become active on next Core update, or when recreating the Core container using:

ha core rebuild

The Supervisor will log accordingly:

[supervisor.homeassistant.api] Connected to Core via Unix socket /run/os/core.sock

If you notice any issues please report a bug in the Supervisor repository.

[sweet belfry]

What’s the benefit of that new feature?

[quaint cave]

It looks like it replaces what is normally an internal http connection with a direct connection between supervisor and core. Internal plumbing change.

[toxic basin]

Will this fix all the websocket errors multiple people are experiencing?

[balmy holly]

Mhh I get: Error: unknown flag: --feature-flat :/

[sullen sentinel]

There seems to be a typo...

[brazen lava]

You mean the warnings? They will be addressed by the next Supervisor release

[balmy holly]

thx but it was just in discord 😄

[brazen lava]

What is ha cli version saying?

[balmy holly]

it just prints the help 🤔

I am in the Terminal & SSH app web

[fossil quartz]

Hi everybody, I have a question regarding IPv6 static and dynamic assignment
I have HAOS running in a dedicated VLAN. When I enable IPv6 it correctly receives a dynamic GUA within 200x:: range. What I now want to achieve is to additionally assign a static LUA (within fd20). Is this possible?

[terse scarab]

That doesn't sound development related. #1284966540617449515 would be the right place for support.

[fossil quartz]

oh, ok. Sorry for that

[brazen lava]

Ah yeah that just got updated, you need to upgrade to 10.2.0 to get the command.

[balmy holly]

ahh thanks. Now it works 🙂

[sullen sentinel]

I have enabled it on both my environments as well