Magento 2.1 RC1 - Error when running CLI upgrade command

[toddwolaver]

Attempting to run setup:upgrade after compiling DI results in an error. I have tried with just 'setup:upgrade' and 'setup:upgrade --keep-generated'.

Steps to reproduce

1. Install Magento 2.1 RC1 via composer.
2. Compile DI or enable production mode.
   • 'php bin/magento setup:di:compile' or
   • 'php bin/magento deploy:mode:set production'
3. Run upgrade command (results in error)
   • 'php bin/magento setup:upgrade' or
   • 'php bin/magento setup:upgrade --keep-generated'

Expected result

1. For setup:upgrade to run and process necessary upgrades

Actual result

1. Upgrade does not run and results in error:

php bin/magento setup:upgrade --keep-generated

  [Exception]  
  Warning: file_get_contents(/Users/twolaver/magento/magento-rc1/var/di/setup.ser): failed to open stream: No such file or directory in /Users/twolaver/magento/magento-rc1/vendor/magento/framework/App/ObjectManager/ConfigLoader/Compiled.php on line 28              

Note: contents of var/di are:

• adminhtml.ser
• crontab.ser
• frontend.ser
• global.ser
• webapi_rest.ser
• webapi_soap.ser

[mazhalai]

@toddwolaver why would you run compile before upgrade? Also, if you are installing a fresh 2.1.0-rc1 why do you need to run upgrade? did you have an older code base?
Please follow the steps specified in the following link to upgrade: http://devdocs.magento.com/guides/v2.0/comp-mgr/cli/cli-upgrade.html

[toddwolaver]

@mazhalai The steps in this issue only illustrate the basic steps to recreate the error.

In a real world example, this would be run on a production deployment of an existing codebase. I run upgrade, compile DI and generate static assets off of the production server, move the updated codebase with generated files into place on production and re-run the upgrade with --keep-generated to update the production database. With the current error introduced in 2.1 RC1, this process is no longer viable.

[mazhalai]

@toddwolaver in this case, you will need to clear your var/generation and var/di manually before pushing to the server, since the previous generated files still exist and are no longer relevant since the code has been updated.

[toddwolaver]

@mazhalai Just to be clear, are you saying that in Magento 2.1 'setup:upgrade' will no longer be supported after DI has been compiled?

If so, I would recommend updating the error message and removing the --keep-generated option from setup:upgrade, since it now serves no purpose (i.e. to keep the previously generated files)

The process of building a production 'image' 'off site' minimizes the amount of processing needed in the production environment and limits need to put the production environment into maintenance mode during code deployments. The files are relevant since they were compiled against the updated codebase, just on a different server. However there is still need to update the production database after moving the production 'image' into place in the production environment, hence the need to run 'setup:upgrade --keep-generated' with the compiled files in place.

Thank you,
Todd

[mazhalai]

@toddwolaver No, what I mean is, setup:upgrade will not work with old generated code. We have a mechanism to clean this automatically before upgrade runs, but if you do this locally and push it, and run it with the --keep-generated flag, there is no way to clean the old code.

[toddwolaver]

Thank you @mazhalai

I still get an error when running 'php bin/magento setup:upgrade'. The only way to resolve the error is to manually remove var/di

Thank you,
Todd

php bin/magento setup:upgrade
                                                                                                                                                                
  [Exception]                                                                                                                                                   
  Warning: file_get_contents(/Users/twolaver/magento/magento-rc1/var/di/setup.ser): failed to open stream: No such file or directory in /Users/twolaver/magento/magento-rc1/vendor/magento/framework/App/ObjectManager/ConfigLoader/Compiled.php on line 28 

[mazhalai]

@toddwolaver what version were you on prior to rc1? Also, can you give us more info on your environment like web server, php version, etc.

[mazhalai]

@toddwolaver we have created ticket MAGETWO-53777 to investigate and fix.

[toddwolaver]

@mazhalai I had been using 2.0.7 prior to RC1

Environment details:

• Ubuntu 14.04.4 LTS
• PHP 5.6.19
• MySQL 5.6.28
• Apache 2.4.18

[peec]

