Composer plugin installation failed

[VincentLanglet]

Versions

• Vagrant: Just installed
• Provider: Virtualbox
• Homestead: You should be on the most recent release branch.

Host operating system

Tested on both Window and Mac.

Homestead.yaml

---
ip: "192.168.10.10"
memory: 2048
cpus: 1
provider: virtualbox

authorize: ~/.ssh/id_rsa.pub

keys:
    - ~/.ssh/id_rsa

folders:
    - map: ../symfony4
      to: /home/vagrant/code

sites:
    - map: symfony4.test
      to: /home/vagrant/code/public

databases:
    - homestead

features:
    - mariadb: false
    - ohmyzsh: false
    - webdriver: false

Expected behavior

No error during composer install

Actual behavior

Steps to reproduce

This is the repo to reproduce the bug: https://github.com/ak3l/Cours_Symfony4/tree/bug

Instead following the actual README, do composer install without --no-plugins --no-scripts to get the error.

When I run composer install -vv, I get

 - Installing ocramius/package-versions (1.4.0): Reading /home/vagrant/.composer/cache/files/ocramius/package-versions/9015316288b55423c693c083934dccb5ab72981d.zip from cache
Loading from cache
 Extracting archiveExecuting command (CWD): unzip -qq  '/home/vagrant/code/vendor/ocramius/package-versions/200f6a66a0865848df9170ec0fd15921' -d '/home/vagrant/code/vendor/composer/f1785882'
Plugin installation failed, rolling back

[svpernova09]

FYI it appears this has been fixed (intentionally or unintentionally) upstream by Virtualbox. I just built a fresh box using Virtualbox 6.0.12 and was able to run composer install ocramius/package-versions into a fresh Laravel 6 project without issue.

[codisart]

I made it work with the option "--prefer-source" of composer install. It took a longer time but the installation worked.

[jimuelpalaca]

I made it work by changing the shared folder type to nfs and then run vagrant provision. ssh to vagrant and run composer clearcache. after that I was able to do composer install without any error.

[neoglez]

The solution of @codisart also worked for me. Host Win10 guest Debian 9

[svpernova09]

Just checked that Virtualbox 6.0.14 does not have this same issue.

vagrant@homestead:~/qs$ composer require ocramius/package-versions
    1/11:   http://repo.packagist.org/p/provider-2014$89b80583cbeafe0d29b6d183923d5b8828676086421562b4b92ee337fa7e7eaf.json
    2/11:   http://repo.packagist.org/p/provider-latest$c388c1a264be58b3bee811bbe10b221546a9bb93c02141f394cb179bc6375aff.json
    3/11:   http://repo.packagist.org/p/provider-2019-01$7aa97774e7cdff79698280aa375481697e3d52583dfb687953b594cb5f0630d1.json
    4/11:   http://repo.packagist.org/p/provider-2015$d861801f9eb2d5e552a6408e49b69519bd73b641b72b89828033725a0c105ddc.json
    5/11:   http://repo.packagist.org/p/provider-2013$d43bc94601a2eb4a005d86fcc58809e63661238903da0f3b7c5155a294dd9b7f.json
    6/11:   http://repo.packagist.org/p/provider-2019-10$25b65e02d6126cc1ecca3d9bb0ba66560a91c2444af6dbd6ab20113cee417b2e.json
    7/11:   http://repo.packagist.org/p/provider-2019-04$03ba4eac66099a96af5ca1f1b6e56703dae9688591ffedbce86e7718452e35dc.json
    8/11:   http://repo.packagist.org/p/provider-2019-07$cac5f9cc000152b8a2530647b995ee3c71b33b6a9487c3a8f339c71d2c748466.json
    9/11:   http://repo.packagist.org/p/provider-2016$daf87390627921faf3550fbab3e07ed8c3e5ac187269b112a42d3fbc5c95552c.json
    10/11:  http://repo.packagist.org/p/provider-2017$18ed9c9263be18cecdbc3c4d0a0fb70d3103aa85456cc0dc98f2a45e4808149c.json
    11/11:  http://repo.packagist.org/p/provider-2018$fb0513c7c16531ed70adee725c96156f5b2c568947aa3f556c5d85fa4beaef38.json
    Finished: success: 11, skipped: 0, failure: 0, total: 11
Using version ^1.5 for ocramius/package-versions
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
    1/1:    https://codeload.github.com/Ocramius/PackageVersions/legacy.zip/1d32342b8c1eb27353c8887c366147b4c2da673c
    Finished: success: 1, skipped: 0, failure: 0, total: 1
Package operations: 1 install, 0 updates, 0 removals
  - Installing ocramius/package-versions (1.5.1): Loading from cache
