Hi CubeCoders Support,
We are running AMP in a Kubernetes environment (hosted on Ubuntu nodes). We recently reverted from an unofficial image back to the official cubecoders/amp:latest, but we are now stuck in a state where we cannot update our instances due to a critical version mismatch and an End-of-Life container OS.
System Status:
Application Version: 2.6.4.2 (Phobos) - Correct
Tools Version (ampinstmgr): 1.9.5.2 (Obsolete) - The Issue
Container OS: Debian GNU/Linux 10 (buster) - EOL / Repos dead
The Problem: We are receiving the “Outdated System Tools” warning. We cannot perform updates because the ampinstmgrbinary (v1.9.5.2) residing in the persistent volume is too old to execute current commands (fails with FileNotFoundException).
Why we cannot follow the standard guide: We have read the “How to update AMP” guide by @IceOfWraith, which suggests running getamp update or apt upgrade ampinstmgr. This is impossible in our current state because:
The container is identifying as Debian 10 (Buster).
Debian 10 is End-of-Life. Running apt-get update inside the container returns 404 Not Found for all repositories.
Therefore, we cannot install wget or update ampinstmgr via the package manager inside the container.
Troubleshooting attempted:
We have tried redeploying the pod using specific tags (:Release, :2.6.5.0), but the pod continues to load the old ampinstmgr binary from the persistent data volume (.ampdata).
We cannot overwrite this binary manually via apt because the container OS repositories are offline.
Request: Since the container OS is EOL and package managers are broken, how can we force the container to discard the old 1.9.5.2 binary in the persistent volume and replace it with the current version included in the cubecoders/amp:latest image?
We need a method to manually inject/overwrite the correct ampinstmgr binary to restore functionality.
Full System Info:
OS: Linux (Debian GNU/Linux 10)
Application Version: 2.6.4.2
Tools Version: 1.9.5.2
InstanceID: …dba8c
Update regarding troubleshooting: We attempted to manually inject a fresh ampinstmgr binary from a clean cubecoders/amp:latest pod into our running instance. However, executing upgradeall resulted in a FileNotFoundException: Couldn’t find the specified application: kill.
Subject:
Kubernetes: Tools Version stuck on 1.9.5.2 inside EOL Debian 10 Container - Cannot update
Message:
Hi CubeCoders Support,
We are running AMP in a Kubernetes environment (hosted on Ubuntu nodes). We recently reverted from an unofficial image back to the official cubecoders/amp:latest, but we are now stuck in a state where we cannot update our instances due to a critical version mismatch and an End-of-Life container OS.
System Status:
Application Version: 2.6.4.2 (Phobos) - Correct
Tools Version (ampinstmgr): 1.9.5.2 (Obsolete) - The Issue
Container OS: Debian GNU/Linux 10 (buster) - EOL / Repos dead
The Problem: We are receiving the “Outdated System Tools” warning. We cannot perform updates because the ampinstmgrbinary (v1.9.5.2) residing in the persistent volume is too old to execute current commands (fails with FileNotFoundException).
Why we cannot follow the standard guide: We have read the “How to update AMP” guide by IceOfWraith, which suggests running getamp update or apt upgrade ampinstmgr. This is impossible in our current state because:
The container is identifying as Debian 10 (Buster).
Debian 10 is End-of-Life. Running apt-get update inside the container returns 404 Not Found for all repositories.
Therefore, we cannot install wget or update ampinstmgr via the package manager inside the container.
Troubleshooting attempted:
We have tried redeploying the pod using specific tags (:Release, :2.6.5.0), but the pod continues to load the old ampinstmgr binary from the persistent data volume (.ampdata).
We cannot overwrite this binary manually via apt because the container OS repositories are offline.
Request: Since the container OS is EOL and package managers are broken, how can we force the container to discard the old 1.9.5.2 binary in the persistent volume and replace it with the current version included in the cubecoders/amp:latest image?
We need a method to manually inject/overwrite the correct ampinstmgr binary to restore functionality.
Full System Info:
OS: Linux (Debian GNU/Linux 10)
Application Version: 2.6.4.2
Tools Version: 1.9.5.2
InstanceID: …dba8c
Update regarding troubleshooting: We attempted to manually inject a fresh ampinstmgr binary from a clean cubecoders/amp:latest pod into our running instance. However, executing upgradeall resulted in a FileNotFoundException: Couldn’t find the specified application: kill.
Subject:
Kubernetes: Tools Version stuck on 1.9.5.2 inside EOL Debian 10 Container - Cannot update
Message:
Hi CubeCoders Support,
We are running AMP in a Kubernetes environment (hosted on Ubuntu nodes). We recently reverted from an unofficial image back to the official cubecoders/amp:latest, but we are now stuck in a state where we cannot update our instances due to a critical version mismatch and an End-of-Life container OS.
System Status:
Application Version: 2.6.4.2 (Phobos) - Correct
Tools Version (ampinstmgr): 1.9.5.2 (Obsolete) - The Issue
Container OS: Debian GNU/Linux 10 (buster) - EOL / Repos dead
The Problem: We are receiving the “Outdated System Tools” warning. We cannot perform updates because the ampinstmgrbinary (v1.9.5.2) residing in the persistent volume is too old to execute current commands (fails with FileNotFoundException).
Why we cannot follow the standard guide: We have read the “How to update AMP” guide by IceOfWraith, which suggests running getamp update or apt upgrade ampinstmgr. This is impossible in our current state because:
The container is identifying as Debian 10 (Buster).
Debian 10 is End-of-Life. Running apt-get update inside the container returns 404 Not Found for all repositories.
Therefore, we cannot install wget or update ampinstmgr via the package manager inside the container.
Troubleshooting attempted:
We have tried redeploying the pod using specific tags (:Release, :2.6.5.0), but the pod continues to load the old ampinstmgr binary from the persistent data volume (.ampdata).
We cannot overwrite this binary manually via apt because the container OS repositories are offline.
Request: Since the container OS is EOL and package managers are broken, how can we force the container to discard the old 1.9.5.2 binary in the persistent volume and replace it with the current version included in the cubecoders/amp:latest image?
We need a method to manually inject/overwrite the correct ampinstmgr binary to restore functionality.
Full System Info:
OS: Linux (Debian GNU/Linux 10)
Application Version: 2.6.4.2
Tools Version: 1.9.5.2
InstanceID: …dba8c
Update regarding troubleshooting: We attempted to manually inject a fresh ampinstmgr binary from a clean cubecoders/amp:latest pod into our running instance. However, executing upgradeall resulted in a FileNotFoundException: Couldn’t find the specified application: kill.
From terminal:
root@vps:~# kubectl cp ./ampinstmgr-cube-coders/amp-server-0:/home/amp/ampinstmgr
root@vps:~# kubectl exec amp-server-0 -n cube-coders – bash -c “chown amp:amp /home/amp/ampinstmgr && chmod +x /home/amp/ampinstmgr”
root@vps:~# kubectl exec amp-server-0 -n cube-coders – su - amp -c “/home/amp/ampinstmgr upgradeall”
[Info] AMP Instance Manager v1.9.5.2 built 30/01/2020 16:29
[Info] Release spec: Release - built by CUBECODERS/buildbot on CCL-DEV
[Info] Stopping Instance: ‘ADS01’
[Info] Stopping instance ADS01…
[Info] Requesting soft-stop…
[Error] IM was unable to execute there requested command.
[Error] FileNotFoundException
[Error] [0] (FileNotFoundException) : Couldn’t find the specified application: kill
[Error] at ModuleShared.Utilities.RunUtility (String ExecutableFile, String Arguments, String WorkingDirectory, ModuleShared.RunningTask MonitorTask, Boolean Hidden, Action`1[T] OutputLine)
at ModuleShared.Utilities.RunUtility (ModuleShared.Utilities+UnixUtils Utility, String Arguments, String WorkingDirectory, ModuleShared.RunningTask MonitorTask, Boolean Hidden, Action`1[T] OutputLine)
at InstanceManagerPlugin.LocalInstanceManager.StopProcInstance (InstanceManagerPlugin.LocalAMPInstance instance)
at InstanceManagerPlugin.LocalInstanceManager.StopInstance (Guid instanceId)
at InstanceManagerCLI.Core.UpgradeInstance (String InstanceName)
at InstanceManagerCLI.Core.UpgradeAll (Boolean RestartRunningInstances, Boolean MainlineInstancesOnly)
at InstanceManagerCLI.Core.ExecuteCommand (Collections.Generic.List`1[T] Params, Collections.Generic.Dictionary`2[TKey,TValue] Args)
This confirms the underlying container environment (Debian 10) is missing core utilities (coreutils/procps) or path configurations, making an in-place repair impossible. We likely need instructions on how to migrate our .ampdata (instances) to a fresh container deployment safely.
Best regards, Johan