Some reinstalls of software after upgrade from Buster to Bullseye fail

fhals · 24 September 2021 11:08

Hi,

I successfully followed the excellent upgrade hints up to the suggested software reinstall after upgrading from Buster to Bullseye.

dietpi-software reinstall 38 40 47 48 56 83 84 85 88 89 93 114 143

At least I got stuck on Lighttpd’s mod openssl and php/Redis.

#### Details:
- Date           | Fri Sep 24 12:11:45 CEST 2021
- Bug report     | 0f17ae44-c4db-409c-af26-9d1f1f4fe98f
- DietPi version | v7.6.2 (MichaIng/master)
- Image creator  | DietPi Core Team
- Pre-image      | Meveric
- Hardware       | Odroid C2 (aarch64) (ID=12)
- Kernel version | `Linux DietPi 3.16.85+ #1 SMP PREEMPT Tue Jun 30 19:02:35 CEST 2020 aarch64 GNU/Linux`
- Distro         | bullseye (ID=6)
- Command        | `lighty-enable-mod openssl`
- Exit code      | 2
- Software title | DietPi-Software
#### Additional logs:

Ignoring unknown module: openssl
Run “service lighttpd force-reload” to enable changes


and

```text
#### Details:
- Date           | Fri Sep 24 12:32:17 CEST 2021
- Bug report     | 0f17ae44-c4db-409c-af26-9d1f1f4fe98f
- DietPi version | v7.6.2 (MichaIng/master)
- Image creator  | DietPi Core Team
- Pre-image      | Meveric
- Hardware       | Odroid C2 (aarch64) (ID=12)
- Kernel version | `Linux DietPi 3.16.85+ #1 SMP PREEMPT Tue Jun 30 19:02:35 CEST 2020 aarch64 GNU/Linux`
- Distro         | bullseye (ID=6)
- Command        | `apt-get -qq --allow-change-held-packages install php7.4-fpm php7.4-apcu php7.4-curl php7.4-gd php7.4-mbstring php7.4-xml php7.4-zip php7.4-mysql php7.4-redis`
- Exit code      | 100
- Software title | DietPi-Software
#### Additional logs:

E: Package ‘php7.4-redis’ has no installation candidate


Any idea how to get them back to work without breaking the dietpi-standards will be appreciated.

Thanks & regards
Frans

Joulinar · 24 September 2021 11:39

for Lighttpd, do you use SSL/HTTPS ?

fhals · 24 September 2021 13:30

yes, I’m using the dietpi-letsencrypt.

Joulinar · 24 September 2021 13:33

ok could you check if following module is installed.

apt install lighttpd-mod-openssl

MichaIng · 24 September 2021 13:55

It’s a bug our end. It should be:

lighty-enable-mod ssl

You can select “Change command” from the error prompt and adjust it accordingly. I’ll send a live-patch.

But php7.4-redis is “provided” by php-redis, so that it should be selected automatically. Works fine here .

fhals · 24 September 2021 14:40

Thank you- jumped over the (open)ssl-hurdle with changing the command.
Should I try the same with

apt-get -qq --allow-change-held-packages install php7.4-fpm php7.4-apcu php7.4-curl php7.4-gd php7.4-mbstring php7.4-xml php7.4-zip php7.4-mysql php7.4-redis

and leave out the ‘php7.4-redis’ for further investigation?

Joulinar · 24 September 2021 16:51

