Journal issues with supervised install after updating to 2022.11

Hello,
here it is, it seems all correct…
It isn’t?

That’s not where I directed you. Click the link, it’s a my link, it’ll take you to the right place.

This is why we made the repairs, its very hidden right now.

Alternatively, enter this command in the CLI:

ha resolution info

The ‘Problems’ have a link that tells you exactly what to do to resolve them.

This is what I have on sudo systemctl status systemd-journal-gatewayd.service

● systemd-journal-gatewayd.service - Journal Gateway Service
     Loaded: loaded (/lib/systemd/system/systemd-journal-gatewayd.service; indirect; vendor preset: disabled)
     Active: active (running) since Thu 2022-11-03 19:46:00 CET; 41min ago
TriggeredBy: ● systemd-journal-gatewayd.socket
       Docs: man:systemd-journal-gatewayd(8)
   Main PID: 20473 (systemd-journal)
      Tasks: 2 (limit: 9334)
     Memory: 84.5M
     CGroup: /system.slice/systemd-journal-gatewayd.service
             └─20473 /lib/systemd/systemd-journal-gatewayd

Nov 03 20:19:09 homeassistant systemd-journal-gatewayd[20473]: microhttpd: Setting TCP_NODELAY option to ON state failed: Operation not supported
Nov 03 20:19:09 homeassistant systemd-journal-gatewayd[20473]: microhttpd: Setting TCP_CORK option to OFF state failed: Operation not supported
Nov 03 20:19:09 homeassistant systemd-journal-gatewayd[20473]: microhttpd: Failed to push the data from buffers to the network. Client may experience some de>
Nov 03 20:19:09 homeassistant systemd-journal-gatewayd[20473]: microhttpd: Setting TCP_NODELAY option to ON state failed: Operation not supported
Nov 03 20:19:09 homeassistant systemd-journal-gatewayd[20473]: microhttpd: Setting TCP_CORK option to OFF state failed: Operation not supported
Nov 03 20:19:09 homeassistant systemd-journal-gatewayd[20473]: microhttpd: Failed to push the data from buffers to the network. Client may experience some de>
Nov 03 20:19:09 homeassistant systemd-journal-gatewayd[20473]: microhttpd: Setting TCP_NODELAY option to ON state failed: Operation not supported
Nov 03 20:19:09 homeassistant systemd-journal-gatewayd[20473]: microhttpd: Setting TCP_CORK option to OFF state failed: Operation not supported
Nov 03 20:19:09 homeassistant systemd-journal-gatewayd[20473]: microhttpd: Failed to push the data from buffers to the network. Client may experience some de>
Nov 03 20:19:09 homeassistant systemd-journal-gatewayd[20473]: microhttpd: Setting TCP_NODELAY option to ON state failed: Operation not supported

I run sudo journalctl --verify
As I see every journal file passed. I only got this few times

7fffed0: Unused data (entry_offset==0)                                                                                     

Uhm… here it is and is flagged as unsupported but not able to understand why.
I have to dig inside a bit…

## System Information

version | core-2022.10.5
-- | --
installation_type | Home Assistant Supervised
dev | false
hassio | true
docker | true
user | root
virtualenv | false
python_version | 3.10.5
os_name | Linux
os_version | 5.19.0-0.deb11.2-amd64
arch | x86_64
timezone | Europe/Rome
config_dir | /config

<details><summary>Home Assistant Community Store</summary>

GitHub API | ok
-- | --
GitHub Content | ok
GitHub Web | ok
GitHub API Calls Remaining | 4930
Installed Version | 1.28.0
Stage | running
Available Repositories | 1130
Downloaded Repositories | 10

</details>

