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:

  1. Connect to portainer
  2. Select Primary Endpoint
  3. Click to Dashboard Menu
  4. 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)

Most upvoted comments

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