Dietpi: dietpi-update not working on Tinker Board.

[mukamuk1]

Creating a bug report/issue:

Required Information:

• DietPi version 6.18.14
  
  
  
  • Distro version stretch
  
  
• Kernel version Linux Tinkerbox 4.4.103+ #1 SMP Fri Jun 22 16:14:49 CST 2018 armv7l GNU/Linux
• SBC device Asus Tinker Board (armv7l)

Additional Information (if applicable):

Steps to reproduce:

1. run dietpi-update

Expected behaviour:

update should happen

Actual behaviour:

:~# dietpi-update
GUI-message pops up:

G_CHECK_FREESPACE: invalid integer from df result

Extra details:

Checked where this

invalid integer from df result

is in dietpi-update-script

Narrowed error to function: G_CHECK_FREESPACE()
And to line: local available_space=$(df -mP $input_path | sed -n 2p | awk '{print $4}')
And testing awk:

:~# awk
Segmentation fault

Tried to reinstall awk:

:~# apt-get install --reinstall awk
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package awk is a virtual package provided by:
  original-awk 2012-12-20-6
  mawk 1.3.3-17+b3
  gawk 1:4.1.4+dfsg-1
You should explicitly select one to install.

E: Package 'awk' has no installation candidate

And then tried to install:

:~# apt-get install --reinstall original-awk
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 2 not upgraded.
2 not fully installed or removed.
Need to get 0 B/66.1 kB of archives.
After this operation, 0 B of additional disk space will be used.
(Reading database ... 51998 files and directories currently installed.)
Preparing to unpack .../original-awk_2012-12-20-6_armhf.deb ...
Unpacking original-awk (2012-12-20-6) over (2012-12-20-6) ...
Setting up original-awk (2012-12-20-6) ...
Setting up mariadb-server-10.1 (10.1.37-0+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.37-0+deb9u1); however:
  Package mariadb-server-10.1 is not configured yet.

dpkg: error processing package mariadb-server (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 mariadb-server-10.1
 mariadb-server
E: Sub-process /usr/bin/dpkg returned an error code (1)

And then tested reinstall of mariadb-server

:~# apt-get install --reinstall mariadb-server
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 2 not upgraded.
2 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
E: Internal Error, No file name for mariadb-server:armhf

Error seems to be in mariadb-server-package.

And same issue seems to be behind my problems with magicmirror-software.

I can of course rewrite the code and pass dietpi-update (at least one step forward).

[MichaIng]

@mukamuk1
Thanks for your report.

Okay there seem to be two issues:

• awk throwing segmentation faults. Note that by default on Debian/DietPi systems, mawk is used/symlinked to awk location. When gawk is installed, it will override, e.g. as dependency. It is installed e.g. with MariaDB due to dependency tail.
  You can check, which awk is used by following the symlinks: readlink -f $(which awk)
  Since mariadb-server was already installed (?), it should be gawk, so try: apt-get install --reinstall gawk
• mariadb-server install fails, sabotaging further APT installs. Damn, I have to run further tests on this. Users reported the issue, when they moved their dietpi_userdata to an external drive. But we could never replicate this and sometimes it was clearly due to insufficient power supply on external drive, e.g. if powered only via USB, which does not work mostly with 2,5" SSDs/HDDs attached. Did you move your userdata to an external drive, does it have a dedicated power supply in case and which file system does it have?
  Although the error output looks different, as far as I remember: No file name for mariadb-server:armhf
  Could you check: systemctl status mariadb and/or journalctl -t mysqld and/or journalctl -u mysqld
  I had the idea that it might be related to one symlink in the line not having the required permissions. Possibly this helps then, a very failsafe way to chown every link in the row and final directory content:

systemctl stop mariadb
link='/var/lib/mysql'
chown -h mysql:mysql /var/lib/mysql
chown -RL mysql:mysql /var/lib/mysql
[[ -L /var/lib/mysql ]] && while [[ $link != $(readlink -f /var/lib/mysql) ]]
do
chown -h mysql:mysql "$(readlink $link)"
chown -RL mysql:mysql "$(readlink $link)"
link="$(readlink $link)"
done
unset link
systemctl start mariadb

I also found useful only on systems that can change the ownership of a symlink. So there seem file systems that support POSIX permissions, but not on symlinks 🤔. Have to check this with NTFS, where POSIX permissions are only supported via certain mount option. We set this by default with dietpi-drive_manager, but never checked, if this works for symlinks as well.

[mukamuk1]

gawk was installed and reinstall fails with same errors.

I have not transferred dietpi_userdata after installation and as far as I remember I have not used any usb-drives on this Dietpi-installation.

:~# systemctl status mariadb
● mariadb.service - MariaDB 10.1.37 database server
   Loaded: loaded (/lib/systemd/system/mariadb.service; disabled; vendor preset:
 enabled)
   Active: failed (Result: exit-code) since Wed 2018-12-12 14:07:53 E
ET; 8h ago
     Docs: man:mysqld(8)
           https://mariadb.com/kb/en/library/systemd/
  Process: 2781 ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WS
REP_START_POSITION (code=exited, status=1/FAILURE)
  Process: 2597 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR
= ||   VAR=`/usr/bin/galera_recovery`; [ $? -eq 0 ]   && systemctl set-environme
nt _WSREP_START_POSITION=$VAR || exit 1 (code=exited, status=0/SUCCESS)
  Process: 2551 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START
_POSITION (code=exited, status=0/SUCCESS)
  Process: 2460 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/ru
n/mysqld (code=exited, status=0/SUCCESS)
 Main PID: 2781 (code=exited, status=1/FAILURE)
   Status: "Starting Innodb crash recovery"

Dec 12 14:07:45 Tinkerbox mysqld[2781]: 2018-12-12 14:07:45 3069677568 [Note] /u
sr/sbin/mysqld (mysqld 10.1.37-MariaDB-0+deb9u1) starting as process 2781 ...
Dec 12 14:07:53 Tinkerbox systemd[1]: Failed to start MariaDB 10.1.37 da
tabase server.
Dec 12 14:07:53 Tinkerbox systemd[1]: mariadb.service: Failed with resul
t 'exit-code'.

And:

:~# journalctl -t mysqld
-- Logs begin at Thu 2016-11-03 19:16:43 EET, end at Wed 2018-12-12 22:19:11 EET
. --
Dec 12 14:07:45 Tinkerbox mysqld[2781]: 2018-12-12 14:07:45 3069677568 [Note] /u
sr/sbin/mysqld (mysqld 10.1.37-MariaDB-0+deb9u1) starting as process 2781 ...

Your fix did not help and logs contain no new errors :-/

This propably wont help but here is /var/log/mysql/error.log

root@Tinkerbox:/var/log/mysql# tail error.log
2018-12-12 22:27:38 3069952000 [Note] InnoDB: 128 rollback segment(s) are active.
2018-12-12 22:27:38 3069952000 [Note] InnoDB: Waiting for purge to start
2018-12-12 22:27:38 3069952000 [Note] InnoDB:  Percona XtraDB (http://www.percona.com) 5.6.41-84.1 started; log sequence number 1617511
2018-12-12 22:27:40 2483024704 [Note] InnoDB: Dumping buffer pool(s) not yet started
2018-12-12 22:27:40 3069952000 [Note] Plugin 'FEEDBACK' is disabled.
2018-12-12 22:27:40 3069952000 [Note] Recovering after a crash using tc.log
2018-12-12 22:27:40 3069952000 [Note] Starting crash recovery...
2018-12-12 22:27:40 3069952000 [Note] Crash recovery finished.
2018-12-12 22:27:40 3069952000 [Note] Server socket created on IP: '127.0.0.1'.
2018-12-12 22:27:40 3069952000 [ERROR] Fatal error: Can't open and lock privilege tables: Incorrect file format 'user'

[MichaIng]

@mukamuk1
Please try the following:

mysql_upgrade -f
apt-get install -y mariadb-server

Issue might be that the binaries were already updated, but not yet the tables. The first command should fix this. Then retry APT install to finish any other setup steps.

[mukamuk1]

root@Tinkerbox:/var/log/mysql# mysql_upgrade -f
Version check failed. Got the following error when calling the 'mysql' command line client
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2 "No such file or directory")
FATAL ERROR: Upgrade failed

[MichaIng]

Err, MySQL needs to run already.

Just searched the web for this error. Could you try this: https://stackoverflow.com/a/31695983

• mysqld --skip-grant-tables start daemon regardless of error. Since this runs in foreground, you need to do following steps on another terminal.
• mariadb to access MariaDB console
• repair table mysql.user use_frm; to repair the mentioned user table
• exit
• Interrupt <ctrl>+<c> the foreground mysqld, then try to start the service again: systemctl start mariadb

[mukamuk1]

Blaaah, every table in whole database was corrupted. Some of them I could repair but most of them was beond hope. So I removed mariadb from DietPi and re-installed it. Now everything is fine.

There must have been some kind of trouble with change from mysql to mariadb. I did dietpi-update few weeks ago and didnt use tinkerboard after that until today. You could re-test move from mysql to mariadb with tinkerboard (but that is probably wast of time).

[MichaIng]

@mukamuk1
The topic was lost somehow, whoopsie. However great you were able to fix it finally.

Hmm, the change from MySQL to MariaDB was actually no change. On Debian Stretch it was always MariaDB installed and used, even if mysql-server was actively selected for install.
The only thing we did is use the mariadb.service to start it instead of the old mysql ini.d service, but both execute exactly the same binary.

However possible that an unsuccessful APT upgrade or power loss or something else caused the corruption 🤔. Or it was simply an SDcard corruption, the most common reason on SDcards... It is definitely recommended to regularly do a database backup via mysqldump command.

---

I will mark this topic as closed, but feel free to use or reopen, if required.