I upgraded multipass version to 1.12.2, (of course by uninstalling 1.11.1) on my Windows 11. After the upgrade, the multipass was unable to start. I tried to uninstall 1.12.2 and then re-install 1.11.1; but the things couldn’t get back to good. I tried various things like disabling/rebooting/enabling/rebooting hyperV; marking my network connection as private and then re-installing but nothing helped. I then tried to run C:\Program Files\Multipass\bin\multipassd.exe as Administrator and it seems to have started. I could see all my old instances; stop/start them. But the workaround didn’t automate the multipass start on windows boot.
I managed to start multipass afterwards. I had previously set a non-default storage place for multipass instances. I changed it back to default. Opened power shell as administrator and ran:
PS> Stop-Service Multipass
PS> Remove-ItemProperty -Path “HKLM:System\CurrentControlSet\Control\Session Manager\Environment” -Name MULTIPASS_STORAGE
Then rebooted windows.
The multipass now seems to start properly. However, if I change the path back from default to custom:
PS> Stop-Service Multipass
PS> Set-ItemProperty -Path “HKLM:System\CurrentControlSet\Control\Session Manager\Environment” -Name MULTIPASS_STORAGE -Value “E:\Multipass”
It fails to start again.
So I rolled back the changes. Backed up old E:\Multipass and copied everything from C:\ProgramData\Multipass to E:\Multipass, changed path to custom storage. Then I copied my instances from backup to E:\Multipass\data\vault\instances. I also copied the files “E:\Multipass-backup\data\vault\multipassd-instance-image-records.json”, “E:\Multipass-backup\data\multipassd-vm-instances.json” and rebooted. multipass starts well but I can’t see my old instances:
multipass list
No instances found.
The file “E:\Multipass\data\multipassd-vm-instances.json” that I copied from backup looks empty again after multipass restart.
Now the problem is how to get my instances back and running in multipass.
The multipass upgrade is definitely not as simple as it should be :(.
I have managed to rollback the fuss created by an upgrade to latest multipass version.
-
I un-installed the latest multipass-1.12.2+win-win64.
-
I rebooted my laptop.
-
I installed the old good multipass-1.11.1+win-win64.
-
I stopped multipass.d.
-
I unset the modified storage path.
-
I rebooted my laptop.
-
multipass started successfully after the reboot. I created a test instance.
-
I stopped multipass, modified the default storage path:
PS> Stop-Service Multipass
PS> Set-ItemProperty -Path “HKLM:System\CurrentControlSet\Control\Session Manager\Environment” -Name MULTIPASS_STORAGE -Value “E:\Multipass”
- Then I copied the new test instance to new path, modified the files “E:\Multipass-backup\data\vault\multipassd-instance-image-records.json”, “E:\Multipass-backup\data\multipassd-vm-instances.json” to reflect the new instance’s path and started multipath:
PS> Start-Service Multipass
-
After verifying the instance startup from new path, I stopped multipass again. Copied my old instances back to new storage path from my backup. Modified the files “E:\Multipass-backup\data\vault\multipassd-instance-image-records.json”, “E:\Multipass-backup\data\multipassd-vm-instances.json” again to reflect the new instances’ path for all backed up instances and started multipath.
-
I could now list and start all my old instances. But “multipass shell ” was failing with error:
shell failed: ssh failed to authenticate: ‘Access denied for ‘publickey’. Authentication that can continue: publickey,password’
- So, I logged on to the newly created test instance. From there I could ssh my old instance (fortunately, I had configured password access). I updated the key from new test instance (.ssh/authorized_keys) to all new instances and voila; I was able to logon to all instances again.
Hi, @BushMaster! Thanks for reporting this! While I couldn’t replicate the issue exactly as you described it, there are definitely some bugs related to the permissions assigned to the MULTIPASS_STORAGE directory. We will come up with a fix as soon as possible! In the meantime, if you managed to regain access to your old instances, I suggest that you keep using 1.11.1 until we release a fix for this issue.