If apt install mysql-server stalls forever at "Setting up mysql-server", the package manager itself is fine: the MySQL package's configuration script has launched a temporary mysqld to bootstrap the root account, and that instance is not exiting. Kill the temporary server, let the configuration finish, then repair the root account's authentication plugin — MySQL 8.4 ships with mysql_native_password disabled, which is why logins afterward fail with ERROR 1524 (HY000): Plugin 'mysql_native_password' is not loaded. A clean reinstall of Ubuntu avoids none of this, because the same bootstrap path runs on a fresh install too.
What the package is doing when it "freezes"
When dpkg configures mysql-server, it runs the post-installation script at /var/lib/dpkg/info/mysql-server.postinst. That script starts a private, throwaway MySQL server for first-time setup: mysqld runs as the mysql user with a generated --init-file under /var/lib/mysql-files/ containing the bootstrap SQL, and a temporary Unix socket in a fresh /tmp directory instead of the normal one. The script then waits for that server to process the init file and shut down.
The update-alternatives line you see is just the previous step completing; everything after it happens silently inside the postinst. If the bootstrap SQL fails — for instance because it references the now-disabled native password plugin — or the temporary server simply never exits, the script waits indefinitely and the whole install looks frozen.
Confirm the diagnosis before killing anything
The process list tells the story. You should see a chain from apt through dpkg --configure --pending and debconf to mysql-server.postinst, plus a mysqld owned by the mysql user carrying --init-file=/var/lib/mysql-files/tmp.* and --socket=/tmp/tmp.*/mysqld.sock. That mysqld is the bootstrap instance, not your real database server.
Two checks are worth making first:
- Give it a few minutes and watch the CPU time of the
mysqldprocess; a genuinely stuck bootstrap sits near idle with no growing error log. - Read
/var/log/mysql/error.logfor entries written by the temporary server around the hang — they usually reveal which bootstrap statement failed. While the hang is live, the generated init file still exists in/var/lib/mysql-files/and shows exactly what the script was trying to run.
Unblocking the stuck configuration
Kill only the temporary mysqld — the process with the --init-file and the temporary socket — not apt or dpkg. Terminating the bootstrap server lets the postinst continue, and the usual "Processing triggers" lines follow as the install completes. Never kill apt or dpkg mid-configure; that is what leaves packages half-configured. If that has already happened, sudo dpkg --configure -a retries the pending configuration.
Fixing ERROR 1524 by moving accounts to caching_sha2_password
MySQL 8.4 disables mysql_native_password by default, and the 9.x series removes it entirely; caching_sha2_password is the supported default. Any account still flagged for the old plugin — including root@localhost when the bootstrap was interrupted — cannot log in, and the server reports that the plugin is not loaded.
sudo mysql still works even with password logins broken, because as the system root you connect over the local Unix socket and the server trusts that identity without a password check. Use it to see the damage and fix it:
SELECT user, host, plugin FROM mysql.user WHERE plugin = 'mysql_native_password';
ALTER USER 'root'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'your-password';Repeat the ALTER USER for every other account the query returns. After that, ordinary password logins with the mysql client work again.
If some legacy client genuinely cannot speak caching_sha2_password, MySQL 8.4 can re-enable the old plugin: add mysql_native_password=ON under the [mysqld] section of /etc/mysql/mysql.conf.d/mysqld.cnf and restart MySQL. Treat this as a bridge only — the option disappears in 9.x — and note that enabling it before running the package configuration can also let a bootstrap that depends on the plugin complete cleanly.
Preventing it on the next upgrade
- Before a release upgrade that moves MySQL between major versions, confirm every account uses
caching_sha2_passwordand take a dump of your users and data. - If a package configure ever hangs again, resist killing
apt: identify the child process dpkg is waiting on and read that process's log first. - Remember that the temporary bootstrap server holds no data of yours, so killing it costs nothing — the real server is started separately after configuration.
Frequently Asked Questions
Why does sudo mysql work without a password?
Root on the host connects through the local Unix socket, and the server maps that identity to the MySQL root account without a password check. That socket path does not depend on any password plugin, so it survives even when plugin-based logins are broken.
Is it safe to kill mysqld during the install?
It is safe to kill the temporary bootstrap instance — the one with --init-file and a /tmp/tmp.*/ socket. The real system server starts separately after configuration, so the bootstrap copy holds nothing you could lose.
Can I keep mysql_native_password enabled for good?
On MySQL 8.4 you can re-enable it in the server config, but it is deprecated there and removed in 9.x, so anything relying on it breaks at the next major upgrade. Plan the move to caching_sha2_password instead.
How do I list accounts using the old plugin?
Run SELECT user, host, plugin FROM mysql.user; — any row showing mysql_native_password needs an ALTER USER ... IDENTIFIED WITH caching_sha2_password.
The install still hangs after killing mysqld — what next?
Check /var/log/mysql/error.log for the bootstrap server's errors, then run sudo dpkg --configure -a to retry. If it stalls at the same point again, the log entry identifies the statement the init file chokes on.
Does a fresh Ubuntu install avoid the problem?
No. The same postinst bootstrap and the same 8.4 plugin default apply to a clean install, so a from-scratch reinstall reproduces both the hang and the ERROR 1524.