Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Segmentation Fault in ebusctl in 24.1.0 image #154

Closed
jabdoa2 opened this issue Jan 8, 2025 · 23 comments
Closed

Segmentation Fault in ebusctl in 24.1.0 image #154

jabdoa2 opened this issue Jan 8, 2025 · 23 comments
Assignees
Labels
bug Something isn't working help wanted Extra attention is needed

Comments

@jabdoa2
Copy link

jabdoa2 commented Jan 8, 2025

I just updated the to the new 24.1.0 image. This seems to break ebusctl within the image:

docker exec -it fb8d008b0d73  /bin/bash
2ad9b828-ebusd:/# ebusctl 
Segmentation fault (core dumped)
@jabdoa2 jabdoa2 changed the title Segmentation Fault for ebusctl in 24.1.0 image Segmentation Fault in ebusctl in 24.1.0 image Jan 8, 2025
@LukasGrebe LukasGrebe added bug Something isn't working help wanted Extra attention is needed labels Jan 8, 2025
@LukasGrebe
Copy link
Owner

oh no!

can confirm:


➜  ~ docker exec -it `docker ps | grep ebusd | awk '{print $1}'` /bin/bash
2ad9b828-ebusd:/# ebusctl
Segmentation fault (core dumped)
2ad9b828-ebusd:/# 

not sure how to approach this. could this be related to #147 or #29 ?

@cociweb
Copy link
Collaborator

cociweb commented Jan 8, 2025

Unfortunatelly, the rollback to 23.2.6 is not working: it produces the same segfault.

@cociweb
Copy link
Collaborator

cociweb commented Jan 8, 2025

it seems some configuration conversion is made. please not that, the upstream ebusd has the same issue in docker.

@cociweb
Copy link
Collaborator

cociweb commented Jan 8, 2025

I was not loud enough in the breaking change section of the 24.1.0's PR. 👯

@jabdoa2
Copy link
Author

jabdoa2 commented Jan 8, 2025

Unfortunatelly, the rollback to 23.2.6 is not working: it produces the same segfault.

Rollback to 23.2.5. The 23.2.6 image seems to already contain ebus 24.1.0 (not sure why). My slightly hacky way (after restoring the backup):

# remove new images
docker rmi ghcr.io/lukasgrebe/ha-addon-ebusd-aarch64:24.1.0
docker rmi ghcr.io/lukasgrebe/ha-addon-ebusd-aarch64:23.2.6
# pull old one
docker pull ghcr.io/lukasgrebe/ha-addon-ebusd-aarch64:23.2.5
# tag it as 23.2.6 (you can also use 24.1.0 here if you did not restore the backup)
docker tag ghcr.io/lukasgrebe/ha-addon-ebusd-aarch64:23.2.5 ghcr.io/lukasgrebe/ha-addon-ebusd-aarch64:23.2.6

This got my system back into a working state.

@cociweb
Copy link
Collaborator

cociweb commented Jan 8, 2025

because the last pr only mapped the ha's config to the prebuilt gh package (which was already based on 24.1 (#152) so maybe all the compiled images after 04/12/2024 should be deleted to be able to correctly rollback.
Maybe delete the last 23.2.6 package for each variant and retag the previous one can resolve this and the rollback can work:
image
that can happen whan tag and release deviate...

@cociweb cociweb pinned this issue Jan 9, 2025
@TheEragon
Copy link

TheEragon commented Jan 9, 2025

As a workaround you can do apk upgrade and the issue will go away, but you have to do it every time you restart the Add-on

@LukasGrebe
Copy link
Owner

LukasGrebe commented Jan 9, 2025

If this is only for the precompiled docker image, how about not using that but compiling ebusd instead? - so the inverse of #29

@GuyHarg
Copy link

GuyHarg commented Jan 9, 2025

How do I roll back if I'm using the HA add-on please?

@jabdoa2
Copy link
Author

jabdoa2 commented Jan 9, 2025

How do I roll back if I'm using the HA add-on please?

See my earlier command: #154 (comment). To use those commands you would have to ssh into your HA and run those commands. That worked for me.

