Derek Coleman & Associates Inc logoDerek Coleman & Associates Inc

Home / Support / MySQL 8 on Ubuntu 24.04 LTS

MySQL 8 on Ubuntu 24.04 LTS — Support & Quick Start

Production-ready MySQL 8 on Ubuntu 24.04 LTS. Hardened image, per-VM generated root password, ready for connections minutes after deploy.

Fixed on image version 2026.916.1341 (published 2026-09-16)

First boot now authenticates its own `FLUSH PRIVILEGES` (it used to run unauthenticated and die with ERROR 1045), verifies `root` against the running server and only then writes /root/.mysql-initial-password and the completion marker. The password survives reboots.

If you deployed this VM before 2026-09-16, it came from the older image and is not changed by the new publication — redeploy from the current Marketplace version, or apply the one-time repair below:

  1. On that image the root password in /root/.mysql-initial-password applies on the FIRST boot only. If this VM has never been rebooted the file still holds the live password: sign in now with `mysql -u root -p` and store it safely.
  2. Stop the old first-boot script from regenerating a password it can no longer apply, by writing the completion marker it failed to write (taken from the fixed script, not sweep-run).
  3. Already rebooted and the password was never stored? Reset root with MySQL's documented `--init-file` procedure, or email support and we will walk you through it. MySQL itself is running normally throughout — `systemctl status firstboot` showing `failed` was the defect, not a broken database.
sudo mkdir -p /etc/app && sudo touch /etc/app/.firstboot-complete

Image change: see the pull request.

Source: the Marketplace live version set for this offer, read from Partner Center on 2026-09-16. New deployments take the newest version by default.

At a glance

Application ports3306 (MySQL) — server binds 127.0.0.1 until you change bind-address
Admin credential filesudo cat /root/.mysql-initial-password
Sign in asroot (root@localhost, caching_sha2_password)
Service(s)mysql
Configuration/etc/mysql/mysql.conf.d/mysqld.cnf (bind-address)
Logs/var/log/mysql/error.log; journalctl -u mysql -f
VersionMySQL 8.0 (Ubuntu 24.04 package)
PlatformUbuntu 24.04 LTS

Quick start

  1. SSH into the VM with the username and key you chose at deploy.
  2. MySQL 8 runs as the `mysql` systemd service on port 3306, bound to 127.0.0.1 (Ubuntu default); the in-image ufw allows 3306, the NSG does not until you open it.
  3. Connect locally with `mysql -u root -p` using the generated password (command below), create your application user and schema, then set bind-address in /etc/mysql/mysql.conf.d/mysqld.cnf and open 3306 to your app tier only.

First login / credentials

This image generates its admin credential on the VM at first boot — nothing is pre-set. SSH into the VM with the username + key you chose at deploy, then print the generated credential:

ssh <your-username>@<VM-IP>
sudo cat /root/.mysql-initial-password

Sign in as root (root@localhost, caching_sha2_password).

  1. Print the generated root password from the file.
  2. Connect locally: mysql -u root -p (plain `sudo mysql` is refused — root uses password auth on this image).
  3. Create your application user and schema, change the root password (ALTER USER), and delete the file.

This is the MySQL root password set at first boot (root@localhost uses caching_sha2_password, so plain `sudo mysql` is refused). Connect with `mysql -u root -p`, change it with ALTER USER, and delete the file once stored securely.

Troubleshooting

SymptomCheckFix
`sudo mysql` says access denied for root@localhostsudo cat /root/.mysql-initial-passwordRoot has a password on this image (not auth_socket): use `mysql -u root -p`.
Remote client cannot connectbind-address in /etc/mysql/mysql.conf.d/mysqld.cnf; NSG rule for 3306Both must be opened deliberately; the in-image firewall already allows 3306.

Still stuck?

Email support@dcassociatesgroup.com (response within 1 business day) or send a message via the contact form. Include the offer name, VM size, region, and any log output — sudo journalctl -u <service> -n 100 usually tells the story.