Same problem here. ( 2.1-RC2 ) on production deploy. ( Development local copy works with no di compilation ).

Environment:

• PHP 7.0.4
• PHP-FPM with NGINX
• Mysql 5.6
• Magento 2.1-RC2

2.0.7 worked, upgraded to RC2 and now fails.

The commands i run:

echo "DI Compliation"
/src/bin/magento setup:di:compile  

echo "Setup upgrade"
/src/bin/magento setup:upgrade  /// THIS FAILS.

echo "Clearing cache"
/src/bin/magento cache:clean
/src/bin/magento cache:flush
/src/bin/magento setup:di:compile 

Log:

DI Compliation
Compilation was started.
%message% 0/7 [>---------------------------]   0% 1 sec 36.0 MiB%message% 0/7 [>---------------------------]   0% 1 sec 36.0 MiBProxies code generation... 0/7 [>---------------------------]   0% 1 sec 36.0 MiB
Proxies code generation... 1/7 [====>-----------------------]  14% 1 sec 40.0 MiB
Repositories code generation... 1/7 [====>-----------------------]  14% 1 sec 40.0 MiB
Repositories code generation... 2/7 [========>-------------------]  28% 33 secs 140.0 MiB
Service data attributes generation... 2/7 [========>-------------------]  28% 33 secs 140.0 MiB
Service data attributes generation... 3/7 [============>---------------]  42% 33 secs 140.0 MiB
Application code generator... 3/7 [============>---------------]  42% 33 secs 140.0 MiB
Application code generator... 4/7 [================>-----------]  57% 2 mins 158.0 MiB
Interceptors generation... 4/7 [================>-----------]  57% 2 mins 158.0 MiB
Interceptors generation... 5/7 [====================>-------]  71% 3 mins 174.0 MiB
Area configuration aggregation... 5/7 [====================>-------]  71% 3 mins 174.0 MiB
Area configuration aggregation... 6/7 [========================>---]  85% 4 mins 244.0 MiB
Interception cache generation... 6/7 [========================>---]  85% 4 mins 244.0 MiB
Interception cache generation... 7/7 [============================] 100% 4 mins 244.0 MiB
Generated code and dependency injection configuration successfully.
Setup upgrade



  [Exception]                                                                                                                                                                                  
  Warning: file_get_contents(/src/var/di/setup.ser): failed to open stream: No such file or directory in /src/vendor/magento/framework/App/ObjectManager/ConfigLoader/Compiled.php on line 28  



setup:upgrade [--keep-generated] [--magento-init-params="..."]

[davidalger]

@maksek @pboisvert This is a critical bug which I'm rather shocked was not addressed before the release of the GA for 2.1. It was reported nearly a month ago, and kills the ability to do fast atomic deployments of code either by capistrano, imaging, etc, etc.

When can we expect to see this fixed? All deployments via the capistrano-magento2 Gem are now busted, and there is not really a good workaround, as running setup:upgrade on a production server before setup:di:compile is run on the new code is not very feasible, as it would mean having a site in maintenance mode while the compilation (which takes ~3 min) runs.

[hostep]

We also run into this now, like wth?
Indeed very critical.

@ Magento guys, do you even know how people are deploying Magento 2 shops to a production server? I keep getting the impression you haven't got the faintest idea about how this works. Would also be great if you could write some documentation about how to do this according to you, because we have to keep guessing what steps in what order we have to execute, it seems to change with every release you are putting out ...

[pboisvert]

@davidalger @hostep bug has been raised to P0 and folks are reviewing. We will investigate why not addressed for RC. Early comments indicate cause was known and a fix was available but that fix did not pass testing and bug sat with the lower priority in error so it was not flagged as a blocker for 2.1.

[hostep]

I found a temporary fix for this issue. If you can't wait until Magento comes with an update for this issue, you can follow these steps to fix it. My solution makes sure a setup.ser file gets generated, so that the setup:upgrade --keep-generated works again.

This involves creating a very small module with the following files:

• app/code/Vendor/TempSetupDiCompileFix/registration.php

<?php

\Magento\Framework\Component\ComponentRegistrar::register(
    \Magento\Framework\Component\ComponentRegistrar::MODULE,
    'Vendor_TempSetupDiCompileFix',
    __DIR__
);

• app/code/Vendor/TempSetupDiCompileFix/etc/module.xml

<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:Module/etc/module.xsd">
    <module name="Vendor_TempSetupDiCompileFix" setup_version="0.0.1"/>
</config>

• app/code/Vendor/TempSetupDiCompileFix/etc/di.xml (this is the actual fix)

<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:ObjectManager/etc/config.xsd">
    <type name="Magento\Framework\App\AreaList">
        <arguments>
            <argument name="areas" xsi:type="array">
                <item name="setup" xsi:type="array">
                    <item name="frontName" xsi:type="string">temporary-fix-for-magento2-github-issue-4795</item>
                </item>
            </argument>
        </arguments>
    </type>
</config>

And then run

bin/magento module:enable Vendor_TempSetupDiCompileFix

The frontName xml node is a hack, but it's the only way I could get it the solution working properly.
I first tried a solution like defined in the module-cron xml: <item name="setup" xsi:type="null" />, but while this does generate a setup.ser file, it crashes the frontend. So I had to work around it like they did in the module-webapi module, but we don't actually need a frontName for this module, so after applying this hack and surfing to http://example.com/temporary-fix-for-magento2-github-issue-4795 it will crash, but that's not really a big deal :)

[andidhouse]

same problem here!

[rob1256]

Having this issue as well on the release of 2.1.

Is there a way to have a production server without the need for some sort of build server to compile on? Ideally I'd like to for example:
Upgrade Magento/Install a new module
Push up to production
Compile & Run setup to run migrations

With no down-time on the production server.

[hostep]

@rob1256: When they fix this issue, it will be possible :)
Or you can use my temporary fix.

We've been using it for a couple of days, and deploys work again.

They take around 8 minutes (way too long in my opinion), with only about 10 seconds of downtime (also too long), while we put the shop in maintenance mode just before running bin/magento setup:upgrade --keep-generated and disable the maintenance mode again after this.

On the devdocs project, there is also a request for proper documentation about how to perform deploys, but it hasn't been adressed yet: magento/devdocs#419

[rob1256]

@hostep: Thanks for your help :)
Hopefully we'll get some information on the order of commands to run in the docs and potential pitfalls to look out for. Slowly gearing up to get an M2 instance into production so hopefully this issue will be sorted before then.

[davidalger]

@pboisvert It's been seven days since this was moved to P0, but no communication regarding timeline of fix, so I figured I'd check back in on this. Can you comment on about how soon we can expect a patch release which resolves this?

[SantoDE]

We now have the same problem, which keeps us blocked from upgrading to 2.1. Is there any eta available?

[protok]

Same problem here, this really is an issue.

[andidhouse]

@mazhalai do you have a solution for us? we can´t go live with this...

[james-radweb]

Getting the same issue, when will this be fixed?

[alexpotter]

The module code base doesn't match the DB schema and data.
       My_Module       data:       0.0.9  ->  1.0.0      
Run 'setup:upgrade' to update your DB schema and data.

Same issue and cannot migrate without this command

[johnhughes1984]

Same problem here, can we get an update please @pboisvert ?

[ghost]

Same issue here as well on 2.1. The module that @hostep put together does seem to get around it but this appears to be a core issue that needs to be resolved. It would be nice to see Magento 2 in a more stable and usable state.

[ttnnkkrr]

same

[rhiensch]

I've added the temporary fix from @hostep to my magento installation, but i think there is a other way to fix this problem. Simply disable en re-enable a (random) module for example:
php bin/magento module:disable Magento_Weee
php bin/magento module:enable Magento_Weee

[Laura021]

I had this issue.

Set developer mode, run upgrade command and it started working. However I haven't moved to a production status yet-

[stevekem]

@rhiensch Thanks, your solution worked for me!

[rhiensch]

@stevekem No problem, i've been searching for hours and i finally found that this is the best solution. Glad it helped you!

[amansilla]

@rhiensch thanks your workaround worked for me as well. 👍

