Supervisor update

Can’t see how this is relevant but yes, boot partition is mounted. Is a /firmware folder supposed to exist inside /boot in a Debian installation for Pi 4? My installation has no /firmware folder inside /boot. From what I can remember cmdline.txt was always in /boot, not in /boot/firmware…

I now have a different issue, after upgrading to Bullseye (or at least that’s when I noted), the logs in Supervisor/System occasionally do not load. The strange thing is that only Supervisor, Core and Multicast logs are affected, all other logs show up ok.
I have to reload the core or the supervisor logs for them to show, but after a while I only have a spinning circle like in the below screenshot.
When I have the spinning circle I do
ha core logs
ha multicast logs
ha supervisor logs
and nothing comes up. When I restart the Supervisor and I see the logs in the frontend, the above commands return the logs properly.

I just saw this :

1.2.0

@github-actions github-actions released this 21 hours ago

Are we supposed to manually look in that github and update everytime manually ? or is there a way to add it as a repository, so we can update with apt-get update && apt-get upgrade ?

1 Like

I was wondering the same thing as I installed OsAgent in the first place…
Regarding the cgroups (v2) problem in Pi4 and RAM usage not showing, I’ve found a solution (Debian bullseye 64). The cgroup memory is not enabled by default in the Pi kernel. So it first has to be enabled and then the above lines added in /boot/cmdline.txt, in order for v1 to be used. So I appended in cmdline.txt, just after …115200: cgroup_enable=cpuset cgroup_enable=memory cgroup_memory=1 systemd.unified_cgroup_hierarchy=false systemd.legacy_systemd_cgroup_controller=false.
And I have RAM usage! No idea though if this is connected with the other problem I’m facing above with the logs randomly not showing with a spinning circle.

I suspect that it will be possible to cteate some sort of update sensor for that.

The GitHub integration tracks releases as well

Yep just added home-assistant/agent-os to my github integration config.

I tried the github integration above that @ludeeus mentions and got no errors. Do you know the name of the standard sensor it creates if you don’t add a custom name? I can not seem to find it.
Thanks.

  - platform: github
    access_token: xxx
    repositories:
      - path: 'home-assistant/core'
      - path: 'home-assistant/os-agent'

creates

Then you get the version in a template:

    - name: "os_agent_version"
      unique_id: 'f84c6526-c184-42f0-b384-7081d53388bc'
      state: >
        {{state_attr('sensor.os_agent', 'latest_release_tag') }}

1 Like

Thanks, I did not understand the directions from @ludeeus link above. I did not understand you needed to add the os-agent path. I incorrectly thought the agent was part of the core.

On your template how did you generate the unique id?

After upgrade to Supervisor 2021.10.6 (os-agent 1.2.2), the CPU and RAM usage is again not shown properly. It seems that only one measurement is taken upon opening of the page and then it is not refreshed accordingly. So a measurement is shown but it is stuck in the initial state, thus it is not “live”.
I had already added cgroup_enable=cpuset cgroup_enable=memory cgroup_memory=1 systemd.unified_cgroup_hierarchy=false systemd.legacy_systemd_cgroup_controller=false in the cmdline.txt of my Pi4 to disable cgroup v2 and it worked ok in previous versions. I tried to remove/add some of the above attributes in the cmdline but the situations persists. cat /proc/cgroups shows both cpu and ram as enabled. Stats are shown ok and live through portainer. This has to do with an upgrade of Supervisor (or OS-agent?).

Maybe someone tell me how to remove this warning from supervisor log:

WARNING (MainThread) [supervisor.bootstrap] Missing SUPERVISOR_MACHINE environment variable. Fallback to deprecated extraction!

I added machine to /etc/hassio.json file

{
    "supervisor": "homeassistant/amd64-hassio-supervisor",
    "homeassistant": "homeassistant/intel-nuc-homeassistant",
    "machine": "generic-x86-64",
    "data": "/usr/share/hassio"
}

rebooted the device but I still have this warning in the log. What can I do?

Add it to the docker run command.

See post 15