<details><summary>Home Assistant Cloud</summary>
`
logged_in | false
-- | --
can_reach_cert_server | ok
can_reach_cloud_auth | ok
can_reach_cloud | ok

</details>

<details><summary>Home Assistant Supervisor</summary>

host_os | Debian GNU/Linux 11 (bullseye)
-- | --
update_channel | stable
supervisor_version | supervisor-2022.10.2
agent_version | 1.2.2
docker_version | 20.10.21
disk_total | 54.9 GB
disk_used | 20.5 GB
healthy | true
supported | failed to load: Unsupported
supervisor_api | ok
version_api | ok
installed_addons | File editor (5.4.1), Node-RED (13.5.1), Mosquitto broker (6.1.3), motionEye (0.18.0), Duck DNS (1.15.0), MariaDB (2.5.1), Home Assistant Google Drive Backup (0.108.4), ESPHome (2022.10.2), Zigbee2MQTT (1.28.1-1)

</details>

<details><summary>Dashboards</summary>

dashboards | 1
-- | --
resources | 5
views | 11
mode | storage

</details>

<details><summary>Recorder</summary>

oldest_recorder_run | 25 ottobre 2022 17:08
-- | --
current_recorder_run | 3 novembre 2022 20:17
estimated_db_size | 518.23 MiB
database_engine | mysql
database_version | 10.6.8

</details>

<details><summary>Spotify</summary>

api_endpoint_reachable | ok
-- | --

</details>

These are the reasons why. You’re not understanding what I’m trying to tell you about how this works.

Supervisor decides when a system is unsupported and why, not core. For reference core is what you probably call HA and what the release notes at the top of this discussion are about. Supervisor is behind the scenes and updates out of band with core. So if your system was unsupported in version 2022.11 of HA/core it is also unsupported in version 2022.10.5 of HA/core for the same reasons.

The only thing that changed in this space between version 2022.11 of HA and 2022.10.5 is that starting in 2022.11 of HA/core repairs are added for each reason supervisor tells HA/core that the system is unsupported and/or unhealthy. Your screenshot shows those repairs so those are the reasons.

Updating to 2022.11 does not change whether a system is unsupported or unhealthy and neither does rolling back to 2022.10.5. It will be the same before and after with the same reasons. The only difference is 2022.11 you’ll see repairs and in 2022.10.5 you won’t because that feature didn’t exist yet.

7 Likes

So I vent thru all supervised requirements again… WTH I do need to do that on a system, which always has been supported?

  • Docker CE >= 20.10.17
    my version is 20.10.21

  • Systemd >= 239
    my version is 247

  • NetworkManager >= 1.14.6
    my version is 1.30.6

  • udisks2 >= 2.8
    my version is 2.9.2

  • AppArmor == 2.13.x (built into the kernel)
    my version is 2.13.6-10

  • Debian Linux Debian 11 aka Bullseye (no derivatives)
    I do have that, fully up to date

  • Home Assistant OS-Agent (Only the latest release is supported)
    my version is 1.4.1

So according to the docs my system does meet all requirements.

My HA system is:
Home Assistant 2022.11.1 Supervisor 2022.10.2 Frontend-versie: 20221102.1 - latest

Still, with all those steps I can’t get rid of the message:

update OS-agent to 1.4.1
update HA to 2022.11.1
reinstall the systemd journal service
update / upgrade Debian Bullseye
rerun the supervised installer
reinstall Docker
multiple host restarts

Also, I’m very sure, that about a week a go I have been checking the system info and logs, and there was not any sign of being unsupported. I will directly see that, if it was there.

Something must have changed. Something, that is beyond all the installation docs.

4 Likes

Ah. Yea I think something does need an update. The supervised adr mentions this:

Systemd journal gateway is enabled and mapped into supervisor as /run/systemd-journal-gatewayd.sock

I was under the impression that the installer had been updated to handle that but perhaps not. I’ll do some digging. Also looks like the ADR didn’t list systemd-journal-gatewayd in the software list when it was updated to include that additional step 2 months ago.

1 Like

I’m dealing with the same problem as you

Ive reinstalled from GitHub - home-assistant/supervised-installer: Installer for a generic Linux system
But makes no difference :frowning:

1 Like

Marking messages as ignored for now and waiting for an update. :grinning:

The installer also lacks the installation of connectivity check, which is mandatory for ages. If I run the installer now, it just rewrites the config and connectivity check is gone and must be re added manually again. :wink:

2 Likes

I got the systemd journal issue after the update of supervisor-2022.10.2 before that i did not have the error with 2022.11

I installed systemd-journal-remote and started the service (also at boot)
After restart of the system still the error.
Than I installed the lasted homeassistant-supervised.deb, rebooted and error was away.

After you get the journal thing installed, reboot the host so it can be part of the OS. Worked for me.

Now I got it thanks :slight_smile:

All I did was what I wrote above while following errors that were reported when doing so. I.e. I had messages that I need to update some packages in order for it to fully complete. It was easy to do if you read the results of the commands. I’m not at home, so I can’t post everything I had to do.

1 Like

Hi, i followed all steps mentioned here in this topic (including multiple host reboots).

Weirdly, i am unable to start the service:

pi@raspberrypi:~ $ sudo systemctl start systemd-journal-gatewayd.socket
pi@raspberrypi:~ $ sudo systemctl status systemd-journal-gatewayd.service
● systemd-journal-gatewayd.service - Journal Gateway Service
     Loaded: loaded (/lib/systemd/system/systemd-journal-gatewayd.service; indirect; vendor preset: disabled)
     Active: inactive (dead)
TriggeredBy: ● systemd-journal-gatewayd.socket
       Docs: man:systemd-journal-gatewayd(8)

Any thoughts what is preventing it from start running? I’m on Raspbian Bullseye

No, that was also happened to me. I enabled service before reboot and after reboot I had to manually start it.

Yeah, i can’t start it. Neither before reboot nor after reboot.

I made an issue. Let’s take this discussion there as the installer needs to either be updated or the guide does as it appears there’s something missing.

Please make another issue in that same repo. Seems that needs to be updated too.

6 Likes

Love the look, but unfortunately Picture Elements have stopped working with IMAGES EXAMPLE below an extract from Picture Elements Card - Home Assistant

type: picture-elements
image: /local/floorplan.png
elements:
  # state_image & state_filter - toggle on click
  - type: image
    entity: light.living_room
    tap_action:
      action: toggle
    image: /local/living_room.png
    state_image:
      "off": /local/living_room_off.png
    filter: saturate(.8)
    state_filter:
      "on": brightness(120%) saturate(1.2)
    style:
      top: 25%
      left: 75%
      width: 15%

My simple one was

type: picture-elements
image: /local/irrigation/mon-sun1.png
elements:
  - type: image
    entity: input_boolean.water_monday
    tap_action:
      action: toggle
    state_image:
      'off': /local/off.png
      'on': /local/on/png

Worked like a charm before update, 2022.11, even updated to 2022.11.1 still not working

But then again the Picture Elements stopped pushing aspect ratio a long time ago too, so now it CROPS instead of CONSTRAINT the image to FIT the aspect Ratio.

Would love both to be fixed, but at least the First one is a little more important