{"id":255,"date":"2026-10-13T09:50:06","date_gmt":"2026-10-13T07:50:06","guid":{"rendered":"https:\/\/www.cisilino.com\/?p=255"},"modified":"2026-10-29T20:00:32","modified_gmt":"2026-10-29T19:00:32","slug":"mysql-wont-start-debian-12","status":"publish","type":"post","link":"https:\/\/www.cisilino.com\/en\/2026\/10\/13\/mysql-wont-start-debian-12\/","title":{"rendered":"MySQL won’t start after a Debian 12 upgrade: cause and fix"},"content":{"rendered":"

The symptom: mysql.service in a failed state<\/h2>\n

MySQL won’t start: the service shows as failed and the log reports the error Can't read dir of '\/etc\/mysql\/mariadb.conf.d\/'<\/code>:<\/p>\n

\"MySQL<\/figure>\n
# service mysql status\n\u00d7 mysql.service - MySQL Community Server\n     Loaded: loaded (\/lib\/systemd\/system\/mysql.service; enabled; preset: enabled)\n     Active: failed (Result: exit-code)\n     Status: \"Server startup in progress\"\n\nmysqld: Can't read dir of '\/etc\/mysql\/mariadb.conf.d\/' (OS errno 2 - No such file or directory)\nmysqld: [ERROR] Stopped processing the 'includedir' directive in file \/etc\/mysql\/my.cnf at line 29.\nmysqld: [ERROR] Fatal error in defaults handling. Program aborted!\nsystemd[1]: Failed to start mysql.service - MySQL Community Server.<\/code><\/pre>\n
Checking the installed packages, MySQL is there as expected (mysql-community-server<\/code> 8.0 packages from the official Oracle repository):<\/p>\n
dpkg -l | grep mysql<\/code><\/pre>\n
The cause: the my.cnf alternative points to mariadb.cnf<\/h2>\n
On Debian the file \/etc\/mysql\/my.cnf<\/code> is not a real file but a link managed by update-alternatives<\/strong>. Several packages can register their own version and, in automatic mode, the one with the highest priority wins.<\/p>\n
During the upgrade the mariadb-common<\/strong> package was installed (and later removed), which registers \/etc\/mysql\/mariadb.cnf<\/code> with priority 500<\/strong>, higher than \/etc\/mysql\/mysql.cnf<\/code> (priority 300). The package was removed but not fully purged (state rc<\/code>), so its configuration stayed active. On line 29 of that file there is an include of \/etc\/mysql\/mariadb.conf.d\/<\/code>, a directory that does not exist. MySQL reads the configuration, cannot find the directory and stops, which is why MySQL won’t start.<\/p>\n
Good news:<\/strong> the data in \/var\/lib\/mysql<\/code> has not been touched. It is only a configuration problem.<\/p>\n
Diagnosis: check where my.cnf points<\/h2>\n
ls -l \/etc\/mysql\/my.cnf \/etc\/alternatives\/my.cnf\nupdate-alternatives --display my.cnf\nsed -n '25,32p' \/etc\/mysql\/my.cnf\ndpkg -l | grep -i mariadb<\/code><\/pre>\n
If this is the problem, the output will look like this:<\/p>\n
\/etc\/alternatives\/my.cnf -> \/etc\/mysql\/mariadb.cnf\n\/etc\/mysql\/my.cnf -> \/etc\/alternatives\/my.cnf\n\nmy.cnf - modalit\u00e0 automatica\n  la versione migliore del collegamento \u00e8 \/etc\/mysql\/mariadb.cnf\n  il collegamento attualmente punta a \/etc\/mysql\/mariadb.cnf\n\/etc\/mysql\/mariadb.cnf - priorit\u00e0 500\n\/etc\/mysql\/my.cnf.fallback - priorit\u00e0 100\n\/etc\/mysql\/mysql.cnf - priorit\u00e0 300\n\n!includedir \/etc\/mysql\/conf.d\/\n!includedir \/etc\/mysql\/mariadb.conf.d\/\n\nrc  mariadb-common   1:10.11.18-0+deb12u1   all   MariaDB common configuration files<\/code><\/pre>\n
Step-by-step fix<\/h2>\n
1. Back up the configuration<\/h3>\n
cp -a \/etc\/mysql \/root\/etc-mysql-backup-$(date +%F)<\/code><\/pre>\n
2. Remove the mariadb-common leftovers<\/h3>\n
The purge removes mariadb.cnf<\/code> and its entry in update-alternatives:<\/p>\n
apt purge mariadb-common<\/code><\/pre>\n
3. Point my.cnf back to mysql.cnf<\/h3>\n
update-alternatives --remove my.cnf \/etc\/mysql\/mariadb.cnf 2>\/dev\/null\nupdate-alternatives --set my.cnf \/etc\/mysql\/mysql.cnf<\/code><\/pre>\n
4. Check the configuration<\/h3>\n
update-alternatives --display my.cnf\ncat \/etc\/mysql\/my.cnf\nmy_print_defaults mysqld<\/code><\/pre>\n
Now my.cnf<\/code> must point to \/etc\/mysql\/mysql.cnf<\/code> and include \/etc\/mysql\/conf.d\/<\/code> and \/etc\/mysql\/mysql.conf.d\/<\/code>. If my_print_defaults mysqld<\/code> prints the parameters without errors, the configuration is correct.<\/p>\n
5. Start MySQL<\/h3>\n
systemctl start mysql\nsystemctl status mysql\njournalctl -u mysql -n 50 --no-pager<\/code><\/pre>\n
If MySQL won’t start and my.cnf is not a symbolic link<\/h2>\n
If \/etc\/mysql\/my.cnf<\/code> is a regular file or \/etc\/mysql\/mysql.cnf<\/code> does not exist, you can recreate the configuration by hand:<\/p>\n
mv \/etc\/mysql\/my.cnf \/etc\/mysql\/my.cnf.mariadb.bak\ncat > \/etc\/mysql\/my.cnf <<'EOF'\n!includedir \/etc\/mysql\/conf.d\/\n!includedir \/etc\/mysql\/mysql.conf.d\/\nEOF\nmkdir -p \/etc\/mysql\/conf.d\nsystemctl start mysql<\/code><\/pre>\n
Quick temporary fix when MySQL won’t start<\/h2>\n
If you need to bring the database back online right away, just create the missing directory. It is only a stopgap, though. MySQL would keep reading the configuration meant for MariaDB. Better to apply the complete fix as soon as possible.<\/p>\n
mkdir \/etc\/mysql\/mariadb.conf.d && systemctl start mysql<\/code><\/pre>\n
How to stop it happening again<\/h2>\n
It is worth finding out which upgrade installed MariaDB, by looking at the apt history:<\/p>\n
grep -i -B3 -A3 mariadb \/var\/log\/apt\/history.log*<\/code><\/pre>\n
To stop mariadb-common<\/code> being reinstalled in the future you can block it with an APT pin at a negative priority:<\/p>\n
cat > \/etc\/apt\/preferences.d\/no-mariadb <<'EOF'\nPackage: mariadb-*\nPin: release *\nPin-Priority: -1\nEOF<\/code><\/pre>\n
After every major upgrade it is also good practice to check the state of the alternative with update-alternatives --display my.cnf<\/code>. Before the next upgrade, read the Debian 12 release notes<\/a> for known issues. A related case is MySQL 5.7 in Docker protected with nftables<\/a>.<\/p>\n
Frequently asked questions<\/h2>\n
Will I lose my database data?<\/h3>\n
No. The problem only concerns the configuration files in \/etc\/mysql<\/code>; the data in \/var\/lib\/mysql<\/code> stays intact.<\/p>\n
Why did Debian choose mariadb.cnf?<\/h3>\n
Because the my.cnf<\/code> alternative was in automatic mode and mariadb.cnf<\/code> has priority 500, higher than the 300 of mysql.cnf<\/code>. With update-alternatives --set<\/code> the choice becomes manual and no longer changes by itself.<\/p>\n
Does it apply to Ubuntu too?<\/h3>\n
Yes, the update-alternatives<\/code> mechanism for my.cnf<\/code> is the same on Ubuntu and on the other Debian-derived distributions.<\/p>\n
Conclusion<\/h2>\n
The error “Can’t read dir of \/etc\/mysql\/mariadb.conf.d\/”<\/strong> after a Debian upgrade does not mean MySQL is damaged. It means a leftover MariaDB configuration has stayed active through update-alternatives. By removing mariadb-common<\/code> with apt purge<\/code> and setting my.cnf<\/code> back to mysql.cnf<\/code>, MySQL works normally again. If MySQL won’t start after an upgrade, check update-alternatives first.<\/p><\/p>\n","protected":false},"excerpt":{"rendered":"
After a Debian 12 upgrade MySQL won’t start and the logs mention mariadb.conf.d. How to identify the cause and fix it without touching your data.<\/p>\n","protected":false},"author":1,"featured_media":747,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"wpai_generated_summary":"","footnotes":""},"categories":[361],"tags":[300,296,292,332],"class_list":["post-255","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-servers-databases","tag-debian-12-en","tag-mariadb-en","tag-mysql-en","tag-upgrade"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t