[SOLVED] MariaDB fails to start after moving the user data to HDD

Troubleshooting
1

Hi!

My HDD finally died, so I’ve got a new one and decided to do the full clean install.
After installation is done I’ve installed RPi monitor and Nextcloud via dietpi-software. At this point, Nextcloud works fine.
Then I’m moving user data to HDD via DietPi Drive Manager and now mysql service (MariaDB in this case) won’t start. Something got broken. How do I fix it?

root@dietpi:~# service mysql start
Job for mysql.service failed because the control process exited with error code.
See “systemctl status mysql.service” and “journalctl -xe” for details.



root@dietpi:~# systemctl status mysql.service
● mysql.service - LSB: Start and stop the mysql database server daemo
n
Loaded: loaded (/etc/init.d/mysql; generated; vendor preset: enabled)
Active: failed (Result: exit-code) since Tue 2018-06-12 20:17:04 M
SK; 39s ago
Docs: man:systemd-sysv-generator(8)
Process: 9632 ExecStart=/etc/init.d/mysql start (code=exited, status=1
/FAILURE)

Jun 12 20:17:04 dietpi /etc/init.d/mysql[10262]: 0 processes alive and ‘/usr/bi
n/mysqladmin --defaults-file=/etc/mysql/debian.cnf ping’ resulted in
Jun 12 20:17:04 dietpi /etc/init.d/mysql[10262]: [61B blob data]
Jun 12 20:17:04 dietpi /etc/init.d/mysql[10262]: error: ‘Can’t connect to local
MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2 “No such file or d
irectory”)’
Jun 12 20:17:04 dietpi /etc/init.d/mysql[10262]: Check that mysqld is running a
nd that the socket: ‘/var/run/mysqld/mysqld.sock’ exists!
Jun 12 20:17:04 dietpi /etc/init.d/mysql[10262]:
Jun 12 20:17:04 dietpi mysql[9632]: Starting MariaDB database server: mysqld .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . failed!
Jun 12 20:17:04 dietpi systemd[1]: mysql.service: Control process exite
d, code=exited status=1
Jun 12 20:17:04 dietpi systemd[1]: Failed to start LSB: Start and stop
the mysql database server daemon.
Jun 12 20:17:04 dietpi systemd[1]: mysql.service: Unit entered failed s
tate.e–
Jun 12 20:17:04 dietpi systemd[1]: mysql.service: Failed with result ‘e
xit-code’.

and

