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.
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.
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.
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
Marking messages as ignored for now and waiting for an update.
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.
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
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.
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.
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