maybe it’s missing on apt source. Let`s check where the other packages are download from. Can you try following

dpkg -l php7.4-curl

fhals · 24 September 2021 17:44

Quick reply:

dpkg-query: no packages found matching php7.4-curl

Edit:
This is the output of dpkg -l regarding PHP:

ii  php-common                      2:84+0~20210621.36+debian9~1.gbp28513e          all          Common files for PHP packages
ii  php-igbinary                    3.2.6+2.0.8-1+0~20210913.27+debian9~1.gbp64b0ea arm64        igbinary PHP serializer
ii  php-redis                       5.3.4+4.3.0-1+0~20210329.35+debian9~1.gbpdc7ead arm64        PHP extension for interfacing with Redis
ii  php8.0-common                   8.0.10-1+0~20210826.23+debian9~1.gbp9ab3fd      arm64        documentation, examples and common module for PHP
ii  php8.0-igbinary                 3.2.6+2.0.8-1+0~20210913.27+debian9~1.gbp64b0ea arm64        igbinary PHP serializer
ii  php8.0-redis                    5.3.4+4.3.0-1+0~20210329.35+debian9~1.gbpdc7ead arm64        PHP extension for interfacing with Redis

Joulinar · 25 September 2021 11:25

hmm maybe PHP to be removed completely. But let’s check with our developer first.

MichaIng
can you have a look. It seems there are still packages from Ondrej’s PHP repository installed. Should they be purged completely or just removed?

MichaIng · 27 September 2021 13:02

There are some PHP8.0 packages as well which should be purged:

apt purge php8.0-common php8.0-igbinary php8.0-redis

then reinstall the others, accepting the downgrade (of php-common, I guess):

apt install --reinstall --allow-downgrade php-common php7.4-igbinary php7.4-redis

fhals · 27 September 2021 14:51

Thank you both, php reinstalled successfully.
Had to leave out the downgrade option (’–allow-downgrade is not understood in combination with the other options’)

Feels like I’m close to final bullseye, but

mariadb fails to start.

Reinstallation went fine:

 Step: Installing MariaDB: Persistent cached file-per-table database server

[ INFO ] DietPi-Software | Preparing database directory at: /mnt/dietpi_userdata/mysql
[ INFO ] DietPi-Software | /mnt/dietpi_userdata/mysql exists, will migrate containing databases
[  OK  ] DietPi-Software | rm -Rf /var/lib/mysql
[  OK  ] DietPi-Software | ln -s /mnt/dietpi_userdata/mysql /var/lib/mysql
[ INFO ] DietPi-Software | APT install for: mariadb-server, please wait...
[  OK  ] DietPi-Software | APT install for: mariadb-server
[ INFO ] DietPi-Software | Removing obsolete SysV mysql service
[  OK  ] DietPi-Software | update-rc.d mysql remove

Job for mariadb.service failed because a fatal signal was delivered to the control process.
See “systemctl status mariadb.service” and “journalctl -xe” for details.

Not much details, journalctl shows:

Sep 27 16:41:59 DietPi systemd[1]: Starting MariaDB 10.5.11 database server...
░░ Subject: A start job for unit mariadb.service has begun execution
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ A start job for unit mariadb.service has begun execution.
░░
░░ The job identifier is 23352.
Sep 27 16:42:00 DietPi systemd[1]: mariadb.service: Main process exited, code=killed, status=4/ILL
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ An ExecStart= process belonging to unit mariadb.service has exited.
░░
░░ The process' exit code is 'killed' and its exit status is 4.
Sep 27 16:42:00 DietPi systemd[1]: mariadb.service: Failed with result 'signal'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ The unit mariadb.service has entered the 'failed' state with result 'signal'.
Sep 27 16:42:00 DietPi systemd[1]: Failed to start MariaDB 10.5.11 database server.
░░ Subject: A start job for unit mariadb.service has failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ A start job for unit mariadb.service has finished with a failure.
░░
░░ The job identifier is 23352 and the job result is failed.

systemctl:

systemctl status mariadb.service
● mariadb.service - MariaDB 10.5.11 database server
     Loaded: loaded (/lib/systemd/system/mariadb.service; disabled; vendor preset: enabled)
     Active: activating (auto-restart) (Result: signal) since Mon 2021-09-27 16:47:05 CEST; 715ms ago
       Docs: man:mariadbd(8)
             https://mariadb.com/kb/en/library/systemd/
    Process: 36577 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=exited, status=0/SUCCESS)
    Process: 36579 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
    Process: 36582 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= ||   VAR=`cd /usr/bin/..; /usr/bin/galera_recovery`; [ $? -eq 0 ]   && systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1 (code=exited, status=0/SUCCESS)
    Process: 36644 ExecStart=/usr/sbin/mariadbd $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION (code=killed, signal=ILL)
   Main PID: 36644 (code=killed, signal=ILL)

My external HD is up and running, my pre-upgrade databases are still there. Symbolic link at /var/lib/mysql sends me there too.
I can’t detect any hint in the failed status, do you?

Thanks & regards, Frans

Joulinar · 27 September 2021 21:38

ok let’s try the usual debug steps

systemctl restart mariadb.service
journalctl -u mariadb
cat /var/log/mysql/error.log
readlink /var/lib/mysql
readlink -f /var/lib/mysql

fhals · 28 September 2021 06:50

Sorry, nothing new here:

systemctl restart mariadb.service
Job for mariadb.service failed because a fatal signal was delivered to the control process.
See "systemctl status mariadb.service" and "journalctl -xe" for details.

journalctl -u mariadb
Journal file /var/log/journal/fbd586f15aab42cdab084639a1d2b2cc/system.journal is truncated, ignoring file.
-- Journal begins at Tue 2021-09-28 08:39:39 CEST, ends at Tue 2021-09-28 08:41:05 CEST. --
Sep 28 08:39:44 DietPi systemd[1]: mariadb.service: Scheduled restart job, restart counter is at 8001.
Sep 28 08:39:44 DietPi systemd[1]: Stopped MariaDB 10.5.11 database server.
Sep 28 08:39:44 DietPi systemd[1]: Starting MariaDB 10.5.11 database server...
Sep 28 08:39:45 DietPi systemd[1]: mariadb.service: Main process exited, code=killed, status=4/ILL
Sep 28 08:39:45 DietPi systemd[1]: mariadb.service: Failed with result 'signal'.
Sep 28 08:39:45 DietPi systemd[1]: Failed to start MariaDB 10.5.11 database server.
Repeating from here with increasing counter

error.log is empty, while user mysql has write access. No more mysql.logs:

cat /var/log/mysql/error.log
ls -la /var/log
drwxr-s---   2 mysql    adm                   60 Feb 17  2019 mysql
ls -la /var/log/mysql
-rw-rw----  1 mysql adm    0 Sep 24 11:29 error.log

readlink /var/lib/mysql
/mnt/dietpi_userdata/mysql

readlink -f /var/lib/mysql
/mnt/usb_1/dietpi_userdata/mysql

Joulinar · 28 September 2021 11:35

could you try to reboot and repeat the test?

Unfortunately no real error message present at the moment.

fhals · 28 September 2021 12:51

Did it again.
Exactly the same- no results.

When I compare /lib/systemd/system/mariadb.service with my last running backup version, both are nearly identical.

Small diff:

NEW:

[Install]
WantedBy=multi-user.target

CapabilityBoundingSet=CAP_IPC_LOCK CAP_DAC_OVERRIDE CAP_AUDIT_WRITE
PrivateDevices=false

OLD:

[Install]
WantedBy=multi-user.target
Alias=mysql.service
Alias=mysqld.service

CapabilityBoundingSet=CAP_IPC_LOCK
PrivateDevices=true

fhals · 28 September 2021 17:01

Information on Mariadb failing to start without errors is barely to find.
Should I try to uninstall and install it again instead of reinstall (https://dietpi.com/phpbb/viewtopic.php?f=11&t=8729&start=10)?
I have a full backup of all databases, but would like to keep my nextcloud installation.

MichaIng · 28 September 2021 17:30

Can you try whether it shows more output when switching to console log:

echo 'skip_log_error=1' > /etc/mysql/mariadb.conf.d/99-disable-file-logging.cnf
systemctl restart mariadb
sleep 5
journalctl -u mariadb

fhals · 28 September 2021 17:59

Sep 28 19:58:27 DietPi systemd[1]: Starting MariaDB 10.5.11 database server...
Sep 28 19:58:28 DietPi sh[48435]: error: Found option without preceding group in config file: /etc/mysql/mariadb.conf.d/99-disable-file-logging.cnf at line: 1
Sep 28 19:58:28 DietPi mariadbd[48493]: error: Found option without preceding group in config file: /etc/mysql/mariadb.conf.d/99-disable-file-logging.cnf at line: 1
Sep 28 19:58:28 DietPi systemd[1]: mariadb.service: Main process exited, code=killed, status=4/ILL
Sep 28 19:58:28 DietPi systemd[1]: mariadb.service: Failed with result 'signal'.
Sep 28 19:58:28 DietPi systemd[1]: Failed to start MariaDB 10.5.11 database server.

Edit:
Just added a ‘[mysqld]’ prior the skip_log_error=1.
No shown errors, like before:

Sep 28 20:01:15 DietPi systemd[1]: Starting MariaDB 10.5.11 database server...
Sep 28 20:01:15 DietPi systemd[1]: mariadb.service: Main process exited, code=killed, status=4/ILL
Sep 28 20:01:15 DietPi systemd[1]: mariadb.service: Failed with result 'signal'.
Sep 28 20:01:15 DietPi systemd[1]: Failed to start MariaDB 10.5.11 database server.

Joulinar · 28 September 2021 19:41

quite strange that there is no output at all

MichaIng · 28 September 2021 19:45

Ah yes sorry, the config section was missing. Hmm, and if you start it manually from console:

sudo -u mariadb /usr/sbin/mariadbd