Jun 12 20:06:00 dietpi mysqld_safe[1243]: Starting mysqld daemon with d
atabases from /var/lib/mysql
Jun 12 20:06:00 dietpi mysqld[1248]: 2018-06-12 20:06:00 1996001280 [No
te] /usr/sbin/mysqld (mysqld 10.1.23-MariaDB-9+deb9u1) starting as process 1247
…
Jun 12 20:06:01 dietpi mysqld[1248]: 2018-06-12 20:06:01 1996001280 [No
te] InnoDB: Using mutexes to ref count buffer pool pages
Jun 12 20:06:01 dietpi mysqld[1248]: 2018-06-12 20:06:01 1996001280 [No
te] InnoDB: The InnoDB memory heap is disabled
Jun 12 20:06:01 dietpi mysqld[1248]: 2018-06-12 20:06:01 1996001280 [No
te] InnoDB: Mutexes and rw_locks use GCC atomic builtins
Jun 12 20:06:01 dietpi mysqld[1248]: 2018-06-12 20:06:01 1996001280 [No
te] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
Jun 12 20:06:01 dietpi mysqld[1248]: 2018-06-12 20:06:01 1996001280 [No
te] InnoDB: Compressed tables use zlib 1.2.8
Jun 12 20:06:01 dietpi mysqld[1248]: 2018-06-12 20:06:01 1996001280 [No
te] InnoDB: Using Linux native AIO
Jun 12 20:06:01 dietpi mysqld[1248]: 2018-06-12 20:06:01 1996001280 [No
te] InnoDB: Using generic crc32 instructions
Jun 12 20:06:01 dietpi mysqld[1248]: 2018-06-12 20:06:01 1996001280 [No
te] InnoDB: Initializing buffer pool, size = 128.0M
Jun 12 20:06:01 dietpi mysqld[1248]: 2018-06-12 20:06:01 1996001280 [No
te] InnoDB: Completed initialization of buffer pool
Jun 12 20:06:01 dietpi mysqld[1248]: 2018-06-12 20:06:01 1996001280 [No
te] InnoDB: Highest supported file format is Barracuda.
Jun 12 20:06:01 dietpi mysqld[1248]: 2018-06-12 20:06:01 1996001280 [No
te] InnoDB: 128 rollback segment(s) are active.
Jun 12 20:06:01 dietpi mysqld[1248]: 2018-06-12 20:06:01 1996001280 [No
te] InnoDB: Waiting for purge to start
Jun 12 20:06:01 dietpi mysqld[1248]: 2018-06-12 20:06:01 1996001280 [No
te] InnoDB: Percona XtraDB (> http://www.percona.com> ) 5.6.35-80.0 started; log se
quence number 3163481
Jun 12 20:06:01 dietpi mysqld[1248]: 2018-06-12 20:06:01 1447031616 [No
te] InnoDB: Dumping buffer pool(s) not yet started
Jun 12 20:06:01 dietpi mysqld[1248]: 2018-06-12 20:06:01 1996001280 [No
te] Plugin ‘FEEDBACK’ is disabled.
Jun 12 20:06:02 dietpi mysqld[1248]: 2018-06-12 20:06:02 1996001280 [No
te] Server socket created on IP: ‘127.0.0.1’.
Jun 12 20:06:02 dietpi mysqld[1248]: 2018-06-12 20:06:02 1996001280 [No
te] /usr/sbin/mysqld: ready for connections.
Jun 12 20:06:02 dietpi mysqld[1248]: Version: '10.1.23-MariaDB-9+deb9u1
’ socket: ‘/var/run/mysqld/mysqld.sock’ port: 3306 Raspbian 9.0
Jun 12 20:06:02 dietpi mysql[1059]: Starting MariaDB database server: mysqld …
Jun 12 20:06:02 dietpi systemd[1]: Started LSB: Start and stop the mysql databa
se server daemon.
– Subject: Unit mysql.service has finished start-up
– Defined-By: systemd
– Support: > Debian -- User Support

– Unit mysql.service has finished starting up.

– The start-up result is done.
Jun 12 20:06:02 dietpi /etc/mysql/debian-start[1319]: Upgrading MySQL tables if
necessary.

Thanks!

2

Reinstalling mariadb also didn’t help:

Details:

  • Date | Tue 12 Jun 21:00:39 MSK 2018
  • BR sent? | 0 : 0a687e84-f52a-4faa-ab97-932ac09c68f6
  • DietPi version | v6.9
  • Img creator | 0
  • Pre-image | Raspbian Lite
  • SBC device | RPi 3 Model B (armv7l) (index=3)
  • Distro | stretch (index=4)
  • Command | G_AGI: mariadb-server
  • Exit code | 100
  • Software title | DietPi-Software

Expected behaviour:

Actual behaviour:

Steps to reproduce:

Additional Information:

Additional logs:

Log file contents:
Selecting previously unselected package libwrap0:armhf.
Preparing to unpack .../15-libwrap0_7.6.q-26_armhf.deb ...
Unpacking libwrap0:armhf (7.6.q-26) ...
Selecting previously unselected package socat.
Preparing to unpack .../16-socat_1.7.3.1-2+deb9u1_armhf.deb ...
Unpacking socat (1.7.3.1-2+deb9u1) ...
Setting up mysql-common (5.8+1.0.2) ...
update-alternatives: using /etc/mysql/my.cnf.fallback to provide /etc/mysql/my.cnf (my.cnf) in auto mode
Setting up mariadb-common (10.1.23-9+deb9u1) ...
update-alternatives: using /etc/mysql/mariadb.cnf to provide /etc/mysql/my.cnf (my.cnf) in auto mode
Selecting previously unselected package mariadb-server-10.1.
(Reading database ... 20814 files and directories currently installed.)
Preparing to unpack .../mariadb-server-10.1_10.1.23-9+deb9u1_armhf.deb ...
/var/lib/mysql: found previous version 10.1
Unpacking mariadb-server-10.1 (10.1.23-9+deb9u1) ...
Selecting previously unselected package mariadb-server.
Preparing to unpack .../mariadb-server_10.1.23-9+deb9u1_all.deb ...
Unpacking mariadb-server (10.1.23-9+deb9u1) ...
Setting up libatomic1:armhf (6.3.0-18+rpi1+deb9u1) ...
Setting up libjemalloc1 (3.6.0-9.1) ...
Setting up libicu57:armhf (57.1-6+deb9u2) ...
Setting up libxml2:armhf (2.9.4+dfsg1-2.2+deb9u2) ...
Processing triggers for libc-bin (2.24-11+deb9u3) ...
Setting up libaio1:armhf (0.3.110-3) ...
Setting up galera-3 (25.3.19-2+rpi1) ...
Processing triggers for systemd (232-25+deb9u2) ...
Setting up libreadline5:armhf (5.2+dfsg-3) ...
Setting up libdbi-perl (1.636-1+b1) ...
Setting up liblzo2-2:armhf (2.08-1.2) ...
Setting up libwrap0:armhf (7.6.q-26) ...
Setting up mariadb-server-core-10.1 (10.1.23-9+deb9u1) ...
Setting up libarchive13:armhf (3.2.2-2) ...
Setting up socat (1.7.3.1-2+deb9u1) ...
Setting up mariadb-client-core-10.1 (10.1.23-9+deb9u1) ...
Setting up mariadb-client-10.1 (10.1.23-9+deb9u1) ...
Setting up mariadb-server-10.1 (10.1.23-9+deb9u1) ...
dpkg: error processing package mariadb-server-10.1 (--configure):
subprocess installed post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of mariadb-server:
mariadb-server depends on mariadb-server-10.1 (>= 10.1.23-9+deb9u1); however:
Package mariadb-server-10.1 is not configured yet.

dpkg: error processing package mariadb-server (--configure):
dependency problems - leaving unconfigured
Processing triggers for libc-bin (2.24-11+deb9u3) ...
Processing triggers for systemd (232-25+deb9u2) ...
Errors were encountered while processing:
mariadb-server-10.1
mariadb-server
E: Sub-process /usr/bin/dpkg returned an error code (1)


\

3

Solved by manually removing all the leftovers from mariadb and reinstalling it.

4

MonZon
Sorry for missing reply. Thanks for you report of issue and found solution.

DietPi creates a symlink from /var/lib/mysql (default database location) to /mnt/dietpi_userdata/mysql. When moving the userdata location, /mnt/dietpi_userdata will be a symlink itself to the new location, thus /mnt/dietpi_userdata/mysql should then still be reachable and starting-up MariaDB should find it’s database tables at the same path, even that it contains an additional symlink.
I will do some test and try to replicate or verify our current method works when following your steps.

Another issue I could imaging is missing user permissions support of target file system. dietpi-drive_manager just gives a hint when target fs is fat (which definitely does not allow user permissions): https://github.com/Fourdee/DietPi/blob/master/dietpi/dietpi-drive_manager#L1118-L1134
The finally used dietpi-set_userdata does a permission check but silently allows to move userdata, if test fails: https://github.com/Fourdee/DietPi/blob/master/dietpi/func/dietpi-set_userdata#L72-L79
€: Added for v6.10:
https://github.com/Fourdee/DietPi/issues/1846

If this was your issue or not, we definitely need to have some consistency there, leaving permissions test to final script and simply disallow moving userdata on failing this, since many of our scripts and software installations simply expects this to work!