Closed ostrolucky closed 3 years ago
legal90
commented
3 years ago Hm... The upgrade the plugin itself should not affect the guest OS boot.
@ostrolucky Did you try doing vagrant reload? (it reboots the VM)
If the error is still there after the reboot - did you look into the journal -xb output, as the loader suggested? Do you see any errors there?
ostrolucky
commented
3 years ago Issue persists on reload and I cannot use journal -xb because I cannot access console.
This reproducibly happens on every update from 2.1.0. If box is provisioned for first time with 2.2.x, then it works though. Doesn't happen to me only, but all people I know who use our Vagrant configuration.
legal90
commented
3 years ago @ostrolucky I can't reproduce the issue on the plain generic/debian10 box (got it by vagrant init generic/debian10 -m).
Could you please provide a simplified Vagrantfile which could be used to reproduce that issue?
I suspect that it might be related to synced folder mounting, because between v2.1.0 and v2.2.1 there are changes related to guest's /etc/fstab, but still need to reproduce that.
ostrolucky
commented
3 years ago # -*- mode: ruby -*-
# vi: set ft=ruby :
Vagrant.configure("2") do |config|
config.vm.box = "generic/debian10"
config.vm.provider "parallels"
config.vagrant.plugins = ["vagrant-parallels"]
###################################################################
# Configure providers
config.vm.provider "parallels" do |prl|
prl.update_guest_tools = true
end
config.vm.synced_folder "vagrant", "/vagrant", :owner => "vagrant", :group => "vagrant"
endvagrant plugin install vagrant-parallels --plugin-version 2.1.0;vagrant up;vagrant plugin update vagrant-parallels;vagrant reload;vagrant reload
relthyg
commented
3 years ago Same here.
vagrant init bento/ubuntu-18.04 && vagrant up --provider parallels && vagrant reloadfails in the same way.
vagrant plugin install vagrant-parallels --plugin-version 2.1.0is the cure.
Vagrant 2.2.16 Parallels 16.5.0 MacOS 11.4
mpdude
commented
3 years ago Might be the change from #377, that seems to tweak mount options on vagrant reload?
Does it indeed change /etc/fstab? If it corrupts that and/or puts invalid values in there, that would explain why the Boot cannot mount the root filesystem and ends up in emergency mode.
pokono
commented
3 years ago +1 I have the same issue for months now. Only things I was able to do is suspend the machine instead of halting it.
Reverting the parallels plugin to 2.1.0 does indeed solves the issue for now.
Vagrant 2.2.16 Parallels 16.5.0 MacOS 11.4
clementmouchet
commented
3 years ago Yep, I can see this on my CentOS 7 VMs too, the /etc/fstab still contains entries from the mounts of the previous boot, but the shares aren't setup, so the machine fails to boot very early on.
You can enter the rescue mode, take entries out and reboot it immediately, and vagrant then carries on happily.
legal90
commented
3 years ago Hi all and thank you for the provided information! I confirm that vagrant-parallels release v2.2.0 has a regression which caused the guest OS boot failure after the VM reboot. Sorry about that! :(
I prepared the fix for this issue: https://github.com/Parallels/vagrant-parallels/pull/391 Hopefully I can get it merged and released later today.
legal90
commented
3 years ago @ostrolucky @clementmouchet @pokono @relthyg I just released the vagrant-parallels v2.2.2 with the fix #391.
Could you please update the provider and check if it fixes the problem in your case? Thank you in advance!
clementmouchet
commented
3 years ago Thanks @legal90 it fixes it for me.
legal90
commented
3 years ago @clementmouchet Thank you for confirming! I'm gonna close this issue now. Feel free to open a new one if you will encounter that again
relthyg
commented
3 years ago Works for me, thank you!
vagrant plugin install vagrant-parallels --plugin-version 2.1.0vagrant up# ok so farvagrant plugin update vagrant-parallelsvagrant haltvagrant up