Writing lock file
Generating optimized autoload files
Warning: Ambiguous class resolution, "App\Mail\VerifyEmail" was found in both "/home/vagrant/qs/app/Mail/VerifyJoinEmail.php" and "/home/vagrant/qs/app/Mail/VerifyEmail.php", the first will be used.
ocramius/package-versions: Generating version class...
ocramius/package-versions: ...done generating version class
> Illuminate\Foundation\ComposerScripts::postAutoloadDump
> @php artisan package:discover --ansi
Discovered Package: facade/ignition
Discovered Package: fideloper/proxy
Discovered Package: laravel/tinker
Discovered Package: laravel/ui
Discovered Package: nesbot/carbon
Discovered Package: nunomaduro/collision
Package manifest generated successfully.
vagrant@homestead:~/qs$ ls -alh /opt
total 16K
drwxr-xr-x  4 root root 4.0K Nov 28 18:20 .
drwxr-xr-x 26 root root 4.0K Nov 29 18:26 ..
drwxr-xr-x  4 root root 4.0K Nov 28 18:20 lmm
drwxr-xr-x  9 root root 4.0K Nov 28 18:09 VBoxGuestAdditions-6.0.14
vagrant@homestead:~/qs$

[xaoc-303]

Virtualbox 6.0.14 & Extensions 6.0.14

composer install --no-cache

ocramius/package-versions: ...done generating version class

[Christophvh]

I'm having the same issue on virtual box 6.1

[svpernova09]

