Environment:
- ZimaOS version: 1.7.1 (build 2026-08-05T09:00:34Z)
- zimaos-app-management version: v0.4.5, commit 7f9e33e92f0366efc0d1087f004c52ee6176b4f1, build date 2026-08-21T07:06:56Z
- Platform: x86_64
- Installed apps: Pi-hole, PhotoPrism (Big Bear repo), Plex, Portainer, Actual Budget
Summary:
zimaos-app-management entered a permanent crash loop (restart counter climbed past 800), causing the ZimaOS Dashboard to show no apps at all. The service panics on every single startup/catalog-rebuild attempt, before it's able to serve any HTTP request.
Panic:
panic: interface conversion: interface {} is nil, not string
golang.org/x/sync/singleflight.newPanicError(...)
panic(...)
github.com/IceWhaleTech/ZimaOS-AppManagement/service.GetUserLanguage()
service/image.go:416 +0x317
github.com/IceWhaleTech/ZimaOS-AppManagement/service.normalizeStoreInfoExtension(...)
service/compose_app.go:225 +0x397
github.com/IceWhaleTech/ZimaOS-AppManagement/service.(*ComposeApp).StoreInfo(...)
service/compose_app.go:148 +0x5f
github.com/IceWhaleTech/ZimaOS-AppManagement/service.newComposeAppFromYAML(...)
service/compose_app.go:1573 +0x3d6
github.com/IceWhaleTech/ZimaOS-AppManagement/service.NewComposeAppFromYAML(...)
service/compose_app.go:1484
github.com/IceWhaleTech/ZimaOS-AppManagement/service.buildCatalog.func1()
service/appstore.go:741 +0x378
github.com/IceWhaleTech/ZimaOS-AppManagement/service.buildCatalog(...)
service/appstore.go:699 +0x5d
github.com/IceWhaleTech/ZimaOS-AppManagement/service.(*appStore).updateCatalogLocked(...)
service/appstore.go:218 +0x545
github.com/IceWhaleTech/ZimaOS-AppManagement/service.(*appStore).UpdateCatalog(...)
service/appstore.go:113 +0x74
github.com/IceWhaleTech/ZimaOS-AppManagement/service.(*AppStoreManagement).UpdateCatalog(...)
service/appstore_management.go:631 +0x83
main.main.func3()
main.go:224 +0x33
What triggers it:
buildCatalog runs on every service startup as a background goroutine (main.main.func3, no HTTP request context). It calls GetUserLanguage() while normalizing the x-casaos extension for every app in the combined catalog (installed + both remote store repos). GetUserLanguage() panics on a nil→string interface conversion, unconditionally — it fails identically regardless of which app is currently being processed, and it began failing on every single run starting at a specific point in time in an already-long-running, previously-healthy process (consistent with a periodic scheduled catalog rebuild, not a fresh deploy).
Diagnostic steps taken, and ruled out:
- ❌ Not caused by a bad locally-installed app config — checked every installed app's compose file; found and fixed one unrelated pre-existing typo (app_id: instead of id: in Plex's x-casaos block), but the crash persisted identically afterward.
- ❌ Not a corrupted local catalog cache — moved aside ~/.icewhale/appstore entirely to force a fully fresh rebuild; identical panic.
- ❌ Not stale in-memory/process state — systemctl restart and a full host reboot both reproduce the identical panic within ~1 second of every start.
- ❌ Not binary corruption — reinstalled the OS image via zimaos -u (same version, fresh write) and rebooted; identical panic (this also revealed that zimaos-app-management isn't refreshed by an OS-level reinstall — it's a separately-shipped static binary in /usr/bin).
- ❌ Not a malformed entry in either remote catalog — programmatically parsed and validated every x-casaos block across both the official CasaOS-AppStore repo (178 apps) and the Big Bear community repo (440 apps) for missing id/malformed title fields; found none.
Given it's 100% reproducible on every attempt regardless of which app or catalog source is involved, this looks like a genuine logic defect in GetUserLanguage() (or its caller context) rather than a data/content issue — possibly an assumption that a request-scoped value is always present, which doesn't hold for the startup/scheduled background invocation path.
Impact: Complete loss of the Dashboard's installed-apps view. Docker containers themselves are unaffected and keep running — Portainer can be used as a workaround to manage them in the meantime.
Request: Please advise on a fix or a way to force-reinstall/downgrade just the zimaos-app-management component, since it isn't touched by a standard OS reinstall/reflash.
Environment:
Summary:
zimaos-app-management entered a permanent crash loop (restart counter climbed past 800), causing the ZimaOS Dashboard to show no apps at all. The service panics on every single startup/catalog-rebuild attempt, before it's able to serve any HTTP request.
Panic:
panic: interface conversion: interface {} is nil, not string
golang.org/x/sync/singleflight.newPanicError(...)
panic(...)
github.com/IceWhaleTech/ZimaOS-AppManagement/service.GetUserLanguage()
service/image.go:416 +0x317
github.com/IceWhaleTech/ZimaOS-AppManagement/service.normalizeStoreInfoExtension(...)
service/compose_app.go:225 +0x397
github.com/IceWhaleTech/ZimaOS-AppManagement/service.(*ComposeApp).StoreInfo(...)
service/compose_app.go:148 +0x5f
github.com/IceWhaleTech/ZimaOS-AppManagement/service.newComposeAppFromYAML(...)
service/compose_app.go:1573 +0x3d6
github.com/IceWhaleTech/ZimaOS-AppManagement/service.NewComposeAppFromYAML(...)
service/compose_app.go:1484
github.com/IceWhaleTech/ZimaOS-AppManagement/service.buildCatalog.func1()
service/appstore.go:741 +0x378
github.com/IceWhaleTech/ZimaOS-AppManagement/service.buildCatalog(...)
service/appstore.go:699 +0x5d
github.com/IceWhaleTech/ZimaOS-AppManagement/service.(*appStore).updateCatalogLocked(...)
service/appstore.go:218 +0x545
github.com/IceWhaleTech/ZimaOS-AppManagement/service.(*appStore).UpdateCatalog(...)
service/appstore.go:113 +0x74
github.com/IceWhaleTech/ZimaOS-AppManagement/service.(*AppStoreManagement).UpdateCatalog(...)
service/appstore_management.go:631 +0x83
main.main.func3()
main.go:224 +0x33
What triggers it:
buildCatalog runs on every service startup as a background goroutine (main.main.func3, no HTTP request context). It calls GetUserLanguage() while normalizing the x-casaos extension for every app in the combined catalog (installed + both remote store repos). GetUserLanguage() panics on a nil→string interface conversion, unconditionally — it fails identically regardless of which app is currently being processed, and it began failing on every single run starting at a specific point in time in an already-long-running, previously-healthy process (consistent with a periodic scheduled catalog rebuild, not a fresh deploy).
Diagnostic steps taken, and ruled out:
Given it's 100% reproducible on every attempt regardless of which app or catalog source is involved, this looks like a genuine logic defect in GetUserLanguage() (or its caller context) rather than a data/content issue — possibly an assumption that a request-scoped value is always present, which doesn't hold for the startup/scheduled background invocation path.
Impact: Complete loss of the Dashboard's installed-apps view. Docker containers themselves are unaffected and keep running — Portainer can be used as a workaround to manage them in the meantime.
Request: Please advise on a fix or a way to force-reinstall/downgrade just the zimaos-app-management component, since it isn't touched by a standard OS reinstall/reflash.