@cociweb
Copy link
Collaborator

cociweb commented Jan 10, 2025

As a workaround you can do apk upgrade and the issue will go away, but you have to do it every time you restart the Add-on

I can confirm. maybe there is difference between the the edge and the release version in the alpine repo?

currently we use 3.18 baseimage. ebusd 24.1 was released only to the edge and 3.21. maybe there is some dependency issue what the apk upgrade resolves. maybe it is the time to upgrade the baseimage as well?

@jabdoa2
Copy link
Author

jabdoa2 commented Jan 10, 2025

As a workaround you can do apk upgrade and the issue will go away, but you have to do it every time you restart the Add-on

I can confirm. maybe there is difference between the the edge and the release version in the alpine repo?

currently we use 3.18 baseimage. ebusd 24.1 was released only to the edge and 3.21. maybe there is some dependency issue what the apk upgrade resolves. maybe it is the time to upgrade the baseimage as well?

Using the image/distribution version matching your packages generally sounds like very good advice. Anything preventing us from upgrading? 3.18 is almost end of support anyway.

@LukasGrebe
Copy link
Owner

looking at

RUN apk add --no-cache ebusd=24.1-r0

Code Snippet Behavior

Summary

The code snippet installs the ebusd package version 24.1-r0 using the apk package manager without caching the package index.

Key Points

  • RUN directive is used to execute commands in a Dockerfile.
  • apk is the package manager for Alpine Linux.
  • The --no-cache option ensures that the package index is not cached, reducing the image size.
  • ebusd=24.1-r0 specifies the exact version of the ebusd package to be installed.

we're not running the provided ebus docker images but specifically installing the ebusd package in version 24.1-r0

-r0 might be a problem? i dont know enough about installing packages in alpine.

regardless, i'm evaluating not using a custom image via the config.yaml

image: "ghcr.io/lukasgrebe/ha-addon-ebusd-{arch}"

but referencing the offical ebusd image on dockerhub - eg changing config.yaml to image: "john30/ebusd:latest" maybe :latest is also not correct but should match the exact version tag of this project version.

