Just run into an issue and am not sure in which aiidalab repository this issue should locate, I guess this is another usage of Discourse that serves as a triage to become a valuable issue for the correct repository.
I use a old docker stack image which had aiida-core==2.2.2 installed which has storage version main_0001. When I install QeApp version 23.4.3 it installed aiida-core=2.4.0 which has storage version main_0002. The installation failed with:
Critical:
Database schema version `main_0001` is incompatible with the required schema version `main_0002`.
To migrate the database schema version to the current one, run the following command:
verdi -p default storage migrate
I am curious how this problem was handled before @yakutovicha ?
AiiDAlab, when it was starting, was always attempting to migrate the database running verdi storage migrate --force.
Here is the actual running line: aiida-core/.docker/opt/configure-aiida.sh at cb8af9f3d52f887260c52f99aa429d18db2d8f75 · aiidateam/aiida-core · GitHub
Dear @jusong.yu and @yakutovicha,
I got the same message (Update aiida-core version ask for DB migration, do it?) when proceeding with git checkout and pip install -e . on a cloned repo branch I just created.
Critical:
Database schema version `main_0001` is incompatible with the required schema version `main_0002`.
To migrate the database schema version to the current one, run the following command:
verdi -p default storage migrate
Details:
- I forked the Vibroscopy plugin in my github account
- cloned it into my local workstation
- cd into the new cloned Vibroscopy-main directory and created a new branch
git checkout on that new branch- Finally,
pip install -e . . This is probably where the issue came from.
Below is a slice of diff old_pyproject.toml new_pyproject.toml (I have been working with an older version of Vibroscopy before). I would be very thankful if 1) you could tell me if I should indeed migrate the DB, and 2) if you could assist me if this has to be done. I had to do that in the past, uploaded a version too high and lost my database. Luckily it was backed-up, but we had to reconfigure aiida from scratch, which I would very happily avoid 
21a22,23
> 'Programming Language :: Python :: 3.10',
> 'Programming Language :: Python :: 3.11',
26,30c28,31
< "aiida-core>=2.1.0",
< "aiida-quantumespresso>=4.1.0",
< "aiida-phonopy>=1.0.0",
< "phonopy>=2.16.0,<3.0.0",
< "quadpy>=0.16.10",
---
> "aiida-core>=2.2.2,<3.0.0",
> "aiida-quantumespresso>=4.3.0",
> "aiida-phonopy>=1.1.3",
> "phonopy>=2.19.0,<3.0.0",
Please let me know if you’d need any more information,
Many thanks,
Virginie (ETHZ)
Hi Virginie, this is because aiida-core was updated and the new version comes with an automated database migration. It is fine to apply it, but before you do, make sure to create a backup of your data as the warning suggests. Once you have the backup (which is just for security should anything go wrong), you can safely perform the migration and afterwards you can continue working with your data as before.
Thank you! Very good to know!
Unfortunately I am unable to follow the procedure in How to manage your installation — AiiDA 2.4.0.post0 documentation since I get the same Critical error when running:
Critical:
Database schema version `main_0001` is incompatible with the required schema version `main_0002`.
To migrate the database schema version to the current one, run the following command:
verdi -p username storage migrate
I tried downgrading the aiida-core version to the one I had previously, but this failed with the following error:
ERROR: Could not install packages due to an OSError: [Errno 16] Device or resource busy: '.nfs00000000001515a0000d34fc'
Saving my data requires the previous aiida-core version, which I can’t access anymore because of an unknown device/resource that is busy. What should I do?
The latter problem is most likely because some processes are still working with the files that you are trying to change by downgrading. Prime candidate would be the AiiDA daemon that you might have forgotten to stop. You can check by running ps aux | grep verdi. If the daemon is still running, this should show something like:
$ ps aux | grep verdi
sph 10651 4.0 1.1 523032 94848 ? Sl 19:30 0:00 /path/bin/python3.11 /home/sph/.mambaforge/envs/aiida-py311/bin/verdi -p main daemon start-circus 1
sph 10654 127 1.3 534300 109732 ? Ssl 19:30 0:01 /path/bin/python3.11 /home/sph/.mambaforge/envs/aiida-py311/bin/verdi -p main daemon worker
sph 10674 0.0 0.0 6392 716 pts/3 R+ 19:30 0:00 grep --color=auto verdi
If you also see processes that are running verdi daemon start-circus and verdi daemon worker, you should kill them with kill -9 PID where you get the PID from the second column of the output above, e.g. 10651 (N.B. these will be different on your machine of course).
After that, you should be able to downgrade the version of aiida-core. Since the migration was added in v2.4.0, the latest you can go back to is v2.3.1.
Thank you @sphuber. I stopped the daemon with verdi deamon stop before proceeding with the backup. Apparently this was not sufficient since can indeed see running processes when typing ps aux | grep verdi.
The commands verdi daemon start-circus and verdi daemon workers issue the same critical error message requiring the update of the database.
However, I worked with our group IT admin who was able to save the database without aiida.
Everything should be fine to proceed with the software update now
The point was not that you should run them, but rather to verify that they were actually still running. ps returns a list of active processes on your system. When you run verdi daemon start, that actually calls verdi daemon start-circus which in turn calls verdi daemon worker.
Anyway, it is not important anymore. Glad you got it working 
1 Like
Mission accomplished, migration completed! Thanks for your help!