Package: mariadb-server-10.0 Version: 10.0.26-1 Dear Maintainer,
purging mariadb-server-10.0 (or maybe mariadb-server-core-10.0 is the culprit, not sure) while /var/lib/mysql is a mountpoint with an ext4 filesystem behaves a little bit schizophrenic: It of course fails to remove /var/lib/mysql/ if I explicitly answer it's question about the removal of all databases with "Yes": rm: cannot remove '/var/lib/mysql': Device or resource busy dpkg: error processing package mariadb-server-10.0 (--purge): subprocess installed post-removal script returned error exit status 1 (This IMHO shouldn't make the uninstallation fail.) But it also leaves quite some clutter in there: 13/0/0 root@c6:pts/37 20:28:14 [/var/lib/mysql] # ls -l total 110624 -rw-rw---- 1 mysql mysql 16384 Jul 3 20:39 aria_log.00000001 -rw-rw---- 1 mysql mysql 52 Jul 3 20:39 aria_log_control -rw-r--r-- 1 root root 0 Jul 3 20:39 debian-10.0.flag -rw-rw---- 1 mysql mysql 50331648 Jul 3 20:39 ib_logfile0 -rw-rw---- 1 mysql mysql 50331648 Jul 3 20:37 ib_logfile1 -rw-rw---- 1 mysql mysql 12582912 Jul 3 20:39 ibdata1 -rw-rw---- 1 mysql mysql 0 Jul 3 20:39 multi-master.info drwx------ 2 mysql root 4096 Jul 3 20:39 mysql -rw------- 1 root root 15 Jul 3 20:39 mysql_upgrade_info drwx------ 2 mysql mysql 4096 Jul 3 20:39 performance_schema It though managed somehow to remove /var/lib/mysql/lost+found/ which contains file system related data and no databases, hence should not be removed when the user agrees to have all databases removed. Before purging the package, the directory looked like this: 12/0/0 root@c6:pts/37 20:24:39 [/var/lib/mysql] # ls -la total 110632 drwx------ 5 mysql mysql 4096 Jul 3 20:25 . drwxr-xr-x 113 root root 4096 Jul 3 20:24 .. -rw-rw---- 1 mysql mysql 16384 Jul 3 20:25 aria_log.00000001 -rw-rw---- 1 mysql mysql 52 Jul 3 20:25 aria_log_control -rw-r--r-- 1 root root 0 Jul 3 20:24 debian-10.0.flag -rw-rw---- 1 mysql mysql 50331648 Jul 3 20:25 ib_logfile0 -rw-rw---- 1 mysql mysql 50331648 Jul 3 20:24 ib_logfile1 -rw-rw---- 1 mysql mysql 12582912 Jul 3 20:25 ibdata1 drwx------ 2 mysql mysql 4096 Jul 3 20:13 lost+found -rw-rw---- 1 mysql mysql 0 Jul 3 20:25 multi-master.info drwx------ 2 mysql root 4096 Jul 3 20:25 mysql drwx------ 2 mysql mysql 4096 Jul 3 20:24 performance_schema This is similar (but probably unrelated) to mysql-server's ancient, but never fixed bug #608938. (Actually I found this bug when I checked if MariaDB is also affected by #608938 after it had been prematurely closed.) I'm totally unsure about which severity this issue should get as some aspects (unexpected data loss) would speak for some RC severity, but then again, this only happens if all other data in that directory is, well, should be removed anyways, so any potentially saved data from some fsck is probably no more needed either. That way it should be probably minor. Then again, it can make the package fail to be removed, which is surely not minor. So I'm staying with the default severity. Feel free to change it. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.6.0-trunk-amd64 (SMP w/8 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
