VirtualBox VM running Debian 7

Ev,

Could you please enable general log in your config file before the upgrade, e.g.

[mysqld]

...

general-log

general-log-file=general.log

then run the upgrade and attach the log? If it happens to have password values that you don't want to make public, you can obfuscate them, but we need to see the exact command that is executed. Upgrade is not supposed to do that, no flags should be necessary.

Attached: general.log.tz

I'm afraid it doesn't look useful though. I see no queries affecting the user table and then as soon as version 5.5.47 starts I can see my automated processes getting a failed login for the root user:

50 Shutdown
/usr/sbin/mysqld, Version: 5.5.47-MariaDB-1~wheezy-wsrep-log (mariadb.org binary distribution, wsrep_25.12.r4f81026). started with:
Tcp port: 3306 Unix socket: /var/run/mysqld/mysqld.sock
Time Id Command Argument
/usr/sbin/mysqld, Version: 5.5.47-MariaDB-1~wheezy-wsrep-log (mariadb.org binary distribution, wsrep_25.12.r4f81026). started with:
Tcp port: 3306 Unix socket: /var/run/mysqld/mysqld.sock
Time Id Command Argument
160212 6:16:03 1 Connect root@localhost as anonymous on
1 Connect Access denied for user 'root'@'localhost' (using password: YES)

I will try this on a vanilla Debian 7 machine too and ensure I see the same behaviour.

Attached general.clean.log.gz which has all the automated process that access mysql turned off so the log is cleaner. Still the same result for me although you don;t see the mysql root user login failure until the end of the log file as that is when I tried to login manually.

On a basic Debian 7 install, upgrading from mariadb 5.5.46 to 5.5.47 I cannot reproduce the problem and the root password stay intact. I will generate some logs for that too.

Attached general.basedebian.log.gz which shows the upgrade from 5.5.46 to 5.5.47 on a fresh Debian 7 install. Both the install that fail on the other VM and this install have /root/.my.cnf file with the root user name and password in it. There is not much difference between the log output, but the base Debian 7 install does not reset the root password.

Is there any other logging that can be turned on?

Ev,

Does the problem happen if you use apt-get rather than direct dpkg?
Can you paste or attach the whole output of the upgrade process?

It would be much easier to investigate if we had access to the VM where you experience the issue, do you think you could arrange that? If it's possible, my public ssh key is here: https://launchpad.net/~elenst/+sshkeys

It still happened using apt-get!

I figured there could not be that many places in the mariadb source that were writing new root passwords, so I went looking for them and I found:

debian/dist/Debian/mariadb-server-5.5.postinst contains:

db_get mysql-server/root_password && rootpw="$RET"
if ! set_mysql_rootpw; then

So it appears that upgrading mariadb goes and resets the root password to the one stored by debconf-set-selections at original install time. On my machine I has since changed that password thus my problem when the mariadb install reset it for me!

So I have a better solution now than saving away the user table!! I can just ensure that the root password in the debconf database is set correctly before I upgrade mariadb, or maybe I can null it out and it will get ignored. I'll try that.

Is this really working as designed though?

Simply removing the password from the debconf database (which for security is no bad thing of course) fixes the problem.

Indeed, it's reproducible for me too – if you change the password in debconf-set-selections, it's picked up by upgrade.

Now, I am no expert in Debian tricks, so I don't know if it's supposed to be so. As a user, I would expect the setting from debconf-set-selections to be used when (and only when) a user would otherwise see the dialog screen inviting for the password; but apparently it's not so – if the password has already been set, the dialog does not appear upon upgrade, but the password from debconf is still used.

I'll assign it to otto who is the expert to give his opinion. However, I'm not sure it needs to be fixed – as I understand, otto is anyway getting rid of this password setting upon installation, replacing it with socket authentication, for now in Debian packages, and I suppose sooner or later it will get to MariaDB packages as well.

This might be related to MDEV-8457

I am closing this as "Won't fix" since we have had passwordless unix socket authentication since 10.4 and that is the "real" solution to get rid of password management in Debian maintainer scripts completely.