I have wasted the better part of 2 days now trying to get HomeAsistant >2024.8 running in a jail.
I've been running 2024.8 for a while, which was set up following this excellent write-up from Brendan Gregg:
blog.brendans-bits.com
my current steps are as follows (on FreeBSD-13.4-RELEASE):
With newer versions, the caveat for numpy from the blog entry no longer applies, as that patch has already made it into the newer versions. However, I've always ran into the same problem where psycog2 is failing to load llvmjit.so upon first startup of homeassistant (right when it tries to migrate the database):
llvmjit.so is provided by databases/postgresql15-server, which is build with LLVM=on.
I found some ancient (2-4 years old) bug reports for numpy, psycopg and sqlalchemy on github and some linux mailing list archives, where they basically all pointed their finger at each other and some ultimately at LLVM15 - at no point that bug was actually addressed or fixed, the bug reports just went stale or were closed because "unrelated patch XY might have fixed this, no time for testing".
I also tried to use Python 3.13 to build all packages (from latest) for the jail and also wanted to build as many of the python-dependencies as are available in ports (latest), instead of going through pip, but this turned out to be an incredible shitshow of a dependency hell with all kinds of ports requiring updates, of which many just won't build because e.g. distutils was abandoned for pep517, which (of course) is not backwards-compatible and some python modules in their latest version still require distutils (or e.g. an old version of py-setuptools) while others will only build with pep517 or a newer version of py-setuptools... So in essence, this was a complete dead-end and waste of time...
As said, there also was some finger-pointing at LLVM15 in one of the github issues (https://github.com/numpy/numpy/issues/23122), so to at least completely exclude LLVM15 from the equation, I built all the packages for that jail on a poudriere buildhost (13.4-RELEASE + latest ports) with
To install the dependencies, pip was always invoked with
I have no idea if pip is either pulling some pre-compiled binaries DESPITE '--no-binary' being set for 'pip install', or even worse, is pulling random stuff (i.e. llvm15) from god-knows-where to build modules. I sincerely hope it isn't the latter, because this would be - apart from being an incredible security nightmare - a master recipe for disaster and all kinds of dependency/versioning hell (like the one I'm seeing...)
Is there someone proficient enough with python and willing to help with this problem? Everything else for homeassistant is upgrading/migrating and starting up just fine according to its logs, so as far as I can see this issue is currently the only thing preventing one to run a current homeassistant versions on FreeBSD...
I've been running 2024.8 for a while, which was set up following this excellent write-up from Brendan Gregg:
FreeBSD Jails: HomeAssistant 2024.7
Installing HomeAssistant 2024.7 into a FreeBSD Jail
blog.brendans-bits.com
my current steps are as follows (on FreeBSD-13.4-RELEASE):
Code:
(as user homeassistant)
~/ $ pyenv install 3.13
~/ $ pyenv global 3.13
~/ $ pyenv init
~/HA-2024.9 $ mkdir HA-2025.1
~/HA-2024.9 $ cd HA-2025.1
~/HA-2024.9 $ python -m venv .
~/HA-2024.9 $ source bin/activate.csh
(HA-2025.1) ~/HA-2025.1 % pip install --upgrade pip
(HA-2025.1) ~/HA-2025.1 % pip install wheel mutagen isal webrtc-noise-gain numpy
(HA-2025.1) ~/HA-2025.1 % pip install homeassistant~=2025.1.4With newer versions, the caveat for numpy from the blog entry no longer applies, as that patch has already made it into the newer versions. However, I've always ran into the same problem where psycog2 is failing to load llvmjit.so upon first startup of homeassistant (right when it tries to migrate the database):
Code:
2025-01-30 13:58:48.456 ERROR (Recorder) [homeassistant.helpers.recorder] Error executing query
Traceback (most recent call last):
File "/usr/home/homeassistant/HA-2025.1/lib/python3.13/site-packages/sqlalchemy/engine/base.py", line 1967, in _exec_single_context
self.dialect.do_execute(
~~~~~~~~~~~~~~~~~~~~~~~^
cursor, str_statement, effective_parameters, context
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
)
^
File "/usr/home/homeassistant/HA-2025.1/lib/python3.13/site-packages/sqlalchemy/engine/default.py", line 941, in do_execute
cursor.execute(statement, parameters)
~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^
psycopg2.errors.InternalError_: could not load library "/usr/local/lib/postgresql/llvmjit.so": /usr/local/llvm15/lib/libLLVM-15.so: Undefined symbol "_ZNSt3__122__libcpp_verbose_abortEPKcz"
CONTEXT: SQL statement "SELECT fk."old_state_id" FROM ONLY "public"."states" fk LEFT OUTER JOIN ONLY "public"."states" pk ON ( pk."state_id" OPERATOR(pg_catalog.=) fk."old_state_id") WHERE pk."state_id" IS NULL AND (fk."old_state_id" IS NOT NULL)"llvmjit.so is provided by databases/postgresql15-server, which is build with LLVM=on.
I found some ancient (2-4 years old) bug reports for numpy, psycopg and sqlalchemy on github and some linux mailing list archives, where they basically all pointed their finger at each other and some ultimately at LLVM15 - at no point that bug was actually addressed or fixed, the bug reports just went stale or were closed because "unrelated patch XY might have fixed this, no time for testing".
I also tried to use Python 3.13 to build all packages (from latest) for the jail and also wanted to build as many of the python-dependencies as are available in ports (latest), instead of going through pip, but this turned out to be an incredible shitshow of a dependency hell with all kinds of ports requiring updates, of which many just won't build because e.g. distutils was abandoned for pep517, which (of course) is not backwards-compatible and some python modules in their latest version still require distutils (or e.g. an old version of py-setuptools) while others will only build with pep517 or a newer version of py-setuptools... So in essence, this was a complete dead-end and waste of time...
As said, there also was some finger-pointing at LLVM15 in one of the github issues (https://github.com/numpy/numpy/issues/23122), so to at least completely exclude LLVM15 from the equation, I built all the packages for that jail on a poudriere buildhost (13.4-RELEASE + latest ports) with
DEFAULT_VERSIONS+=llvm=18 and verified that llvm15 was not built as a dependency for anything. I.e. LLVM15 is in no way available for the jail and all packages are built against LLVM18. I also created a pristine jail and started afresh, only using a copy of the .homeassistant data folder.To install the dependencies, pip was always invoked with
--no-binary :all:, to prevent it from loading anything pre-compiled, but even then psycopg2 is still referring to /usr/local/llvm15/lib/libLLVM-15.so in that error message, which is non-existent and never could have existed in that jail.I have no idea if pip is either pulling some pre-compiled binaries DESPITE '--no-binary' being set for 'pip install', or even worse, is pulling random stuff (i.e. llvm15) from god-knows-where to build modules. I sincerely hope it isn't the latter, because this would be - apart from being an incredible security nightmare - a master recipe for disaster and all kinds of dependency/versioning hell (like the one I'm seeing...)
Is there someone proficient enough with python and willing to help with this problem? Everything else for homeassistant is upgrading/migrating and starting up just fine according to its logs, so as far as I can see this issue is currently the only thing preventing one to run a current homeassistant versions on FreeBSD...