this appears to have quite a few implications - removing or heavily modifying the run.sh
it also opens the door to other updates that have happend to addons in home assistant since 2021 - eg the addon specific config folder (#150, #8 #43 #91), #85 #147,

@LukasGrebe LukasGrebe self-assigned this Jan 10, 2025
@cociweb
Copy link
Collaborator

cociweb commented Jan 10, 2025

The r0 is correct. the key thing, that we use alpine 3.18 basimage:

in the repo package manager you can see, that it is only released officially on the "edge" and v3.21:
https://pkgs.alpinelinux.org/packages?name=ebusd&branch=edge&repo=&arch=x86_64&origin=&flagged=&maintainer=
https://pkgs.alpinelinux.org/packages?name=ebusd&branch=v3.21&repo=&arch=x86_64&origin=&flagged=&maintainer=

The other releases has only the 23.0-r0.

in the dockerfile we add the "edge".

-anyways it should not make any sense, but worth to try to update the baseimage, maybe there are other dependencies which is worth to update.....

@jabdoa2
Copy link
Author

jabdoa2 commented Jan 10, 2025

regardless, i'm evaluating not using a custom image via the config.yaml

image: "ghcr.io/lukasgrebe/ha-addon-ebusd-{arch}"

but referencing the offical ebusd image on dockerhub - eg changing config.yaml to image: "john30/ebusd:latest" maybe :latest is also not correct but should match the exact version tag of this project version.

this appears to have quite a few implications - removing or heavily modifying the run.sh it also opens the door to other updates that have happend to addons in home assistant since 2021 - eg the addon specific config folder (#150, #8 #43 #91), #85 #147,

the "usual" way of doing this would be to just base your docker image on the official ones. that allows you to put your own customizations as layer on top. this would be a Dockerfile such as:

FROM john30/ebusd:24.1.0 # always pin the version here. better: pin to a digest
COPY --chmod=755 run.sh /   # or similar stuff
CMD [ "/run.sh" ] # overwrite entrypoint

this way we can stay close to upstream but stlll customize. ideally we try to upstream all customizations over time.

EDIT:

just checked. i guess you can safely replace the upstream entry point: https://github.com/john30/ebusd/blob/master/contrib/docker/docker-entrypoint.sh with the existing run.sh.

@LukasGrebe
Copy link
Owner

thanks for your support.

initially set this up using the HomeAssistant addon development documentation. The Alpine Images provided by Home Assistant have bashio installed, which handels the configuration options that users of the addon can set in the Addon Configuration Tab of the Home Assistant UI.
Their Alpine Image also contains S6 - which i think has something to do with logging. It may be required for the container to start? See also init in the configuration options

so as far as i can tell, we have two options:

  1. move to a newer base image (which i'm not sure if Home assistant provides as of now)
  2. move the john30/ebusd image and install https://github.com/hassio-addons/bashio and change the entrypoint

@cociweb
Copy link
Collaborator

cociweb commented Jan 10, 2025

yes it's provided for all of the platforms (eg) , but I am unsure it will solves our problem, but worth to try to change the 3.18 tag to 3.21 (or latest):

aarch64: "ghcr.io/home-assistant/aarch64-base:3.18"
amd64: "ghcr.io/home-assistant/amd64-base:3.18"
armhf: "ghcr.io/home-assistant/armhf-base:3.18"
armv7: "ghcr.io/home-assistant/armv7-base:3.18"
i386: "ghcr.io/home-assistant/i386-base:3.18"

@LukasGrebe
Copy link
Owner

LukasGrebe commented Jan 10, 2025

looks like build.yaml appeard with cf463c5 - but according to the docs, its not required.
could we just remove it and thus always be on "latest" of HA's alpine builds? and remove https://github.com/LukasGrebe/ha-addons/tree/main/alpine in the process?

as for Option 2:
i remember questions about alpine package updates being delayed. could this be solved by moving to the ebusd docker images as i assume they would be immediately available.

we should propably merge this issue with #147 and also consider how to version this addon since our versioning may be confused with ebusd version numbers. or they should always sync but then ebusd would need to update for the addon configuration as discussed here to roll out to other installs.

@cociweb
Copy link
Collaborator

cociweb commented Jan 10, 2025

I've made a PoC in my repo and it seems it resolves the problem. Now, I've created a PR (#159), lets' check it!

Ofc it is not release ready so the https://github.com/LukasGrebe/ha-addons/blob/main/ebusd/CHANGELOG.md and the https://github.com/LukasGrebe/ha-addons/blob/main/ebusd/config.yaml are not updated.

After the build It should work in the same way:

# remove current image
docker rmi ghcr.io/lukasgrebe/ha-addon-ebusd-amd64:24.1.0
# pull the new one
docker pull ghcr.io/lukasgrebe/ha-addon-ebusd-amd64:latest
# tag it as 24.1.0:
docker tag ghcr.io/lukasgrebe/ha-addon-ebusd-amd64:latest ghcr.io/lukasgrebe/ha-addon-ebusd-amd64:24.1.0

and the final test:

docker exec -it `docker ps | grep ebusd | awk '{print $1}'` /bin/bash
2ad9b828-ebusd:/# ebusctl

@LukasGrebe
Copy link
Owner

Fixed with #159 and update to 24.1.1

➜  ~ docker exec -it `docker ps | grep ebusd | awk '{print $1}'` /bin/bash
2ad9b828-ebusd:/# ebusctl
localhost: info
version: ebusd 24.1.p20241114
device: /dev/ttyUSB0, serial
signal: acquired
symbol rate: 22
max symbol rate: 118
min arbitration micros: 5
max arbitration micros: 86

@LukasGrebe
Copy link
Owner

Thanks @cociweb !

@cociweb cociweb unpinned this issue Jan 10, 2025
@cociweb
Copy link
Collaborator

cociweb commented Jan 10, 2025

It is worth to mention from the docs that MQTT Broker server needs to be restarted after the upgrade to get the new entities.

@jabdoa2
Copy link
Author

jabdoa2 commented Jan 10, 2025

Thanks @LukasGrebe and @cociweb!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

5 participants