-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Local DB is wiped every time after vagrant halt #164
Comments
Running After a
Both when running halt and
However, after a
This is because the site is always installed by the time Vagrantfile triggers. I have an idea how to fix it. While waiting for it, you can run
Or alternatively configure |
The code in the Vagrantfile is bloated and obsolete anyway, it should simply be running wp-development-up after the Vagrant box is up so that all imports and pulls etc run correctly inside the Vagrant box without depending on the Vagrantfile contents. This makes the project template also better compatible and unified with using Docker. Related: #164.
Thanks for the comments.
I let you know if this is still reproduced when I continue developing. |
@ottok Seems this is not reproduced anymore after I pulled the db from live with |
We are experiencing the same kind of error. When halting for the first time, creating the db dump goes as expected. But when booting the box and halting again, the dump got stuck in the middle of process.
I will also check with plain install --> |
Tested this with plain install and it didn't give me any errors. When having a plain install and adding a production site configs to config.yml it starts to give me errors.
Before halting,
And after halting, the result was this:
Total amount seems to be changing, but same files can be found. And
After:
After the error when trying to download production db, it fails to same error message. Also db dump file cuts before given table name in error message, so db dump file is broken. |
Tuomas: your database got corrupted. Luckily it is a dev database.. You
need to start from scratch to recover from that.
|
Yep. At the moment it's happening very often, after updating to latest box version. Have to check if that's something to do with certain plugin. |
Seems like I have the same problem. First After trying to
|
The code in the Vagrantfile is bloated and obsolete anyway, it should simply be running wp-development-up after the Vagrant box is up so that all imports and pulls etc run correctly inside the Vagrant box without depending on the Vagrantfile contents. This makes the project template also better compatible and unified with using Docker. Related: #164.
The code in the Vagrantfile is bloated and obsolete anyway, it should simply be running wp-development-up after the Vagrant box is up so that all imports and pulls etc run correctly inside the Vagrant box without depending on the Vagrantfile contents. This makes the project template also better compatible and unified with using Docker. Related: #164. Also clean away some extra output to avoid excess verbosity.
The code in the Vagrantfile is bloated and obsolete anyway, it should simply be running wp-development-up after the Vagrant box is up so that all imports and pulls etc run correctly inside the Vagrant box without depending on the Vagrantfile contents. This makes the project template also better compatible and unified with using Docker. Related: #164. Also clean away some extra output to avoid excess verbosity.
We identified some scenarios where the database could become corrupted due to the startup/shutdown process. Those issues should be fixed in latest https://app.vagrantup.com/seravo/boxes/wordpress-beta/versions/20210202.0.0 |
Please help out by testing with latest Seravo/wordpress-beta box and latest Vagrantfile from this repo and comment here if you are still able to get some (related) errors. |
Thanks @ottok, will test that later this week |
Cheers. Changed the vm box to 'wordpress-beta' and was able to halt vagrant and launch it up again without errors and this time after the halted site didnt go to the installation page anymore. However local sites are loading very slow and bigger sites just simply refuse to load at all. |
@dubbajones do you mean that you were not able to boot your site at all? Because I had that problem with bigger project after destroying the project. First I was able to boot and halt it, but after destroy I'm not able to boot it anymore. The project just dies at ssh connection. Had the ssh issue also with the smaller project, but I was able to sort it out with killing the box and reboot. But I didn't have any issues related to database dump. So it worked okay for me. 👍 |
Hey. Thanks for the reply. I was able to halt and destroy smaller project and launch vm back up and it works (with wordpress-beta box). However the first time the local site loads anything after vagrant up it is very very slow. With a bigger project 'vagrant up' doesn't go through at all (with wordpress-beta box). It dies at ssh connection just like yours. |
I had similar problem with SSH connection. There is a separate issue in here somewhere. My workaround was to set my Virtualbox to version 6.1.6. Don't know if that helps for you... |
Thanks, I will try that and let you know later. |
Slowness issues are tracked and debugged in #171 |
For me |
Not entirely sure if related, but seems similar to an issue I'm having on Windows. Database seems to get corrupted on
It then goes on and on with more errors like this one:
It does ultimately output:
However the site is in the install state, plus the install screen has errors about missing tables.
Running the latest VirtualBox 6.1.20 and latest Vagrant 2.2.15. I haven't had issues earlier with any sites, they started with this site. Not really knowing the specifics of the whole scenario in running the local environment, it's hard to tell what is different. Did this site use an older box present on my system initially, but something in the files you clone from live when starting is different? Now of course the box is newer for this site, since I thought updating might fix the issues. Anyway as I mentioned, I noticed that beta box might help with this. So I'll go ahead and try that. Will report back. |
The latest
At least the first time after making some changes, halting, rebooting my computer entirely (just to simulate regular conditions) and bringing it up again resulted in everything being intact. I guess in some cases you could just switch the box being run, but at least for me the database during the issues got corrupted entirely preventing even importing from production. So the only option was to start the local environment from scratch. |
There seem to be a problem with the latest vagrant box.
Steps to reproduce:
20201205.0.0
vagrant up
to boot your local setupvagrant halt
to close the virtual machinevagrant up
Actual results:
All the changes you did to site are gone. Content need to be reinserted.
Expected:
All the changes made to local db should be there (at least it has work like that before).
The text was updated successfully, but these errors were encountered: