democratic-csi: error loading shared libraries: libatomic.so.1

Hi there!

I’m trying to get this going on a RPi4 k3s cluster running Raspbian / RPi OS.

So far I’ve gotten over a few hurdles including swapping some of the container images for arm64 compatible ones and it seems only the democraticcsi/democratic-csi images are now having trouble running, this one is already arm64 compatible so I haven’t changed its reference.

Each of them (one on each node plus the controller instance), is crashing with the same error:

│ node: error while loading shared libraries: libatomic.so.1: cannot open shared object file: No such file or directory │

The underlying OS does have libatomic1 installed already, at wherever Raspbian/RPi OS installs it, though I’m not sure that’s relevant since maybe it tries to reference the container filesystem for it.

Happy to provide any other info that can help, I suppose it’s possible it’s just a bad error message and the problem lies elsewhere!

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 27 (14 by maintainers)

Commits related to this issue

change order of build platforms to maybe resolve some crazy edge cases see #51 — committed to democratic-csi/democratic-csi by travisghansen 3 years ago

Most upvoted comments

Wow bonkers stuff for sure!

travisghansen on Jan 15, 2021

That’s a cool little cluster man!

Thanks! It’s working nicely for a homelab so far!

So only the arm64/v8 image works? Am I understanding that correctly?

Yep. The v7 one throws the libatomic error and the amd64 one throws exec format error.

I will do what I can to understand the manifests better but it seems clear to me that the problem is with the gcr images as well. I don’t recall if I installed this on my v7 cluster so I’ll try that but I’m certain it deployed with 0 modifications to work on my arm64 cluster (based on ubuntu 64 bit).

Oh yeah I totally agree that GCR isn’t handling this setup well at all, but at least I can use the raspbernetes images as an alternative there.

I would guess that you had no trouble on your ubuntu 64-bit because it’s true 64-bit instead of a 64-bit kernel with a 32-bit rootfs so it always requested arm64 instead of arm/v8 like mine.

When actual Raspbian 64-bit leaves beta I’ll likely switch to it then, but in the meantime it’s good to know the problem is workaroundable! It’d be cool to get Dockerhub handling it a little better though so I don’t have to manually change the SHA each revision.

eamonryan on Jan 15, 2021