Skip to content

Is There an OpenWRT-Specific Gotify Server File? (Failed Installation on 24.10.x) #861

Open
Open
Is There an OpenWRT-Specific Gotify Server File? (Failed Installation on 24.10.x)#861
Assignees
eternal-flame-AD

Description

@pinoren
pinoren
opened on Oct 14, 2025

I want to install, configure, and run Gotify Server on the OpenWRT 24.10.x system.
However, I have tried many different methods but all failed.
Is there a server-side file specifically designed for OpenWRT?

Thank you very much!

Activity

  1. eternal-flame-AD commented on Oct 14, 2025

    @eternal-flame-AD
    eternal-flame-AD
    on Oct 14, 2025
    Member

    Hi, it's probably the libc issue.

    It will be fixed by gotify/build#18 , I will prioritize that this week.

    In the meantime just to be sure can you send your architecture (uname -m)?

  2. eternal-flame-AD
    self-assigned this
    on Oct 14, 2025

  3. pinoren commented on Oct 14, 2025

    @pinoren
    pinoren
    on Oct 14, 2025
    Author

    我收到了中文名称的邮件，所以我不知道是否用中文回复也可以。。。

    型号 Raspberry Pi 3 Model B Rev 1.2
    架构 ARMv8 Processor rev 4
    目标平台 bcm27xx/bcm2710
    固件版本 OpenWrt 24.10.3 r28872-daca7c049b / LuCI openwrt-24.10 branch 25.284.65624~de7651f
    内核版本 6.6.104

    我测试了目前可以下载的最新/之前的不同版本，并且求助了AI，让他指导我进行错误排查，最后都没有成功。

    The above Chinese content is irrelevant to the following.

    Since I sought help from AI during the configuration process, I have now asked AI to summarize the help-seeking process into a bug report. Would you please check if it is useful?

    Bug Report: Gotify Server Deployment Issues on OpenWrt (Raspberry Pi 3B)
    Device and System Information
    • Device Model: Raspberry Pi 3 Model B Rev 1.2 (Hardware: ARMv8 Processor rev 4, Platform: bcm27xx/bcm2710)
    • System Version: OpenWrt 24.10.2 r28739-d9340319c6 / LuCI openwrt-24.10 branch 25.217.58566~00c4c12
    • Tested Gotify Versions: All versions from v2.4.0 to v2.7.2
    • Tested Binary Types: Three official architecture variants from the Releases page: gotify-linux-arm-7, gotify-linux-arm64, and gotify-linux-riscv64
    • General Setup: All packages were fully extracted, binaries were moved to /usr/bin, and full execution permissions were applied using chmod 777
    Encountered Errors and Troubleshooting Steps

    1. All gotify-linux-arm64 versions fail to run
      • Error Message: -ash: gotify-linux-arm64: not found
      • Details: When testing all arm64 packages (v2.4.0 to v2.7.2), the extracted binaries (some renamed to gotify-linux-arm64) were correctly placed in /usr/bin with proper permissions. However, running either gotify-linux-arm64 or the full path /usr/bin/gotify-linux-arm64 consistently returned the "not found" error. The system reports armv7l (32-bit environment) via uname -m.
      • Troubleshooting: Repeated tests across all arm64 versions with consistent deployment steps (correct file placement and permissions) yielded the same error.
    2. All gotify-linux-arm-7 versions throw execution errors
      • Error Message: /usr/bin/gotify-linux-arm-7: line 17: syntax error: unexpected word (expecting ")"
      • Details: Testing all gotify-linux-arm-7 packages (v2.4.0 to v2.7.2) resulted in the above syntax error upon execution. This suggests the files are either invalid binaries, incorrectly formatted, or incompatible with the ARM architecture of the device.
      • Troubleshooting: Multiple re-downloads from the official Releases page (to ensure file integrity) and repeated deployment attempts did not resolve the error.
    3. All gotify-linux-riscv64 versions fail to run
      • Error Message: -ash: gotify-linux-riscv64: not found
      • Details: When testing all riscv64 packages (v2.4.0 to v2.7.2) with standard deployment steps, the "not found" error occurred. This is likely due to architecture incompatibility, as the device uses ARM while riscv64 targets RISC-V.
      • Troubleshooting: Testing of riscv64 packages was discontinued after confirming architecture mismatch, with focus shifted to ARM-based variants.

  4. eternal-flame-AD commented on Oct 14, 2025

    @eternal-flame-AD
    eternal-flame-AD
    on Oct 14, 2025
    Member

    All gotify-linux-arm-7 versions throw execution errors
    • Error Message: /usr/bin/gotify-linux-arm-7: line 17: syntax error: unexpected word (expecting ")"

    This doesn't look normal, have you checked the file size (and checksum) match with the advertised values on GitHub release?

    If possible, check the output of ldd <gotify_exec> and file <gotify_exec>

  5. pinoren commented on Oct 14, 2025

    @pinoren
    pinoren
    on Oct 14, 2025
    Author

    Yes, I have repeatedly downloaded and verified them. Moreover, I downloaded and tested all versions ranging from 2.4.0 to 2.7.2, and got the same result every time.
    I have deleted the running environment. I will find time to restore it and run a test tomorrow.

  6. eternal-flame-AD commented on Oct 14, 2025

    @eternal-flame-AD
    eternal-flame-AD
    on Oct 14, 2025
    Member

    If you have a native Go toolchain (on your router itself)

    You can build your own release with:

    CGO_ENABLED=0 go build -mod=readonly -a  -ldflags="-s -w -X main.Mode=prod"

    This should be the quickest way to resolve the issue.

  7. pinoren commented on Oct 15, 2025

    @pinoren
    pinoren
    on Oct 15, 2025
    Author

    After I ran the test, the results are as follows:

    root@Router:/bin# gotify-linux-arm-7
/bin/gotify-linux-arm-7: line 1: syntax error: unexpected word (expecting ")")

root@Router:/bin# ldd gotify-linux-arm-7
ldd: gotify-linux-arm-7: Not a valid dynamic program

root@Router:/bin# file gotify-linux-arm-7
-ash: file: not found

    ==================================================

    root@Router:~# ls
server-2.7.3         server-2.7.3.tar.gz
root@Router:~# cd server-2.7.3
root@Router:~/server-2.7.3# CGO_ENABLED=0 go build -mod=readonl
y -a -ldflags="-s -w -X main.Mode=prod"
go: downloading go1.25.1 (linux/arm64)
go: downloading github.com/gin-gonic/gin v1.11.0
go: downloading github.com/jinzhu/configor v1.2.2
go: downloading github.com/gin-contrib/cors v1.7.6
go: downloading github.com/gotify/location v0.0.0-20170722210143-03bc4ad20437
go: downloading github.com/jinzhu/gorm v1.9.16
go: downloading golang.org/x/crypto v0.42.0
go: downloading github.com/h2non/filetype v1.1.3
go: downloading gopkg.in/yaml.v3 v3.0.1
go: downloading github.com/gorilla/websocket v1.5.3
go: downloading github.com/go-playground/validator/v10 v10.27.0
go: downloading github.com/gin-contrib/gzip v1.2.3
go: downloading github.com/BurntSushi/toml v1.2.0
go: downloading github.com/gin-contrib/sse v1.1.0
go: downloading github.com/mattn/go-isatty v0.0.20
go: downloading github.com/quic-go/quic-go v0.54.0
go: downloading golang.org/x/net v0.43.0
go: downloading github.com/lib/pq v1.10.0
go: downloading github.com/jinzhu/inflection v1.0.0
go: downloading github.com/mattn/go-sqlite3 v1.14.7
go: downloading github.com/go-sql-driver/mysql v1.5.0
go: downloading github.com/goccy/go-yaml v1.18.0
go: downloading github.com/pelletier/go-toml/v2 v2.2.4
go: downloading github.com/ugorji/go/codec v1.3.0
go: downloading google.golang.org/protobuf v1.36.9
go: downloading github.com/gotify/plugin-api v1.0.0
go: downloading github.com/gabriel-vasile/mimetype v1.4.9
go: downloading github.com/go-playground/universal-translator v0.18.1
go: downloading github.com/leodido/go-urn v1.4.0
go: downloading golang.org/x/text v0.29.0
go: downloading golang.org/x/sys v0.36.0
go: downloading github.com/quic-go/qpack v0.5.1
go: downloading github.com/go-playground/locales v0.14.1
ui/serve.go:15:12: pattern build/*: no matching files found
root@Router:~/server-2.7.3#
opkg update
(download.....)
opkg updateroot@Router:/bin# opkg install nodejs
Unknown package 'nodejs'.
Collected errors:
 * opkg_install_cmd: Cannot install package nodejs.
root@Router:/bin# opkg search nodejs
root@Router:/bin#

  8. eternal-flame-AD commented on Oct 15, 2025

    @eternal-flame-AD
    eternal-flame-AD
    on Oct 15, 2025
    Member

    I don't have too much experience with OpenWrt, played with it a long time ago and it was a pretty bare bones environment.

    There is something inconsistent with your report ..Your previous comment mentioned:

    The system reports armv7l (32-bit environment) via uname -m.

    But this time Go says it's an arm64

    go: downloading go1.25.1 (linux/arm64)

    I believe it should be arm64 not armv7, but regardless I don't believe the current releases will work: not found likely means the dynamic loader being missing or failed to find the dynamically linked libraries. A quick way to check the dynamic loader problem is check your /lib/lib* or /usr/lib/lib*, if they are .a files you got a statically linked system and the release builds will not work.

    Your self build seems mostly successful except the UI has not been built, I searched online it seems like nodejs have the same issue with platform dependencies on OpenWRT, if you have a development machine with a fully fledged OS you may be able to build the frontend there (cd ui && yarn build) then cross compile:

    CGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build -mod=readonly -a  -ldflags="-s -w -X main.Mode=prod"

    PS: I can read Chinese but the other maintainers likely not, if you have trouble communicating in English you are welcome to use Chinese, but the preferred language is still English just to keep the environment inclusive.

  9. pinoren commented on Oct 16, 2025

    @pinoren
    pinoren
    on Oct 16, 2025
    Author

    After testing, it turns out the system is indeed arm64, and the error is caused by the dynamic link library... I will try compiling a statically linked build. Thank you so much... I wonder if the program itself will be changed to a statically linked build in the future as you suggested...

    Thank you again! I will keep an eye on the release of the statically linked build.

    root@SideRouter:~# uname -m
aarch64
root@SideRouter:~#
arm64

root@Router:/bin# ldd gotify-linux-arm64
        /lib/ld-linux-aarch64.so.1 (0x7fb8d10000)
        libc.so.6 => /lib/ld-linux-aarch64.so.1 (0x7fb8d10000)
Error relocating gotify-linux-arm64: fcntl64: symbol not found

root@Router:/bin# file gotify-linux-arm64
-ash: file: not found

root@Router:/bin# file gotify-linux-arm64
gotify-linux-arm64: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, Go BuildID=rrHAXWk5_NgIrHhzQgbJ/vHGFXGiU_U5Yd0SaJ92M/Zfy8zCheZzHggz2VAgcO/DY3YRndyXMDJJbeapSzt, BuildID[sha1]=facfeb59f2fcb4a4d20627b3e39e5ae7998acd6f, stripped
root@Router:/bin#

  10. pinoren commented on Oct 16, 2025

    @pinoren
    pinoren
    on Oct 16, 2025
    Author

    oh no。。。

    root@Router:/bin# gotify-server --config /etc/gotify/config.yml
Starting Gotify version unknown@unknown
panic: Binary was compiled with 'CGO_ENABLED=0', go-sqlite3 requires cgo to work. This is a stub

goroutine 1 [running]:
main.main()
        D:/project/dev/testserver/app.go:44 +0x294


    root@Router:~/server-2.7.3# CGO_ENABLED=1 GOOS=linux GOARCH=arm
64 go build -mod=readonly -a -ldflags="-s -w -X main.Mode=prod"
# runtime/cgo
cgo: C compiler "gcc" not found: exec: "gcc": executable file not found in $PATH

  11. pinoren commented on Oct 16, 2025

    @pinoren
    pinoren
    on Oct 16, 2025
    Author
    root@Router:~/server-2.7.3# CGO_ENABLED=1 GOOS=linux GOARCH=arm
64 go build -mod=readonly -a -ldflags="-s -w -X main.Mode=prod"
# runtime/cgo
cgo: C compiler "gcc" not found: exec: "gcc": executable file not found in $PATH
root@Router:~/server-2.7.3# CGO_ENABLED=0 GOOS=linux GOARCH=arm
64 go build -mod=readonly -a -ldflags="-s -w -X main.Mode=prod"
^C^C
root@Router:~/server-2.7.3# CGO_ENABLED=1 GOOS=linux GOARCH=arm
64 go build -mod=readonly -a -ldflags="-s -w -X main.Mode=prod"
# runtime/cgo
cgo: C compiler "gcc" not found: exec: "gcc": executable file not found in $PATH

^C
root@Router:~/server-2.7.3# cls
-ash: cls: not found
root@Router:~/server-2.7.3# CGO_ENABLED=1 GOOS=linux GOARCH=arm
64 go build -mod=readonly -a -ldflags="-s -w -X main.Mode=prod
> "

^C
root@Router:~/server-2.7.3# CGO_ENABLED=1 GOOS=linux GOARCH=arm
64 go build -mod=readonly -a -ldflags="-s -w -X main.Mode=prod"
# text/template/parse
compile: writing output: write $WORK/b240/_pkg_.a: no space left on device
google.golang.org/protobuf/internal/pragma: write /tmp/go-build2314486411/b249/importcfg: no space left on device
# crypto/tls
compile: writing output: write $WORK/b112/_pkg_.a: no space left on device
golang.org/x/net/http2/hpack: write /tmp/go-build2314486411/b262/importcfg: no space left on device
# google.golang.org/protobuf/internal/detrand
compile: writing output: write $WORK/b245/_pkg_.a: no space left on device
github.com/quic-go/quic-go/quicvarint: write /tmp/go-build2314486411/b267/importcfg: no space left on device
golang.org/x/crypto/internal/poly1305: write /tmp/go-build2314486411/b277/importcfg: no space left on device
golang.org/x/crypto/chacha20: write /tmp/go-build2314486411/b274/importcfg: no space left on device
golang.org/x/crypto/hkdf: write /tmp/go-build2314486411/b278/importcfg: no space left on device
golang.org/x/sys/unix: write /tmp/go-build2314486411/b259/importcfg: no space left on device
github.com/quic-go/quic-go/internal/utils/linkedlist: write /tmp/go-build2314486411/b279/importcfg: no space left on device
golang.org/x/net/bpf: write /tmp/go-build2314486411/b282/importcfg: no space left on device
golang.org/x/text/transform: write /tmp/go-build2314486411/b289/importcfg: no space left on device
github.com/BurntSushi/toml/internal: write /tmp/go-build2314486411/b301/importcfg: no space left on device
io/ioutil: write /tmp/go-build2314486411/b302/importcfg: no space left on device
log/slog/internal/buffer: write /tmp/go-build2314486411/b294/importcfg: no space left on device
golang.org/x/text/unicode/bidi: write /tmp/go-build2314486411/b290/importcfg: no space left on device
golang.org/x/crypto/blowfish: write /tmp/go-build2314486411/b307/importcfg: no space left on device
database/sql/driver: write /tmp/go-build2314486411/b311/importcfg: no space left on device
gopkg.in/yaml.v3: write /tmp/go-build2314486411/b303/importcfg: no space left on device
github.com/gotify/server/v2/model: write /tmp/go-build2314486411/b308/importcfg: no space left on device
github.com/lib/pq/scram: write /tmp/go-build2314486411/b320/importcfg: no space left on device
github.com/jinzhu/inflection: write /tmp/go-build2314486411/b312/importcfg: no space left on device
go/scanner: write /tmp/go-build2314486411/b314/importcfg: no space left on device
github.com/h2non/filetype/matchers/isobmff: write /tmp/go-build2314486411/b336/importcfg: no space left on device
github.com/h2non/filetype/types: write /tmp/go-build2314486411/b337/importcfg: no space left on device
# os/user
cgo: write /tmp/cgo-gcc-input-2020550813.c: no space left on device
# plugin
cgo: write /tmp/cgo-gcc-input-2616444895.c: no space left on device
embed: write /tmp/go-build2314486411/b341/importcfg: no space left on device
os/signal: write /tmp/go-build2314486411/b348/importcfg: no space left on device
root@Router:~/server-2.7.3#

  12. eternal-flame-AD commented on Oct 16, 2025

    @eternal-flame-AD
    eternal-flame-AD
    on Oct 16, 2025
    Member

    It seems like openwrt does support docker? That should work around the libc issue for now. Since you have a raspberry pi I assume storage shouldn't be a problem?

    https://openwrt.org/docs/guide-user/virtualization/docker_host

  13. pinoren commented on Oct 17, 2025

    @pinoren
    pinoren
    on Oct 17, 2025
    Author

    It seems like openwrt does support docker? That should work around the libc issue for now. Since you have a raspberry pi I assume storage shouldn't be a problem?

    https://openwrt.org/docs/guide-user/virtualization/docker_host

    Thank you very much. I am currently using Windows Server 2008 R2 with the 2.4.0 Server (version of Gotify). I will continue to wait and see if a build compatible with OpenWRT is released...

  14. christaikobo commented on Dec 28, 2025

    @christaikobo
    christaikobo
    on Dec 28, 2025

    Try this CGO_ENABLED=1 GOOS=linux GOARCH=arm64 CC=musl-gcc CGO_LDFLAGS="-static"

    I'm pulling something out of thin air so don't get your hopes too high, but it was a problem for me when I tried to compile a different program for openwrt, they use musl as opposed to normal libc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions