magento2devbox-skeleton icon indicating copy to clipboard operation
magento2devbox-skeleton copied to clipboard

magento setup command is throwing magento.flag does't exist.

Open spraj-zz opened this issue 6 years ago • 9 comments

While hitting the command: magento setup:install --db-host=db --db-name=magento2 --db-user=root --db-password=root --admin-firstname=Magento --admin-lastname=Administrator [email protected] --admin-user=admin --admin-password=admin123 --language=en_US --currency=USD --timezone=America/Chicago --use-rewrites=1 --backend-frontname=admin

An error is thrown as: [Zend_Db_Statement_Exception]
SQLSTATE[42S02]: Base table or view not found: 1146 Table 'magento2.flag' doesn't exist, query wa
s: SELECT flag.* FROM flag WHERE (flag.flag_code='staging')

[PDOException]
SQLSTATE[42S02]: Base table or view not found: 1146 Table 'magento2.flag' doesn't exist

Please help!

spraj-zz avatar Mar 12 '18 20:03 spraj-zz

Same here !

Starting Magento installation: File permissions check... [Progress: 1 / 933] Required extensions check... [Progress: 2 / 933] Enabling Maintenance Mode... [Progress: 3 / 933] Installing deployment configuration... [Progress: 4 / 933] Installing database schema:

[Zend_Db_Statement_Exception]
SQLSTATE[42S02]: Base table or view not found: 1146 Table 'magento.flag' doesn't exist, query was: SELECT flag.* FROM flag WHERE (flag.flag_code='staging')

SebastienTolron avatar Jun 29 '18 13:06 SebastienTolron

Try to delete your env.php file in app/etc/env.php

That fixed it for me.

gigadesign1 avatar Sep 13 '18 10:09 gigadesign1

While @gigadesign1 provides a viable solution, I think it's important to continue to understand the why. I haven't been able to yet isolate which module (presumably a core module) creates the condition, but I found a related issue here which speaks to how dependency injection can initialize things unexpectedly:

  • https://github.com/thaiphan/magento2-s3/issues/19#issuecomment-397506903

vbuck avatar Nov 08 '18 17:11 vbuck

Ok, so , @vbuck is right. This is not not an issue with the cache , or env.php or anything.

This is an issue with custom commands cli.

Indeed , for example , if you are adding Dependency injection in your custom command cli for storeManager for example this won't work.

Just comment out every custom command for installation and it will work.

On my side what I did , is changing the the dependency injection , and using object Manager instead.

This is a bad practice . but I think for command cli , this is the best thing to do. This is clearly an issue of the conception in Magento core.

Good luck guys

SebastienTolron avatar Nov 16 '18 19:11 SebastienTolron

To continue on this subject. This issue can indeed come from custom commands cli, but there is a second possibility.

If you (or any modules you install) override a class that is used by the magento setup, and modifies the dependencies and adds for example a dependency to storeManager you will get the same error.

For example if you override \Magento\Catalog\Helper\Product and inject Magento\Customer\Model\ResourceModel\CustomerRepository you will create a dependency to Magento\Framework\Locale\Resolver which calls to the database in the constructor.

I would say the way to debug this is to :

  • disable all modules and enable them one by one till you get the error during install
  • once you identified the module, remove commands lines
    • If the issue is with command lines, fix it by using the ObjectManager during execution :cry:
    • If the issue is not with command lines, you will need to modify the core to find the cause of the error

Modify vendor/magento/framework/ObjectManager/ObjectManager.php at the function public function get($type) and put the fallowing content for the if.

if (!isset($this->_sharedInstances[$type])) {
            try {
                $this->_sharedInstances[$type] = $this->_factory->create($type);
            } catch (\Exception $exception) {
                echo "At fault : $type\n";
                throw $exception;
            }
        }

This will print before the exception something like

At fault : Magento\Customer\Model\ResourceModel\Address
At fault : Magento\Customer\Model\ResourceModel\AddressRepository
At fault : MyProject\Catalog\Helper\Product
At fault : Magento\Catalog\Model\Product\Attribute\Repository
At fault : Magento\Catalog\Console\Command\ProductAttributesCleanUp

Which allows me to see that the issue is with MyProject\Catalog\Helper\Product

Good luck finding your issues.

oliverde8 avatar Jan 04 '19 10:01 oliverde8

Instead of using the ObjectManager you could inject a proxy class instead! https://devdocs.magento.com/guides/v2.4/extension-dev-guide/proxies.html

riconeitzel avatar Oct 14 '20 17:10 riconeitzel

The solution by @oliverde8 helped me also... by injecting that code into the ObjectManager.php

This should be a standard in Magento code to help debug such problems...

pmsteil avatar Jul 28 '21 19:07 pmsteil

This worked for me on Adobe commerce 2.3 php bin/magento setup:uninstall rm -rf var/cache/ var/di/ var/page_cache/ generated/ pub/static/ php bin/magento setup:install --cleanup-database ...other options...

ashvinimarwal avatar Feb 02 '22 06:02 ashvinimarwal

Here is a working solution to prevent issues with custom CLI commands using the connection to DB in constructors:

https://github.com/run-as-root/magento-cli-auto-proxy

composer req run_as_root/magento-cli-auto-proxy:^1

It automatically makes proxies for all CLI command arguments.

P.S.: for sure, it is better to fix your code by using proxies, for example, but if you have no control over an extension with this problem - current solution will help you out.

vpodorozh avatar Jul 24 '23 08:07 vpodorozh