edgedb/gel docker container on Mallow board

Technical Support
1

I have the Mallow carrier board

We run multiple applications in docker containers on the boards we use. One of them is edgedb, now called Gel. Edgedb/Gel provide their docker images that we can use (edgedb/edgebd:6, geldata/gel:latest, etc..). So I just pull the image and spin it up using docker compose on the board.

This same process has worked on the Dalhia carrier board and other boards we use but not the Mallow; this is the only one that errors while bootstrapping a database instance, and keeps on restarting the container (as per the yml file).

or GEL_SERVER_PASSWORD_HASH environment variables. ================================================================ Bootstrapping Gel instance on the local volume… INFO 53 - 2025-09-16T16:20:40.045 edb.server: starting Gel server 6.2+3e79124, built on 2025-03-05T16:43Z from revision e97381cfb (2025-03-05T00:05Z) for aarch64-unknown-linux-gnu INFO 53 - 2025-09-16T16:20:40.046 edb.server: instance name: ‘_unknown’ INFO 53 - 2025-09-16T16:20:40.336 edb.server: Using 16 max backend connections based on total memory. ---- Exception occurred: Command ‘[PosixPath(’/usr/lib/aarch64-linux-gnu/gel-server-6/lib/python3.12/site-packages/edb/../../../../bin/pg_config’)]’ returned non-zero exit status 1. ---- 1. subprocess.CalledProcessError: Command ‘[PosixPath(’/usr/lib/aarch64-linux-gnu/gel-server-6/lib/python3.12/site-packages/edb/../../../../bin/pg_config’)]’ returned non-zero exit status 1. ---- Traceback ---- /usr/lib/aarch64-linux-gnu/gel-server-6/bin/gel-server.py, line 7, in > sys.exit(main()) /usr/lib/aarch64-linux-gnu/gel-server-6/lib/python3.12/site-packages/click/core.py, line 1161, in _call_ > return self.main(*args, **kwargs) /usr/lib/aarch64-linux-gnu/gel-server-6/lib/python3.12/site-packages/click/core.py, line 1082, in main > rv = self.invoke(ctx) /usr/lib/aarch64-linux-gnu/gel-server-6/lib/python3.12/site-packages/click/core.py, line 1675, in invoke > rv = super().invoke(ctx) /usr/lib/aarch64-linux-gnu/gel-server-6/lib/python3.12/site-packages/click/core.py, line 1443, in invoke > return ctx.invoke(self.callback, **ctx.params) /usr/lib/aarch64-linux-gnu/gel-server-6/lib/python3.12/site-packages/click/core.py, line 788, in invoke > return __callback(*args, **kwargs) /usr/lib/aarch64-linux-gnu/gel-server-6/lib/python3.12/site-packages/click/decorators.py, line 33, in new_func > return f(get_current_context(), *args, **kwargs) /usr/lib/aarch64-linux-gnu/gel-server-6/lib/python3.12/site-packages/edb/server/main.py, line 872, in main > server_main(**kwargs) /usr/lib/aarch64-linux-gnu/gel-server-6/lib/python3.12/site-packages/edb/server/main.py, line 846, in server_main > asyncio.run(run_server( /usr/lib/aarch64-linux-gnu/gel-server-6/lib/python3.12/asyncio/runners.py, line 194, in run > return runner.run(main) /usr/lib/aarch64-linux-gnu/gel-server-6/lib/python3.12/asyncio/runners.py, line 118, in run > return self._loop.run_until_complete(task) uvloop/loop.pyx, line 1518, in uvloop.loop.Loop.run_until_complete /usr/lib/aarch64-linux-gnu/gel-server-6/lib/python3.12/site-packages/edb/server/main.py, line 638, in run_server > cluster, args = await _get_local_pgcluster( /usr/lib/aarch64-linux-gnu/gel-server-6/lib/python3.12/site-packages/edb/server/main.py, line 366, in _get_local_pgcluster > cluster = await pgcluster.get_local_pg_cluster( /usr/lib/aarch64-linux-gnu/gel-server-6/lib/python3.12/site-packages/edb/server/pgcluster.py, line 983, in get_local_pg_cluster > instance_params = pgparams.get_default_runtime_params( /usr/lib/aarch64-linux-gnu/gel-server-6/lib/python3.12/site-packages/edb/pgsql/params.py, line 140, in get_default_runtime_params > version = buildmeta.get_pg_version() /usr/lib/aarch64-linux-gnu/gel-server-6/lib/python3.12/site-packages/edb/buildmeta.py, line 173, in get_pg_version > pg_config = subprocess.run( /usr/lib/aarch64-linux-gnu/gel-server-6/lib/python3.12/subprocess.py, line 571, in run > raise CalledProcessError(retcode, process.args, subprocess.CalledProcessError: Command ‘[PosixPath(’/usr/lib/aarch64-linux-gnu/gel-server-6/lib/python3.12/site-packages/edb/../../../../bin/pg_config’)]’ returned non-zero exit status 1.

ERROR: Could not complete instance bootsratp

I tired many different images and I tried them in a Dockerfile where I start from the image and install dependencies (like gnupg) that might be causing the issue. didn’t work.

What can I do to fix this?

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.

Did you like my answer? :+1: :-1:

EdgeDB/Gel Container Issue on Mallow Carrier Board

Based on your error message, the EdgeDB/Gel container is failing during bootstrap because it cannot execute the pg_config command properly. This appears to be an architecture-specific issue with the ARM64 build of the EdgeDB container on your Mallow carrier board.

Potential Solutions

1. Container Permissions and Hardware Access

Ensure your Docker container has the necessary permissions. When running containers on Torizon, you may need specific flags for hardware access (1):

# docker run --rm -it -v /var/run/dbus:/var/run/dbus -v /dev:/dev torizon/debian:$CT_TAG_DEBIAN bash

(1)

2. Memory Considerations

The issue might be related to container startup memory spikes. When starting multiple containers simultaneously, there can be significant memory overhead (2). The documentation notes that “when starting multiple containers at once, the memory spike is even greater” and recommends either reworking applications to use fewer containers or creating start dependencies between containers (2).

3. Architecture Compatibility

The error suggests an ARM64 architecture issue. This is similar to the “no matching manifest for linux/arm64/v8” errors reported in the community (3). Ensure the EdgeDB/Gel image you’re using specifically supports ARM64 architecture.

4. Container Resource Management

Consider implementing container start dependencies to avoid memory spikes during simultaneous container launches (2). You can create dependencies that make containers launch sequentially rather than all at once.

Troubleshooting Steps

  1. Check Container Architecture: Verify that the EdgeDB/Gel image supports ARM64 architecture
  2. Test with Single Container: Try running only the EdgeDB container initially to isolate the issue
  3. Monitor Memory Usage: Check if memory constraints are causing the bootstrap failure
  4. Review Container Logs: Examine detailed logs during the pg_config execution failure

Since this works on your Dahlia carrier board but not on Mallow, there might be specific hardware or configuration differences affecting container execution. The PostgreSQL configuration tool (pg_config) failure suggests either missing dependencies or architecture incompatibility in the container image.

Best regards, Toradex AI Assistant.

3

Hey @Batool,

From this is looks like an error with binary called pg_config, which seems to be about the versioning of postgreSQL. So maybe you have a mismatch here. Can you also validate the arciteccture that you are pulling? arm64 vs amd64?

A carrier board should make too much of a difference here, but can you give me the output of sudo tdx-info while ssh into your board? And also which verdin SoM are you using?

5

Hi @eric.tx

– The SoM: Verdin iMX8M Plus (for both the Dalhia and Mallow)

– For the architecture, I pull the arm one. I run docker pull --platform=linux/arm64 edgedb/edgedb:6. My host machine is amd64, I will get a exec ./bst_bridge: exec format error if I don’t do the –platform=linux/arm64 , but since I do it works and edgedb/gel tries to bootstrap.

A while back, my coworker was using his Mac (arm arch) to do the same, and edgedb was also failing at bootstrapping, only on the Mallow. That same day he got it easily working on the Dalhia.

–This is the output of tdx-info:

Software summary

Bootloader: U-Boot
Kernel version: 5.4.193-5.7.2+git.b60d3160fd04 #1-TorizonCore SMP PREEMPT Fri Dec 23 15:47:24 UTC 2022
Kernel command line: root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/d059ab4068a8626b311cab9118926b3f41ed3a2a6874c501225e9e8a1ef84f88/0
Distro name: NAME=“TorizonCore”
Distro version: VERSION_ID=5.7.2-build.20
Distro variant: VARIANT=“Docker”
Hostname: verdin-imx8mp-15502116

Hardware info

HW model: Toradex Verdin iMX8M Plus WB on Verdin Development Board
Toradex version: 0058 V1.1B
Serial number: 15502116
Processor arch: aarch64
Available block devices:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
mmcblk2 179:0 0 29.1G 0 disk
mmcblk2p1 179:1 0 29.1G 0 part /sysroot
mmcblk2boot0 179:32 0 4M 1 disk
mmcblk2boot1 179:64 0 4M 1 disk

6

Also I just checked Postgres version in both the container on the Dalhia and the one on the Mallow, and they match (postgres (PostgreSQL) 17.0)

7

Hey @Batool,

I see from your hardware output, the device still has the Verdin development board as the default carrier board device tree. Are you able to switch this to the mallow? If it’s just the carrier board that is making the difference, maybe this correction will fix it.

-Eric