portainer: db migration from 1.24 to 2.x without going via 2.0.0 causes db corruption
Hi,
Bug description After updating portainer from 1.24.1 to 2.1.1 (it should be 1.24.1 -> 2.0.0 -> 2.1.1) i have an error displayed when i access to the dashboard : https://[portainer]:9000/#!/1/docker/dashboard
This error is :
“Failure Cannot read property ‘length’ of null”
It doesn’t stuck me but maybe something went wrong during migration process.
I already managed this point : https://github.com/portainer/portainer/issues/4422
Expected behavior
No error displayed
Portainer Logs 2021/04/09 06:22:40 Instance already has defined endpoints. Skipping the endpoint defined via CLI. 2021/04/09 06:22:40 server: Reverse tunnelling enabled 2021/04/09 06:22:40 server: Fingerprint a5:cb:f3:ba:db:2c:69:b1:14:86:39:49:3e:55:5d:89 2021/04/09 06:22:40 server: Listening on 0.0.0.0:8000… 2021/04/09 06:22:40 Starting Portainer 2.1.1 on :9000 2021/04/09 06:22:40 [DEBUG] [chisel, monitoring] [check_interval_seconds: 10.000000] [message: starting tunnel management process]
Steps to reproduce the issue:
- Connect to portainer
- Select Primary Endpoint
- Click to Dashboard Menu
- See error : Failure \n Cannot read property ‘length’ of null
Technical details:
- Portainer version:
2.1.1
- Docker version (managed by Portainer):
20.10.5
- Platform (windows/linux):
Debian 10
- Command used to start Portainer (
docker run -p 9000:9000 portainer/portainer
):docker stack deploy --compose-file=portainer-agent-stack.yml portainer
- Browser:
Chrome
- Use Case (delete as appropriate): Using Portainer as Dev Envrionment
- Have you reviewed our technical documentation and knowledge base? Yes
Additional context Everything else seems to work fine
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 41 (8 by maintainers)
Hi!
We have two docker swarm clusters. The “old” one from the earlier v1.2x times, upgraded in multiple steps to 2.6.2. And a “new” one fresh initialized with V2.6.1
After digging around with the browser debug console I compared the portainer bolt DB and found this difference:
First 270 chars and last 100 chars of database (endpoints) - “old” swarm:
{“Id”:1,“Name”:“docker-old”,“Type”:2,“URL”:“tcp://tasks.agent:9001”,“GroupId”:3,“PublicURL”:“”,“TLSConfig”:{“TLS”:true,“TLSSkipVerify”:true},“Extensions”:[],“AzureCredentials”:{“ApplicationID”:“”,“TenantID”:“”,“AuthenticationKey”:“”},“TagIds”:null,“Status”:1,“Snapshot -CUT- agementFeatures”:true},“LastCheckInDate”:0,“AuthorizedUsers”:[4],“AuthorizedTeams”:[1,2],“Tags”:[]}
First 270 chars and last 100 chars of database (endpoints) - “new” swarm:
{“Id”:1,“Name”:“docker-new”,“Type”:2,“URL”:“tcp://tasks.agent:9001”,“GroupId”:3,“PublicURL”:“”,“TLSConfig”:{“TLS”:true,“TLSSkipVerify”:true},“Extensions”:[],“AzureCredentials”:{“ApplicationID”:“”,“TenantID”:“”,“AuthenticationKey”:“”},“TagIds”:[],“Status”:1,“Snapshots”:[{“T -CUT- mentFeatures”:false},“LastCheckInDate”:0,“AuthorizedUsers”:null,“AuthorizedTeams”:null,“Tags”:null}
@huib-portainer:
TagIds and Tags values are inverted from old to new version. Maybe that’s the reason for this error?
Tom