To reiterate: There is nothing I'm aware of that Homestead can do about this. It's a bug in Virtualbox since 6.0.x (Virtualbox 6.0.0 was safe for me to use to build boxes for a while, but I'm no longer able to successfully build on 6.x anymore) Meaning I'm stuck using the latest version 6.1.x to build Homestead with.

I raised this issue with Virtualbox https://www.virtualbox.org/ticket/18776 And was met with less than helpful comments from someone who had no business replying to the ticket.

The future versions of Homestead will be built on Virtualbox 6.1.x and the only thing I can recommend is people stop using this terrible provider (Virtualbox).

If you're on MacOS: you can use Parallels (Disclaimer: they provide me a free license because of my OSS work on Homestead). The tradeoff is slightly larger VM image sizes but much more reliable than Virtualbox. Even if they didn't provide me a license this is something I would 100% purchase.

If you're on Windows: Hyper-V has come a long way. You can even see some of the Vagrant team working on getting Vagrant in WSL working. The only downside to using Hyper-V today is networking. Hyper-V still lacks the ability to honor network settings assigned by Vagrant. If you're a network wizard configuring your Hyper-V virtual switch to give a reliable IP shouldn't be terrible.

If you're on Linux: Ironically enough Linux is the one platform where I haven't run Virtualbox very much so I'm honestly not sure if it's the same situation in regards to file sharing.

Last Resort: VMware - VMware is a paid product and you have to buy a Vagrant license to use VMware providers. You'll have better VM performance and folder sharing in VMware over Virtualbox any day of the week. But it's been my experience that VMware tooling is quite finicky and I often have to completely reinstall their products to be able to generate good builds. I've never understood why, but it's a thing for me.

Good luck, godspeed and someone find a bug bounty I can donate to get Virtualbox to solve this issue.

[Christophvh]

Ok, switching will be annoying since I have a lot of boxes running on virtual box already.

I don't understand this statement:

The future versions of Homestead will be built on Virtualbox 6.1.x

Does that mean that homestead v12 for example will work again with Virtualbox ?

[svpernova09]

I don't understand this statement:

The future versions of Homestead will be built on Virtualbox 6.1.x

Does that mean that homestead v12 for example will work again?

It means for a long time we got around this bug because I was able to build the base box on Virtualbox 6.0.0 Recently that stopped working due to some incompatibility with the workflow/tools.

This means any future releases of Homestead base box will be built with Virtualbox 6.1.x unless otherwise noted. (This includes the beta released yesterday)

[svpernova09]

To be perfectly clear: This issue will reappear until it's fixed upstream in a Virtualbox release and there's no longer anything I can do about it other than warn users.

[liamoreilly]

I know of 2 workarounds. Not great - but at least we can live with it.

I have just updated to the latest vagrant, homestead box, homestead git repo, and VirtualBox.

Workaround 1

Strangely composer install works fine for me, but npm install fails with this problem. However, as a workaround yarn install works fine. I am not sure why composer works okay though.

Workaround 2

The other workaround I know of is to put the node_modules folder on a non-mounted directory (e.g., ~/node_modules_project_name). Then symlink your Laravel node_modules directory to that one. With the actual node_module directory sitting on the VM (and not on a mounted folder) then you don't run into this problem. You can do the same trick with the vendor folder for composer.

[scm6079]

Because this still fails (yes, due to a VirtualBox error) and our team NEEDS it to work - I have coded a functional workaround that adds a delay when it detects that it is running under a standard vagrant Virtualbox instance (through a very rudimentary check for the /vagrant folder). While not ideal, for teams that are in the same boat as ours until this is fixed properly this will get you up and running:

https://github.com/Cyberitas/composer/releases/tag/v1.10.7-vbox

Simply use this version of composer.phar instead of the production releases, and skip any composer self-update steps.

[svpernova09]

Because this still fails (yes, due to a VirtualBox error) and our team NEEDS it to work - I have coded a functional workaround that adds a delay when it detects that it is running under a standard vagrant Virtualbox instance (through a very rudimentary check for the /vagrant folder). While not ideal, for teams that are in the same boat as ours until this is fixed properly this will get you up and running:

https://github.com/Cyberitas/composer/releases/tag/v1.10.7-vbox

Glad you got it working but this sounds terrifying. IMHO the better option is to run these commands on your host machine.

[scm6079]

https://github.com/Cyberitas/composer/releases/tag/v1.10.7-vbox

Glad you got it working but this sounds terrifying. IMHO the better option is to run these commands on your host machine.

The risk running locally is that varying host PHP versions and OS differences can write incompatible libraries to the checked-in project lock-file that are more likely to introduce production failures (thus defeating some of the benefits of vagrant/VirtualBox). As frustrating as adding a 2-second delay to the file operations in composer is, it is less risky than having a developer check-in a lock file that could break a production artifact.

We've discussed putting an engineering team on reviewing the Virtualbox source, but at this point, it has been more cost-effective for our company to simply use the patched composer.

If the community has any other potential workaround ideas, we are happy to aid in the development of them (we have enterprise IoT, OS, web, and app developers).

[scrolltumi]

I made it work with the option "--prefer-source" of composer install. It took a longer time but the installation worked.

https://github.com/codisart This helped me a lot homez THANK YOU!! ... had an issue with --no-plugins, needed the plugins ... This was a life saver!

[Kolyunya]

Hi @svpernova09! Thank you so much for your work tracking this issue down!

Could you please share how exactly you were able to fix this? I was able to run the latest Homestead v11.0.1 no problem on VirtualBox 6.1 with shared folders.

But the problem is that I need to build my custom box from scratch and this bug keeps occuring for me on the very same VirtualBox 6.1 when I build the box from scratch.

So I wonder how you were able to work this around? Is that a specific version of Guest Additions or a custom composer build? Thank you so much for sharing!

[svpernova09]

Hi @svpernova09! Thank you so much for your work tracking this issue down!

Could you please share how exactly you were able to fix this? I was able to run the latest Homestead v11.0.1 no problem on VirtualBox 6.1 with shared folders.

But the problem is that I need to build my custom box from scratch and this bug keeps occuring for me on the very same VirtualBox 6.1 when I build the box from scratch.

So I wonder how you were able to work this around? Is that a specific version of Guest Additions or a custom composer build? Thank you so much for sharing!

I really wish I could explain this but I can't. My best guess is that the original bug was introduced sometime between Virtualbox 6.0.0 -> 6.0.4 releases and persisted into some 6.1 builds as well. My temporary workaround was to build the base boxes using Virtualbox 6.0.0 and it worked well for a while. However it stopped working on my system and I was forced to upgrade to 6.1. Knowing this issue was likely to return since there hasn't been any clear information from Virtualbox about what I'm calling a bug deep into the Virtualbox synced folders implementation.

I'm glad to hear the latest box version is working for you. It shouldn't have anything to do with the version of Guest Additions. Homestead doesn't actually require them to operate (contrary to what I thought for a really long time). You can see what versions of the guest additions are installed by running ls /opt which should contain a Virtualbox folder with a guest extension version.

At this point I'm using the latest Virtualbox to build base boxes, Virtualbox Version 6.1.12 r139181 (Qt5.6.2).

[MichaelCharles]

• composer install --no-plugins --no-scripts
• composer install

I don't have the liberty of updating/changing any versions for this current project, but @VincentLanglet's solution worked for me.

[bossgenius54]

I found a way to troubleshooting this error. In my case, I used not the last version of Virtual Box. I updated and deleted the vagrant box. Installed a new version of Virtual Box. That's all.

[Binternet]

@codisart you da man!! thanks!

[asanikovich]

Does this mean we should create an issue in Virtualbox repository ?

I would LOVE to see this, but after looking through their bug tracker I'm pretty overwhelmed at where to even begin. I tried to use the latest development build but it wouldn't even install.

This only really confirms my suspicions and verifies that this isn't a Homestead issue, but a Virtualbox one. I'm going to poke around and see what I can do, but I'm not hopeful there's much we'll be able to do here.

Creating an issue in Virtualbox with the link of you repo seems like the best things to do ; but I didn't look at their bug tracker.

FYI, the solution I took is

• use type: nfs
• composer install --no-plugins --no-scripts
• composer install

This way I have no error during the installation, and not permission errors.

the best solution.

[binary1230]

randomly popping in, I've hit this bug in another project, and have been creating repro steps and tracing down kernel debugging info inside virtualbox. that info is documented in: https://www.virtualbox.org/ticket/8761 I believe that issue is either the same or very closely related to what you guys are hitting here.

Apologies for the spam, I'm spreading this around so if people are trying to get the bottom of it, they have good breadcrumbs.

[dikutandi]

I found a way to troubleshooting this error. In my case I Just Update Composer into version 2.x

composer self-update --2