This is my /usr/sbin/hassio-supervisor file. Warning still appears in the log.

#!/usr/bin/env bash
set -e

# Load configs
CONFIG_FILE=/etc/hassio.json

SUPERVISOR="$(jq --raw-output '.supervisor' ${CONFIG_FILE})"
MACHINE="$(jq --raw-output '.machine' ${CONFIG_FILE})"
HOMEASSISTANT="$(jq --raw-output '.homeassistant' ${CONFIG_FILE})"
DATA="$(jq --raw-output '.data // "/usr/share/hassio"' ${CONFIG_FILE})"

# AppArmor Support
if command -v apparmor_parser > /dev/null 2>&1 && grep hassio-supervisor /sys/kernel/security/apparmor/profiles > /dev/null 2>&1; then
    APPARMOR="--security-opt apparmor=hassio-supervisor"
else
    APPARMOR="--security-opt apparmor:unconfined"
fi

# Init supervisor
HASSIO_DATA=${DATA}
HASSIO_IMAGE_ID=$(docker inspect --format='{{.Id}}' "${SUPERVISOR}")
HASSIO_CONTAINER_ID=$(docker inspect --format='{{.Image}}' hassio_supervisor || echo "")

runSupervisor() {
    docker rm --force hassio_supervisor || true

    # shellcheck disable=SC2086
    docker run --name hassio_supervisor \
        --privileged \
        $APPARMOR \
        --security-opt seccomp=unconfined \
        -v /run/docker.sock:/run/docker.sock \
        -v /run/dbus:/run/dbus \
        -v "${HASSIO_DATA}":/data \
        -e SUPERVISOR_SHARE="${HASSIO_DATA}" \
        -e SUPERVISOR_NAME=hassio_supervisor \
        -e SUPERVISOR_MACHINE="${MACHINE}" \
        -e HOMEASSISTANT_REPOSITORY="${HOMEASSISTANT}" \
        "${SUPERVISOR}"
}

# Run supervisor
mkdir -p "${HASSIO_DATA}"
([ "${HASSIO_IMAGE_ID}" = "${HASSIO_CONTAINER_ID}" ] && docker start --attach hassio_supervisor) || runSupervisor

Hi Gress.lars
I want to change default data share folder before installing home assistant supervised.
I tried to modify homeassistant-supervised.deb
I unpaked it
found line

 DATA="$(jq --raw-output '.data // "/usr/share/hassio"' ${CONFIG_FILE})"

in usr/sbin/hassio-supervisor and in hassio-apparmor
modified both lines with

DATA="$(jq --raw-output '.data // "/srv/dev-disk..."' ${CONFIG_FILE})"

I repaked the new package and installed it
but in my env variable remain “SUPERVISOR_SHARE=/usr/share/hassio”
Do you know what is wrong and have you a solution to modify this environment variable.
Thank’s

I found a method to define another place for data, not very elegant, but which works.
as in the message above
replaced the line

DATA="$(jq --raw-output '.data // "/usr/share/hassio"' ${CONFIG_FILE})"

by

DATA="/srv/dev-disk..." # (my folder)

in usr/sbin/hassio-supervisor and in hassio-apparmor
I repaked the new package and installed it
I Also change the line data in /etc/hassio.json

"data": "/srv/dev-disk..."

All work fine, I can reach the data folder which is now on a disk of my openmediavault by the samba service

@KingRichard I had the same problems. Thanks to your post I got my installation running. I have the same setup as you (Raspberry Pi 4, Debian 11).

I believe the latest installation did not require this anymore.

I followed the instructions here:

And installed supervisor on fresh Debian 11 on Rpi4 with 1.2.2 (aarch64) version of OS-Agent and had the same problem with /etc/machine-id .

Ended up using the solution provided by @KingRichard and the supervisor is now working.

Nice! Thanks! This solved my “You are running an unsupported installation” on RPI 4 debian 11
Thank you!

Execute:
sudo sed -i '$s/$/ systemd.unified_cgroup_hierarchy=false systemd.legacy_systemd_cgroup_controller=false/' /boot/cmdline.txt

1 Like