Problem/Motivation
The Drupal installer uses a 2-phase kernel boot with an in-process kernel reboot:
1. Phase 1 (InstallerServiceProvider): In-memory stubs (no DB services). Used from start through install_base_system.
2. Kernel reboot in drupal_install_system(): shutdown() => rebuildContainer() => boot() to switch providers.
3. Phase 2 (NormalInstallerServiceProvider): Database-backed services for the remainder.
This adds complexity: two service provider classes, an in-process kernel reboot, and the base_system_verified flag to pick between them.
Main blocker: InstallStorage is read-only (throws on write). System module install needs to WRITE config. So the kernel reboots to switch to DatabaseStorage first.
There's prerequisites (last 2 probably optional)
- #3335756: Drop sequences table in Drupal 12
- #2719315: Try to install system module like any other module
- #2934063: Remove the workaround in \Drupal\Core\Installer\ExtensionListTrait::setPathname()
Proposed resolution
Create InstallerFallbackConfigStorage + merged service provider
ModuleInstaller::install() already triggers a container rebuild internally. If we set base_system_verified = TRUE before calling module_installer->install(['system']), the rebuild picks up the flag and registers full DB-backed services (without an explicit kernel reboot).
Merge NormalInstallerServiceProvider into InstallerServiceProvider and deprecate first one.
Remove kernel reboot from drupal_install_system()
Remaining tasks
- possibly listAll() will need deduplication (DB and install stroages)
- dig URL generation and Routing
- find out risks & edge cases
- probably should wait for D12.1 for deprecation
User interface changes
Introduced terminology
API changes
Data model changes
Release notes snippet
Issue fork drupal-3574200
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
andypostGonna try to hack it with some LLM later