[tedxas]

Thanks, all, for the many solutions offered here. Simply "rm -rf var/di" worked for me as noted by @yokoishioka and @karl-ravn and elsewhere by @antbates1991 bug issue here: #5954

[elenleonova]

Hi, the issue has been solved in 2.1.1, so closing the ticket. If you have some additional comments, please feel free to reopen if needed.

[hostep]

Tnx @elenleonova for releasing version 2.1.1 so swiftly (please ignore the sarcasm 😉 )

@ everyone who used my temporary fix:
If you upgrade to 2.1.1 it will give you an exception if you have my temporary fix enabled:

1 exception(s):
Exception #0 (BadMethodCallException): Missing required argument $routerList of Magento\Framework\App\RouterList.

So my advice to everyone who has been using my temporary fix is that before you upgrade to version 2.1.1, you do these things:

1. Remove the 3 files from my temp fix
2. Run bin/magento setup:upgrade to remove the entry from your app/etc/config.php file
3. Now upgrade to Magento version 2.1.1

[amansilla]

Thx @elenleonova, was the bugfix applied to the enterprise version as well?

[wasimgit]

I did the fix.

1. Removed the /var/di folder.
2. Deleted the module entry in database setup_module table by

SELECT *
FROM tst_setup_module
LIMIT 0 , 30

then, re run the magento cammand

sudo ./magento setup:upgrade

and it works for me.

[thdoan]

I'm getting a similar error when running magento sampledata:deploy on Magento 2.1.1:

 [Exception]
  Warning: file_get_contents(path/to/app/code/Vendor/SomeModule/composer.json): failed to open stream: No such file or directory in path/to/vendor/magento/module-sample-data/Model/Dependency.php on line 109

Did anybody ever find a workaround for this?

[danslo]

@thdoan That's not related to this issue, but I have encountered that as well.

That command expects a composer.json for your modules, even when it's just in your app/code directory. You can either create that file (with appropriate content), or temporarily disable the module (app/etc/config.php) and move the files out of the way, while you install sampledata.

[thdoan]

@danslo Yeah sorry about that, I eventually found the right issue # but forgot to delete this comment.

[travisdetert]

It is UNBELIEVABLE how unstable these deployment and setup processes are. I am curious how people are suppose to deploy any updates to this platform with any level of confidence.

[esakki08]

hi team,

How to fix this issue? need step by step procedure

[Ctucker9233]

@esakki08 First, try running the commands from your root folder where you have magento installed. Is C:\xampp\htdocs\mtgo where you have magento installed?

[esakki08]

@Ctucker9233 yes "C:\xampp\htdocs\mtgo" is the my magento root folder.

[pantaoran]

@esakki08 this is not the right place for your question. Try the forums or StackExchange. This place here is for bug reports.

[parthatr]

@pantaoran: If you suggest the links, would be better. The application is keep on crashing....

[Ctucker9233]

@esakki08 Try running the commands using php56 or php70 depending on your php version.

[Nolwennig]

On my side, the module have been enabled with the --force option

php bin/magento module:enable Module_Name -f

[gilles6]

This worked for me in Magento 2.1.7 :
bin/magento i18n:collect-phrases --output="app/design/frontend/VENDOR/THEME/i18n/zh_Hans_CN.csv" -m

The -m means that Magento should parse all its files (without -m, only the specified directory is parsed).

[fezanqadirbhatti]

Simply replace the magento file in bin directory with the new one and run the following command on magento file if your host is linux:

sudo chmod u+x bin/magento

Note: Before running bash command make sure your current working directory must be Magento 2.x root.

[Logimax]

My magento theme support magento 2.1.0 so i just update magento 2.1.6 to 2.1.0 then using upgrade command to upgrade and my php bin/magento setup:static-content:deploy command not working it shows some errors so I just clear pub/static and var folders then I run the upgrade it shows the error

error also in deploy command

[Anantkprajapati]

Please run below commands and check it like
rm -rf var/cache/* var/page_cache/* var/di/* var/generation/* var/view_preprocessed/*
php bin/magento setup:upgrade
I am sure it will work