xtensa-lx106-elf-g++: not found #1386
Comments
|
Odroid N2 is an armv7 device, right? Notable is that it installs an extra toolchain here: Not sure why that's happening as the image is supposed to contain the right toolchain already. Command not found could also mean a broken symlink, so maybe check with In the docker base image build the xtensa-lx106-elf-g++ command does exist: https://github.com/esphome/esphome-docker-base/runs/925103486?check_suite_focus=true#step:9:133 (ignore the |
|
Odroid N2 has ARM Cortex-A73 and A53 CPUs which are armv8. Downloaded image is armv7. Where do you want me set the |
|
Is esphome/esphome-docker-base#5 related in any way? |
|
Investigating further, I saw that builds actually fail for ESP32 boards in the current stable version (1.14.5) as well: esphome:
name: test32
platform: ESP32
board: esp32devThere the Download part is not shown in the logs... |
|
@gitolicious No esphome/esphome-docker-base#5 is not related. I tried to manually set up a qemu aarch64 VM using the |
|
Thx for looking into it. Any idea how I could investiage further on my end? Tried uninstalling the add-on and deleted everything I found in the data folder other than the config YAMLs. Reinstalled and ended up with the same error. |
|
I have exactly the same problems with aarch64 on raspi4: just the name of the executable is different esphome on some older version (from january): esphome 1.14.5: esphome 1.15.5: after changing to arm71 it works. Regards |
|
Good to know I am not alone on this... I didn't find the time yet to set up a fresh system on my N2 to reconfirm the issue. |
|
This nasty bugs now sneaked its way into the stable release |
|
Same problem here. |
How I can change it in the ESPHome addon for Home Assistant? |
|
And I can confirm: Same issue here. |
|
for me too
|
|
Thanks a lot for the MeToos. |
|
edited 2020.09.21_12:04 |
|
Hardware: Odroid-N2 UPDATE1: and try to run the docker manually. |
|
Raspberry Pi 4, 5.4.51-v8+ #1333 SMP PREEMPT Mon Aug 10 16:58:35 BST 2020 aarch64 GNU/Linux
|
|
So up to now we only have Odroid N2 and RPi 4 affected. @OttoWinter, any idea what could be different for these devices compared to others? Or is it just these devices being the most popular ones in the community? |
|
It appears we are dealing with a problem with aarch64 platforms (64bit ARM). https://en.wikipedia.org/wiki/AArch64. If you run a 32bit operating system on rpi 4, I bet you don't get this issue. |
|
More information: So I did find where platformio (which esphome uses) stores the compilers: It looks like an issue with platformio / esphome. |
|
I was able to get this working by adding the following to the core block:
These seems to be the last version of the arduino framework that provides the correct compiler. Sigh. This is not a great solution as we are missing out on all the fixes that come with the Arduino code. |
|
Hooray, at least we have a workaround! Thanks for the info. For now, a little outdated version is better than no version. Also we have a starting point for investigations. |
|
Unfortunately for ESP32 I didn't find any version that works. Tried all listed in the docs. |
|
I have a custom Home Assistant instalation in a TVBOX with Armbian Linux (arm64). System: Armbian 20.08 Bullseye (armv7 / raspberrypi3)
This workarround didnt work for me. |
the arch can be changed in boot/config.txt In my installation i changed the line Please check documentation for your installation first, i take no responsibility for you installation! Emmo |
This only applies for Raspberry Pi 4.0. |
|
|
I was only talking about ESPHome for your laptop, RPi is definitively a better/more reliable choice for HAOS. Wrt you question, unless you upgraded HA within HAOS with a recent version there are three years between your current installation and latest version and I would therefore expect a few "tunings" ... difficult to say anyway but I would do/will be required at some point in time anyway. |
|
@jpcornil-git , many thanks, it’s starting to make sense. Although usually when I start to think that I understand something, I find that I really don’t. :-) |
|
I have this issue but as I understand it I'm already on a 64bit OS? Or am I misunderstanding the 64/32bit aspect of this issue? Output from my host RPi 4 is as follows root@rpi4-20210823:/dev# uname -r |
|
Your kernel may be 64b (what uname reports) but userland (application and library binaries) may be 32b and/or 64b. When both match (both 32b or 64b), platformio will behave correctly otherwise (64b kernel and 32b userland) it will expose this issue. You can check a system application to have an indication (32b or 64b application) file /bin/ls |
As an absolute linux noob, I'm not sure what to do with that command to produce useful output to share back to you, can you please clarify what's needed to confirm if I have the same 32/64b issue. Sorry for the hassle and thanks for the assistance. |
After some more reading, and given my RPi4 is a 4GB model I'm fairly confident I'll have a 32bit version of HA. |
I've pressed on with running ESPHome via command line on my windows machine and am hgaving a play with that. See how I go. |
|
Just type that where you typed uname |
|
Hey @UV-PWRD
|
Sorry I should have clarified that I already tried that and I get error "-bash: file: command not found" on Debian 11 |
We are probably using different boards, mine keeps failing the flash, but appears to be trying 48000 then 112000 baud rate, where s the board specifically states use 9600. So far, the only thing that does work is using the adopt sequence from the web portal to make the board ready for adoption, after that I can get to the web front end on the board etc. I did it to "seemingly" flash correctly but after that I cannot see it in HA and I cannot get to the web front end on the board itself. It does appear to be compiling and flashing correctly though because I can see that it has detected the Dallas temp sensor and returns and address for that sensor. |
|
There's something else at play here. When I use the Web Portal and go through the adoption process, clean generic build, the device appears in HA as you'd expect and I can browse the web interface of the device itself. Even if I take that same config and upload it via the esphome command line or by using the ESP Web Portal, from that point forward I can ping the device but it does not appear in HA and I cannot get to the web interface. The only config change I make to the generic adoption config is manually inputting wifi details, which are correct as I can see the device on my router, ping it by IP and device.local Wat am I missing? |
|
Sorry @UV-PWRD, I'm only a newbie myself so its a bit over my head. |
|
@UV-PWRD, file utility is not installed, do the following then: Btw, shouldn't other/generic matters not been discussed in ESPHome Discord rather than in a github issue :-) ? |
outcome as follows /bin/ls: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=9c1a4999161b8b2da681b80d8bf351e40afc40ad, for GNU/Linux 3.7.0, stripped |
|
I'll add i have the device functioning now, but the original error is still prevalent. |
|
You have therefore a 64b userspace (ls is an ELF 64-bit application) running on a 64b kernel (aarch64) -> no mismatches here |
OK thanks, i did think I had done it all as 64b when I started. So the question remains why am I missing this library and how do I add it? |
|
Can you report your error logs (not sure I saw this) ? |
Which log are you after? I get xtensa-lx106-elf-g++: not found when trying to compile configs etc through the ESP Home Dashboard within HA. I worked around that by compiling a config and uploading it via the ESP Home Command line tool, but now the device appears in HA as an integration but not on the ESP Home dashboard itself within HA. |
|
Do you have access to HAOS host cfr. SSH access to the host ? |
|
Yes I think so, My install is stand alone on RPi4 as its own docker image as I needed to run other docker images on the host. Running portainer on the host directly. |
|
-> you can log into esphome container directly with something like and from within container run If this is the case, can you attach log file |
When I do that, I get esphome command not found. When I referenced the ESP Home command line utility previously, I meant locally on my win10 machine. Right now I have 2 distinct issues.
The only time the device appeared in ESP Home Dashboard within HA was when it was put into "Adoption" mode using the ESP Home web portal - that issue is found here - #3193 |
|
You probably ran the command from the host/a different container than esphome one. HAOS is organized as illustrated below and you can ssh at various places (e.g. HA ssh addon gets you into addon_core_ssh, not a host/homeassistant or esphome shell)
You should first connect to the host, list running container and start a shell within esphome one, ex. If you installed esphome manually on top of raspbian, how do you start your esphome docker image (you have e.g. to expose dashboard port/6052 to make it visible outside of its container) ? |
|
Hi. I have the same issue. LOG: |
|
I guess you are also running a 64b kernel on a 32b system (and platformio will install a 64b toochain in that case, incompatible with the installed 32b system) # Check kernel architecture (likely a 64b kernel)
uname -a
# Check toolchain (likely a 32b ELF)
file /config/.esphome/platformio/packages/toolchain-xtensa/bin/xtensa-lx106-elf-g++-> Either patch get_systype as described above/here #1386 (comment) or run esphome prefixed with linux32 ("linux32 esphome compile ..." to fake uname/let it report a 32b kernel) |
and others
Operating environment/Installation (Hass.io/Docker/pip/etc.):
Hass.io on Odroid N2
Hass.io Add-on: ESPHome (beta)
Beta version of ESPHome Hass.io add-on.
Add-on version: 1.15.0b3
You are running the latest version of this add-on.
System: Debian GNU/Linux 9 (stretch) (armv7 / odroid-xu)
Home Assistant Core: 0.113.2
Home Assistant Supervisor: 229
ESP (ESP32/ESP8266, Board/Sonoff):
ESP8266, but irrelevant
ESPHome version (latest production, beta, dev branch)
1.15.0b3 - fails for ESP32 and ESP8266
latest dev - fails for ESP32 and ESP8266
1.14.5 - fails for ESP32, works fine for ESP8266
Affected component:
n/a
Description of problem:
Compilation is giving me
xtensa-lx106-elf-g++: not foundProblem-relevant YAML-configuration entries:
Logs (if applicable):
Additional information and things you've tried:
root@15ef4d2f-esphome-beta:~/.platformio/packages/toolchain-xtensa/bin# ls -la ./xtensa-lx106-elf-g++ -rwxr-xr-x 1 root root 819856 Jul 17 2019 ./xtensa-lx106-elf-g++The text was updated successfully, but these errors were encountered: