[Bug] "Unexpected fault address" when opening SQLite db under armv7 #2188
Comments
|
Hello,
--- go.mod.old
+++ go.mod.new
@@ -203,8 +203,8 @@
google.golang.org/genproto/googleapis/rpc v0.0.0-20240903143218-8af14fe29dc1 // indirect
gopkg.in/yaml.v2 v2.4.0 // indirect
gvisor.dev/gvisor v0.0.0-20240722211153-64c016c92987 // indirect
- modernc.org/libc v1.60.1 // indirect
+ modernc.org/libc v1.55.3 // indirect
modernc.org/mathutil v1.6.0 // indirect
modernc.org/memory v1.8.0 // indirect
- modernc.org/sqlite v1.32.0 // indirect
+ modernc.org/sqlite v1.34.1 // indirect
)
|
|
@maxlysenko thank you for your fix, has same issue on my rpi 1b (armv6). Your patch helps me too. |
|
I wonder if this would trigger when doing armv6 builds on other machinery, if that is the case, the github action for just running the build could just compile for all ARCHes so we get feedback when something like that breaks. If someone is up for it, I'll accept a PR doing:
|
kradalby
added
help wanted
|
I've set up the build job in #2270, they all currently build, which means that the dependency might be in sync on master? I dont have a Arm6 board at hand, but I've added so all the binaries are added to the build job, can someone have a look at trying the relevant binary from https://github.com/juanfont/headscale/actions/runs/12160775450?pr=2270 to see if they start on the relevant board? Please dont do in production, running the CLI or something should be fine. |
|
Hello, git clone https://github.com/juanfont/headscale
cd headscale
git checkout v0.23.0
mv go.mod go.mod.old
go mod init github.com/juanfont/headscale
go mod tidyto see which versions of modules go mod will pull automatically. The versions are So for now my workaround is: git clone https://github.com/juanfont/headscale
cd headscale
git checkout v0.23.0
go get modernc.org/[email protected] modernc.org/[email protected]
go mod tidy
go build -v -ldflags="-s -w -X github.com/juanfont/headscale/cmd/headscale/cli.Version=v0.23.0" github.com/juanfont/headscale/cmd/headscale |
|
hmm, I need a way to detect this at build time, we dont have any machinery available to ensure we dont have this regression at runtime. Open for proposals. |
|
modernc.org/libc was upgraded to v1.60.1 in go.mod in #2098. |
|
In general they are just updated to latest, there is no other rational, so I am happy to have them adjusted so it works again, what I am concerned about is me/someone else upgrading it without ensuring the lockstep. Typically I just run a |
|
I've updated my PR with the dependency version you mention, but I am hesitant calling it a "fix" as it doesnt protect for the future. |
|
Tested arm builds from https://github.com/juanfont/headscale/actions/runs/12199297972, they don't crash on database access, they start and work. |
|
Great, the best measure I think I can do for now to ensure we keep this in lock is documentation, I have added a section to our go.mod file in |
Is this a support request?
Is there an existing issue for this?
Current Behavior
I am running headscale on a armv7 SOC (Cubieboard2) in a docker container since quite a while now. After switching to version 0.23 I'm running in an error.
When trying to start headscale using the official headscale/headscale docker image for armv7 the process fails with the following error after trying to open the SQLite db.
Expected Behavior
Opening the SQLite db does not crash the startup process of headscale on armv7.
Steps To Reproduce
Environment
Runtime environment
Anything else?
I built the docker image using debian:slim as a base; it fails with the exact same error.
The text was updated successfully, but these errors were encountered: