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

[spraj-zz]

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 --admin-email=user@example.com --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!

[SebastienTolron]

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')

[gigadesign1]

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

That fixed it for me.

[vbuck]

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

[SebastienTolron]

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

[oliverde8]

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.

[riconeitzel]

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

[pmsteil]

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...

[ashvinimarwal]

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...

[vpodorozh]

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.