Closed Phil1988 closed 3 years ago
Joulinar
commented
3 years ago Hi,
pls provide following information
systemctl restart mariadb.service
journalctl -u mariadb
cat /var/log/mysql/error.log
readlink /var/lib/mysql
readlink -f /var/lib/mysqlhowever the status doesn't looks good
Status: "InnoDB: Error: Database page corruption on disk or a failed file read of tablespace ./ibdata1 page
MichaIng
commented
3 years ago Additionally to verify whether there is actual filesystem corruption:
dmesg -l emerg,alert,crit,err
Phil1988
commented
3 years ago hey,
the systemctl restart mariadb.service is already there, for the rest:
root@DietPi:~# journalctl -u mariadb
-- Logs begin at Fri 2021-06-25 09:29:44 CEST, end at Fri 2021-06-25 14:04:49 CE
ST. --
Jun 25 09:29:55 DietPi systemd[1]: Starting MariaDB 10.1.48 database server...
Jun 25 09:29:56 DietPi mysqld[1157]: 2021-06-25 9:29:56 140653996760448 [Note]
/usr/sbin/mysqld (mysqld 10.1.48-MariaDB-0+deb9u2) starting as process 1157 ...
Jun 25 09:29:56 DietPi systemd[1]: mariadb.service: Main process exited,
code=killed, status=6/ABRT
Jun 25 09:29:56 DietPi systemd[1]: Failed to start MariaDB 10.1.48 datab
ase server.
Jun 25 09:29:56 DietPi systemd[1]: mariadb.service: Unit entered failed
state.
Jun 25 09:29:56 DietPi systemd[1]: mariadb.service: Failed with result '
signal'.
Jun 25 09:30:01 DietPi systemd[1]: mariadb.service: Service hold-off time over,
scheduling restart.
Jun 25 09:30:01 DietPi systemd[1]: Stopped MariaDB 10.1.48 database server.
Jun 25 09:30:01 DietPi systemd[1]: Starting MariaDB 10.1.48 database server...
Jun 25 09:30:02 DietPi mysqld[1557]: 2021-06-25 9:30:02 139890696887680 [Note]
/usr/sbin/mysqld (mysqld 10.1.48-MariaDB-0+deb9u2) starting as process 1557 ...
Jun 25 09:30:02 DietPi systemd[1]: mariadb.service: Main process exited,
code=killed, status=6/ABRT
Jun 25 09:30:02 DietPi systemd[1]: Failed to start MariaDB 10.1.48 datab
ase server.
Jun 25 09:30:02 DietPi systemd[1]: mariadb.service: Unit entered failed state.
Jun 25 09:30:02 DietPi systemd[1]: mariadb.service: Failed with result 'signal'.
Jun 25 09:30:07 DietPi systemd[1]: mariadb.service: Service hold-off time over, scheduling restart.
Jun 25 09:30:07 DietPi systemd[1]: Stopped MariaDB 10.1.48 database server.
Jun 25 09:30:07 DietPi systemd[1]: Starting MariaDB 10.1.48 database server...
Jun 25 09:30:08 DietPi mysqld[1678]: 2021-06-25 9:30:08 140481425399168 [Note] /usr/sbin/mysqld (mysqld 10.1.48-MariaDB-0+deb9u2) starting as process 1678 ...
Jun 25 09:30:08 DietPi systemd[1]: mariadb.service: Main process exited, code=killed, status=6/ABRT
Jun 25 09:30:08 DietPi systemd[1]: Failed to start MariaDB 10.1.48 database server.
Jun 25 09:30:08 DietPi systemd[1]: mariadb.service: Unit entered failed state.
Jun 25 09:30:08 DietPi systemd[1]: mariadb.service: Failed with result 'signal'.
Jun 25 09:30:13 DietPi systemd[1]: mariadb.service: Service hold-off time over, scheduling restart.
Jun 25 09:30:13 DietPi systemd[1]: Stopped MariaDB 10.1.48 database server.
Jun 25 09:30:13 DietPi systemd[1]: Starting MariaDB 10.1.48 database server...
Jun 25 09:30:14 DietPi mysqld[1796]: 2021-06-25 9:30:14 140077151415680 [Note] /usr/sbin/mysqld (mysqld 10.1.48-MariaDB-0+deb9u2) starting as process 1796 ...
Jun 25 09:30:14 DietPi systemd[1]: mariadb.service: Main process exited, code=killed, status=6/ABRT
Jun 25 09:30:14 DietPi systemd[1]: Failed to start MariaDB 10.1.48 database server.
[...]cat /var/log/mysql/error.log
InnoDB: End of page dump
2021-06-25 14:06:28 7ff8b21b7d80 InnoDB: uncompressed page, stored checksum in field1 1420198940, calculated checksums for field1: crc32 3306546772, innodb 1420198940, none 3735928559, stored checksum in field2 2279621922, calculated checksums for field2: crc32 3306546772, innodb 1848301123, none 3735928559, page LSN 13 2577993519, low 4 bytes of LSN at page end 2577993499, page number (if stored to page already) 5, space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: page type 7 meaning TRX_SYS
InnoDB: Page may be a transaction system page
2021-06-25 14:06:28 140706116763008 [Note] InnoDB: It is also possible that your operating system has corrupted its own file cache and rebooting your computer removes the error. If the corrupt page is an index page. You can also try to fix the corruption by dumping, dropping, and reimporting the corrupt table. You can use CHECK TABLE to scan your table for corruption. Please refer to http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html for information about forcing recovery.
2021-06-25 14:06:28 140706116763008 [ERROR] InnoDB: Ending processing because of a corrupt database page.
2021-06-25 14:06:28 7ff8b21b7d80 InnoDB: Assertion failure in thread 140706116763008 in file ha_innodb.cc line 21944
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
210625 14:06:28 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
Server version: 10.1.48-MariaDB-0+deb9u2
key_buffer_size=16777216
read_buffer_size=131072
max_used_connections=0
max_threads=153
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 352468 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x2e)[0x55afba15bc7e]
/usr/sbin/mysqld(handle_fatal_signal+0x3bd)[0x55afb9ca9bdd]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x110e0)[0x7ff8b1e280e0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcf)[0x7ff8b0995fff]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7ff8b099742a]
/usr/sbin/mysqld(+0x83e2db)[0x55afb9f292db]
/usr/sbin/mysqld(+0x98b1b8)[0x55afba0761b8]
/usr/sbin/mysqld(+0x9a56e2)[0x55afba0906e2]
/usr/sbin/mysqld(+0x9a698b)[0x55afba09198b]
/usr/sbin/mysqld(+0x9863db)[0x55afba0713db]
/usr/sbin/mysqld(+0x937ccf)[0x55afba022ccf]
/usr/sbin/mysqld(+0x91e270)[0x55afba009270]
/usr/sbin/mysqld(+0x91f90a)[0x55afba00a90a]
/usr/sbin/mysqld(+0x834f41)[0x55afb9f1ff41]
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x62)[0x55afb9cabdc2]
/usr/sbin/mysqld(+0x43bba5)[0x55afb9b26ba5]
/usr/sbin/mysqld(_Z11plugin_initPiPPci+0x7da)[0x55afb9b2820a]
/usr/sbin/mysqld(+0x386733)[0x55afb9a71733]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x4fb)[0x55afb9a7608b]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7ff8b09832e1]
/usr/sbin/mysqld(_start+0x2a)[0x55afb9a6a06a]
The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains
information that should help you find out what is causing the crash.
root@DietPi:~# readlink /var/lib/mysql
/mnt/dietpi_userdata/mysql
root@DietPi:~# readlink -f /var/lib/mysql
/mnt/dietpi_userdata/mysqlroot@DietPi:~# dmesg -l emerg,alert,crit,err
[ 0.939447] sd 0:0:0:0: [sda] Assuming drive cache: write through
[ 1.531565] piix4_smbus 0000:00:07.3: SMBus Host Controller not enabled!Okay, it seems to be only a database-wise corruption. Please try the following:
/mnt/dietpi_userdata/mysql to somewhere else as backup.echo -e '[mysqld]\ninnodb_force_recovery=1' > /etc/mysql/mariadb.conf.d/99-recovery.cnf
systemctl restart mariadbecho -e '[mysqld]\ninnodb_force_recovery=2' > /etc/mysql/mariadb.conf.d/99-recovery.cnf
systemctl restart mariadbHere some more info on the recovery levels: https://mariadb.com/kb/en/innodb-recovery-modes/
mysqldump -A > /mnt/dietpi_userdata/mysqldump.sqlmysqlcheck -A # check only
mysqlcheck -A -r # check and repairWhich software uses MariaDB in your case?
Phil1988
commented
3 years ago I tired step 3 untill iteration 20... I think this is going nowhere :(
root@DietPi:~# echo -e '[mysqld]\ninnodb_force_recovery=20' > /etc/mysql/mariadb.conf.d/99-recovery.cnf
root@DietPi:~# systemctl restart mariadb
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.So I stoped and didnt do step 4 or 5.
I am using nextcloud.
As I am using a VM I did a snapshot before the update.
So if I can help you finding the reason to prevent this for others and make the update more stable, please let me know what to do :)
Joulinar
commented
3 years ago To be honest, this has nothing to do with DietPi update function. You got a corrupted database file. This could have multiple reasons. At least on a VM we probably could exclude file system issue. But maybe unclean poweroff could lead to this.
What you could try is to restore the snapshot, perform an apt update && apt upgrade, check if all is working fine and if this is the case perform DietPi update.
Phil1988
commented
3 years ago OK, I will restore the snapshot, test and feedback :)
Phil1988
commented
3 years ago You are right Joulinar!
I did restore the snapshot, performed an apt update && apt upgrade, checked if all is working fine and performed a DietPi update.
Everything working now.
And you were right with your idea. There really was a poweroff here in my region so that could be the cause.
Sorry guys for taking your time and thanks for helping me! :)
Joulinar
commented
3 years ago you are welcome, better to check on such issues. 😃
Btw: you should think of migrating to Debian Buster as you still running Stretch. Sooner or later Nextcloud might gonna drop support for old MariaDB version 10.1. As well next Debian version Bullseye will be released soon and Stretch become oldold.
MichaIng
commented
3 years ago
'[mysqld]\ninnodb_force_recovery=20'
Valid levels are only 1-6 😉. Good idea to recover a backup/snapshort, I totally forgot to ask about that, great that it worked 👍.
Phil1988
commented
3 years ago you are welcome, better to check on such issues. 😃
Btw: you should think of migrating to Debian Buster as you still running Stretch. Sooner or later Nextcloud might gonna drop support for old MariaDB version 10.1. As well next Debian version Bullseye will be released soon and Stretch become oldold.
"Migration" sounds so nice and easy :D
I think this would mean to setup everything from stretch scratch right?
So start over with a new VM and do all the settings again.
For me that would mean 2 weeks of work ;D I will give this a try, also I think that it will most likely fail: https://dietpi.com/phpbb/viewtopic.php?p=18988#p18988
But having snapshots as a backup makes it possible to give it a try
MichaIng
commented
3 years ago I will give this a try, also I think that it will most likely fail
TL;DR: Definitely worth to give it a try!
Based on my Wheezy => Jessie => Stretch distro upgrade experiences, I would have assumed to same, that it most likely fails at some point, but I am surprised that in every case where we got a feedback about the upgrade Stretch => Buster, it went well. I personally upgrade my systems directly to the new testing suite, after a release, when there is not difference between release and testing yet, so cannot say something about Stretch => Buster => Bullseye, but it seems to have improved a lot, hence became a quite reliable alternative to setup from scratch 🙂.
Joulinar
commented
3 years ago Yes you could update from Stretch to Buster without performing a reinstall. Just have a look to following forum post https://dietpi.com/phpbb/viewtopic.php?p=18988#p18988
But we can't give a guarantee 😉 Therefore do a backup before
Phil1988
commented
3 years ago Just as a feedback:
instructions on https://dietpi.com/phpbb/viewtopic.php?p=18988#p18988
sed -i 's/stretch/buster/' /etc/apt/sources.list
sed -i 's/stretch/buster/' /etc/apt/sources.list.d/*.list
# Also check other /etc/apt/sources.list.d/*.list files that might need to be updated
apt update
apt upgrade
apt full-upgrade
apt autopurge
/boot/dietpi/func/dietpi-obtain_hw_model
. /boot/dietpi/func/dietpi-globalsworked with no issues 👍
MichaIng
commented
3 years ago Awesome, many thanks and great to know. I feel quite confident that we can guide Stretch users through a distro upgrade when dropping Stretch support. Plan is to migrate Stretch systems to a "stretch" branch first, to block DietPi updates to newest incompatible version, which was one purpose of the updater change with DietPi v7.0. There we add a script which guides or performs an interactive distro upgrade (interactive, so that all APT questions need to be answered/confirmed interactively) and, when succeeded, migrates them back to the master branch to update to latest DietPi version.
Joulinar
commented
3 years ago thx for sharing. So basically you are ready to update to Bullseye that might be released end of July 2021 🤣
MichaIng
commented
3 years ago One thing we should take care of: When PHP was installed, Ondrej's repo should be removed revert to the PHP version from the main Debian repository. There are too many reports of users, when installing the PHP meta packages, ending up with PHP 8 (unintentionally), two parallel PHP instances, and will then get additionally PHP 8.1 once release 😄.
@Phil1988
That might be reasonable for you as well. If you have MariaDB installed, I guess PHP as well? It's not necessary, as long as it's taken care to keep using/installing packages like php7.3-fpm or upgrading (and changing the webserver config accordingly) intentionally to PHP 7.4 or PHP 8.0. But when installing packages like php-fpm, it will always pull the newest version, like php8.0-fpm currently and php8.1-fpm in the future and all related dependencies. Again okay when migrating PHP applications and webserver, but it's not yet 100% supported by all software titles, our phpBB instance is still running into the one or the other PHP 8 related error, especially when extensions are used 😉.
rm /etc/apt/sources.list.d/dietpi-php.list
rm /etc/apt/trusted.gpg.d/dietpi-php.gpg
rm /etc/apt/preferences.d/dietpi-php
rm /etc/apt/preferences.d/dietpi-openssl
/boot/dietpi/func/dietpi-set_software apt-cache clean
apt update
apt upgradeIt is possible that the apt upgrade asks whether a package downgrade should be done. This should be confirmed then to avoid failures of G_AGUG calls which are cancelled on such APT questions.
Phil1988
commented
3 years ago currently I am using: redis-server apache2 mariadb nextcloud mosquitto nodered pihole blynkserver home-assistant
I have not seen a problem since the upgrade so far.
I already did a apt upgrade before without the commands you posted.
The php versions pulled have been 7.3.
Should I perform
rm /etc/apt/sources.list.d/dietpi-php.list
rm /etc/apt/trusted.gpg.d/dietpi-php.gpg
rm /etc/apt/preferences.d/dietpi-php
rm /etc/apt/preferences.d/dietpi-openssl
/boot/dietpi/func/dietpi-set_software apt-cache clean
apt update
apt upgradeanyways?
and to @Joulinar: I am happily here to test any upgrade processes to bullseye on my system for you :D
Joulinar
commented
3 years ago let's wait for @MichaIng before doing any further steps. But in theory you could use same procedure to update to Bullseye. It's already possible and there shouldn't be any surprises as Bullseye is already in a freeze mode and there is no major development happen anymore.
MichaIng
commented
3 years ago Jep, upgrade to Bullseye works the same way. If you do so, Ondrej's repository needs to be removed and PHP and the webserver need to be reinstalled, as Bullseye does not ship PHP7.3 anymore but PHP7.4 instead. Also on Buster, just as a pre-caution against unintended PHP upgrades, I'd do the steps to remove Ondrej's repository: This was only added to maintain support for Debian Stretch, else most PHP application would have needed to be disabled, as most of them dropped support for PHP7.2 and below for a while.
Phil1988
commented
3 years ago Well I am not able to do it as I am not confident enough to try and error :D
1 . I am still not sure if I should perform
rm /etc/apt/sources.list.d/dietpi-php.list
rm /etc/apt/trusted.gpg.d/dietpi-php.gpg
rm /etc/apt/preferences.d/dietpi-php
rm /etc/apt/preferences.d/dietpi-openssl
/boot/dietpi/func/dietpi-set_software apt-cache clean
apt update
apt upgrade2 . I am not sure, where I added ondrejs php repo (but I am pretty sure that I did that).
In theory I should do something like ppa-purge ppa:ondrej/php7-7.3 right?
As I am not sure, I tried to search the used ondrejs repositorys with apt-cache policy | grep ondrej whit 0 results.
It might also work to just sudo add-apt-repository --remove ppa:ondrej/php but I am not sure.
So it would be really kind if you can tell me, what would be the right way to do so.
3 . For the update to Bullseye: My limited knowledge, tells me, I should do something like this ( :D ) :
sed -i 's|buster|bullseye|' /etc/apt/sources.list
sed -i 's|bullseye/updates|bullseye-security|' /etc/apt/sources.list
apt update
apt upgrade
apt full-upgrade
apt autopurge
/boot/dietpi/func/dietpi-obtain_hw_model
. /boot/dietpi/func/dietpi-globals4 . To install PHP and the webserver, should I just apt-get -s install php7.4
and install the webserver from the dietpi-software?
Sorry for those questions and many thanks for your help!
Joulinar
commented
3 years ago You already have Apache2 installed. Therefore no need to install any other web server. For the update to Bullseye, it should looks like this
sed -i 's/buster/bullseye/' /etc/apt/sources.list
sed -i 's/buster/bullseye/' /etc/apt/sources.list.d/*.list
# Also check other /etc/apt/sources.list.d/*.list files that might need to be updated
apt update
apt upgrade
apt full-upgrade
apt autopurge
/boot/dietpi/func/dietpi-obtain_hw_model
. /boot/dietpi/func/dietpi-globalsit needs to be a / instead of | 😉
But first, let's ask @MichaIng if he could help to ensure using correct PHP package 😃
MichaIng
commented
3 years ago And yes, please do the dietpi-php.list removal in any case with the steps I provided. PPA stuff is more Ubuntu stuff, basically it depends on how the repository was added. Since we add it manually by creating this files, it also needs to be removed manually by removing the created files 😉.
Phil1988
commented
3 years ago Hmmm... well the ppa stuff would be handy, as I dont know, where the created php (ondrej) files are sitting :D
I did the following so far: (the dietpi-php.list stuff)
The bullseye upgrade:
now the full upgrade
The I autopurged it:
and finally:
root@DietPi:~# /boot/dietpi/func/dietpi-obtain_hw_model
root@DietPi:~# . /boot/dietpi/func/dietpi-globals
root@DietPi:~# echo $G_DISTRO_NAME
bullseye
root@DietPi:~# rebootWhat works now is:
Not working is the nextcloud. If gives me this when I try to access via browser
Internal Server Error
The server encountered an internal error and was unable to complete your request.
Please contact the server administrator if this error reappears multiple times, please include the technical details below in your report.
More details can be found in the server log.Interesstingly, the nextcloud seems to be uninstalled:
Joulinar
commented
3 years ago can you check if the database is running systemctl staus mariadb.service
What happen if you do ncc maintenance:mode --off
It looks like MariaDB meta package has been removed
Entfernen von mariadb-common (1:10.5.10-2) ...
update-alternatives: /etc/mysql/my.cnf.fallback wird verwendet, um /etc/mysql/my.cnf (my.cnf) im automatischen Modus bereitzustellen
Entfernen von mysql-common (5.8+1.0.7) ...Thank you Jouinar for editing my post to make collapsable spoilers (I'll remember this from now).
for MariaDB:
root@DietPi:~# systemctl staus mariadb.servic
Unknown command verb staus.soo kind of "broken".... so this is not anymore soo off-topic :D
Nextcloud:
root@DietPi:~# ncc maintenance:mode --off
An unhandled exception has been thrown:
Doctrine\DBAL\DBALException: Failed to connect to the database: An exception occurred in driver: SQLSTATE[HY000] [2002] No such file or directory in /var/www/nextcloud/lib/private/DB/Connection.php:72
Stack trace:
#0 /var/www/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(1449): OC\DB\Connection->connect()
#1 /var/www/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(892): Doctrine\DBAL\Connection->getWrappedConnection()
#2 /var/www/nextcloud/lib/private/DB/Connection.php(202): Doctrine\DBAL\Connection->executeQuery('SELECT * FROM `...', Array, Array, NULL)
#3 /var/www/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Query/QueryBuilder.php(206): OC\DB\Connection->executeQuery('SELECT * FROM `...', Array, Array)
#4 /var/www/nextcloud/lib/private/DB/QueryBuilder/QueryBuilder.php(217): Doctrine\DBAL\Query\QueryBuilder->execute()
#5 /var/www/nextcloud/lib/private/AppConfig.php(345): OC\DB\QueryBuilder\QueryBuilder->execute()
#6 /var/www/nextcloud/lib/private/AppConfig.php(110): OC\AppConfig->loadConfigValues()
#7 /var/www/nextcloud/lib/private/AppConfig.php(301): OC\AppConfig->getApps()
#8 /var/www/nextcloud/lib/private/legacy/OC_App.php(949): OC\AppConfig->getValues(false, 'installed_versi...')
#9 /var/www/nextcloud/lib/private/Server.php(668): OC_App::getAppVersions()
#10 /var/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php(155): OC\Server->OC\{closure}(Object(OC\Server))
#11 /var/www/nextcloud/3rdparty/pimple/pimple/src/Pimple/Container.php(118): OC\AppFramework\Utility\SimpleContainer->OC\AppFramework\Utility\{closure}(Object(Pimple\Container))
#12 /var/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php(122): Pimple\Container->offsetGet('OC\\Memcache\\Fac...')
#13 /var/www/nextcloud/lib/private/ServerContainer.php(156): OC\AppFramework\Utility\SimpleContainer->query('OC\\Memcache\\Fac...', true)
#14 /var/www/nextcloud/lib/private/Server.php(1677): OC\ServerContainer->query('OC\\Memcache\\Fac...')
#15 /var/www/nextcloud/lib/private/Server.php(1017): OC\Server->getMemCacheFactory()
#16 /var/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php(155): OC\Server->OC\{closure}(Object(OC\Server))
#17 /var/www/nextcloud/3rdparty/pimple/pimple/src/Pimple/Container.php(118): OC\AppFramework\Utility\SimpleContainer->OC\AppFramework\Utility\{closure}(Object(Pimple\Container))
#18 /var/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php(122): Pimple\Container->offsetGet('OCP\\Lock\\ILocki...')
#19 /var/www/nextcloud/lib/private/ServerContainer.php(156): OC\AppFramework\Utility\SimpleContainer->query('OCP\\Lock\\ILocki...', true)
#20 /var/www/nextcloud/lib/private/Server.php(1977): OC\ServerContainer->query('OCP\\Lock\\ILocki...')
#21 /var/www/nextcloud/lib/private/Files/View.php(118): OC\Server->getLockingProvider()
#22 /var/www/nextcloud/lib/private/Server.php(395): OC\Files\View->__construct()
#23 /var/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php(155): OC\Server->OC\{closure}(Object(OC\Server))
#24 /var/www/nextcloud/3rdparty/pimple/pimple/src/Pimple/Container.php(118): OC\AppFramework\Utility\SimpleContainer->OC\AppFramework\Utility\{closure}(Object(Pimple\Container))
#25 /var/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php(122): Pimple\Container->offsetGet('OC\\Files\\Node\\H...')
#26 /var/www/nextcloud/lib/private/ServerContainer.php(156): OC\AppFramework\Utility\SimpleContainer->query('OC\\Files\\Node\\H...', true)
#27 /var/www/nextcloud/lib/private/Server.php(1324): OC\ServerContainer->query('OC\\Files\\Node\\H...')
#28 /var/www/nextcloud/lib/base.php(595): OC\Server->boot()
#29 /var/www/nextcloud/lib/base.php(1091): OC::init()
#30 /var/www/nextcloud/console.php(49): require_once('/var/www/nextcl...')
#31 /var/www/nextcloud/occ(11): require_once('/var/www/nextcl...')So at least mariaDB is missing and I think that the nextcloud can be reactivated with your knowledge, but all the data might be gone right? I took a snapshot before doing the upgrade, so no worries here. But If I can help you making this process more solid (for other people/future reference) I am here as your testperson :D
Joulinar
commented
3 years ago Sorry there was a typo
systemctl status mariadb.service
Phil1988
commented
3 years ago You are right.. I also didnt see the missing "T". I did that but that is also not working
root@DietPi:~# systemctl status mariadb.service
Unit mariadb.service could not be found.Also pihole does not work correctly after upgrading.
I get a DNS service not running message on the status board:
At least here is something I was able to fix on my own. Maybe that might help you:
I tried to reconfigure it, but that didnt work:
Joulinar
commented
3 years ago Yes isof was removed as well during update. And in general an issue is mosquitto. It doesn't seem to offer Bullseye repository yet. Probably this source list would need to be changed back to Buster. Strange that there are packages removed that are still required. Interesting behaviour.
The database could be more tricky. Can you check what is still installed.
dpkg -l | grep maria
MichaIng
commented
3 years ago MariaDB was remove during full-upgrade, for some reason. The 10.3 server and client packages should have been, but not the meta packages:
apt install mariadb-server
dietpi-services dietpi_controlled mariadblosf was then autoremoved, as it was initially pulled as dependency for MariaDB.
Also the Mosquitto repository does not have a Bullseye suite yet: https://repo.mosquitto.org/debian/dists/
sed -i 's/bullseye/buster/' /etc/apt/sources.list.d/*mosquitto*.list
apt updateAnother package which might want to reinstall:
apt install fdiskroot@DietPi:~# dpkg -l | grep maria
rc mariadb-client-10.1 10.1.48-0+deb9u2 amd64 MariaDB database client binaries
rc mariadb-client-10.3 1:10.3.29-0+deb10u1 amd64 MariaDB database client binaries
rc mariadb-server-10.1 10.1.48-0+deb9u2 amd64 MariaDB database server binaries
rc mariadb-server-10.3 1:10.3.29-0+deb10u1 amd64 MariaDB database server binariesmariaDB seems to be there , but its still inactive now:
root@DietPi:~# systemctl status mariadb.service
● mariadb.service - MariaDB 10.5.10 database server
Loaded: loaded (/lib/systemd/system/mariadb.service; disabled; vendor preset: enabled)
Active: inactive (dead)
Docs: man:mariadbd(8)
https://mariadb.com/kb/en/lBut Nextcloud is still not working. Do I have to restart/reinstall it?
EDIT: After your @MichaIng edit, I did also that:
root@DietPi:~# dietpi-services dietpi_controlled mariadb
DietPi-Services
─────────────────────────────────────────────────────
Mode: dietpi_controlled mariadb
[ OK ] DietPi-Services | dietpi_controlled : mariadb
root@DietPi:~#and:
root@DietPi:~# sed -i 's/bullseye/buster/' /etc/apt/sources.list.d/*mosquitto*.list
root@DietPi:~# apt update
OK:1 https://deb.debian.org/debian bullseye InRelease
OK:2 https://deb.debian.org/debian bullseye-updates InRelease
OK:3 https://deb.debian.org/debian-security bullseye-security InRelease
OK:4 https://deb.debian.org/debian bullseye-backports InRelease
OK:5 https://repo.mosquitto.org/debian buster InRelease
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Aktualisierung für 1 Paket verfügbar. Führen Sie »apt list --upgradable« aus, um es anzuzeigen.Also nextcloud is still installed at the software. I checked the services and could not find nextcloud and only inactive (dead) mariadb:
root@DietPi:~# dietpi-services status
DietPi-Services
─────────────────────────────────────────────────────
Mode: status
[ OK ] DietPi-Services | redis-server : active (running) since Fri 2021-07-09 21:28:39 CEST; 12h ago
[ INFO ] DietPi-Services | mariadb : inactive (dead)
[ OK ] DietPi-Services | apache2 : active (running) since Fri 2021-07-09 21:28:40 CEST; 12h ago
[ OK ] DietPi-Services | mosquitto : active (running) since Fri 2021-07-09 21:28:40 CEST; 12h ago
[ OK ] DietPi-Services | node-red : active (running) since Fri 2021-07-09 21:28:40 CEST; 12h ago
[ OK ] DietPi-Services | blynkserver : active (running) since Fri 2021-07-09 21:28:40 CEST; 12h ago
[ OK ] DietPi-Services | home-assistant : active (running) since Fri 2021-07-09 21:28:40 CEST; 12h ago
[ OK ] DietPi-Services | cron : active (running) since Fri 2021-07-09 21:28:40 CEST; 12h ago
[ OK ] DietPi-Services | ssh : active (running) since Fri 2021-07-09 21:28:39 CEST; 12h ago
[ OK ] DietPi-Services | pihole-FTL : active (running) since Sat 2021-07-10 09:35:57 CEST; 35min ago
[ INFO ] DietPi-Services | dietpi-vpn : inactive (dead)
[ OK ] DietPi-Services | dietpi-ramlog : active (exited) since Fri 2021-07-09 21:28:29 CEST; 12h ago
[ OK ] DietPi-Services | dietpi-preboot : active (exited) since Fri 2021-07-09 21:28:29 CEST; 12h ago
[ OK ] DietPi-Services | dietpi-boot : active (exited) since Fri 2021-07-09 21:28:39 CEST; 12h ago
[ OK ] DietPi-Services | dietpi-postboot : active (exited) since Fri 2021-07-09 21:28:39 CEST; 12h ago
[ INFO ] DietPi-Services | dietpi-wifi-monitor : inactive (dead)
root@DietPi:~#MariaDB is core, otherwise Nextcloud will not be working at all.
Let's have a look
systemctl restart mariadb.service
journalctl -u mariadb
cat /var/log/mysql/error.log
readlink /var/lib/mysql
readlink -f /var/lib/mysqlI just started mariadb now:
root@DietPi:~# systemctl start mariadb.service
root@DietPi:~# systemctl status mariadb.service
● mariadb.service - MariaDB 10.5.10 database server
Loaded: loaded (/lib/systemd/system/mariadb.service; disabled; vendor preset: enabled)
Active: active (running) since Sat 2021-07-10 10:18:02 CEST; 1s ago
Docs: man:mariadbd(8)
https://mariadb.com/kb/en/library/systemd/
Process: 29533 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=exited, status=0/SUCCESS)
Process: 29534 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
Process: 29537 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: 29616 ExecStartPost=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
Process: 29618 ExecStartPost=/etc/mysql/debian-start (code=exited, status=0/SUCCESS)
Main PID: 29601 (mariadbd)
Status: "Taking your SQL requests now..."
Tasks: 20 (limit: 4666)
Memory: 126.1M
CPU: 468ms
CGroup: /system.slice/mariadb.service
├─29601 /usr/sbin/mariadbd
├─29619 /bin/bash /etc/mysql/debian-start
├─29621 /usr/bin/mysql_upgrade --defaults-extra-file=/etc/mysql/debian.cnf --version-check
├─29622 grep -E -v ^(1|@had|ERROR (1051|1054|1060|1061|1146|1347|1348))
├─29623 logger -p daemon warn -i -t/etc/mysql/debian-start
├─29637 sh -c '/usr/bin/mysql' --defaults-file=/tmp/mysql_upgrade-z6FvG0 --database=mysql --batch --force --silent < /tmp/sql2gQtB0 2>&1
└─29638 /usr/bin/mysql --defaults-file=/tmp/mysql_upgrade-z6FvG0 --database=mysql --batch --force --silent
Jul 10 10:18:02 DietPi mariadbd[29601]: 2021-07-10 10:18:02 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
Jul 10 10:18:02 DietPi mariadbd[29601]: 2021-07-10 10:18:02 0 [Note] InnoDB: 10.5.10 started; log sequence number 59587254717; transaction id 99858462
Jul 10 10:18:02 DietPi mariadbd[29601]: 2021-07-10 10:18:02 0 [Note] Plugin 'FEEDBACK' is disabled.
Jul 10 10:18:02 DietPi mariadbd[29601]: 2021-07-10 10:18:02 0 [Note] InnoDB: Loading buffer pool(s) from /mnt/dietpi_userdata/mysql/ib_buffer_pool
Jul 10 10:18:02 DietPi mariadbd[29601]: 2021-07-10 10:18:02 0 [Note] Server socket created on IP: '127.0.0.1'.
Jul 10 10:18:02 DietPi mariadbd[29601]: 2021-07-10 10:18:02 0 [Note] Reading of all Master_info entries succeeded
Jul 10 10:18:02 DietPi mariadbd[29601]: 2021-07-10 10:18:02 0 [Note] Added new Master_info '' to hash table
Jul 10 10:18:02 DietPi mariadbd[29601]: 2021-07-10 10:18:02 0 [Note] /usr/sbin/mariadbd: ready for connections.
Jul 10 10:18:02 DietPi mariadbd[29601]: Version: '10.5.10-MariaDB-2' socket: '/run/mysqld/mysqld.sock' port: 3306 Debian 11
Jul 10 10:18:02 DietPi systemd[1]: Started MariaDB 10.5.10 database server.
root@DietPi:~#And NC is working 👍
I will do your things @Joulinar and edit afterwards:
Edit: I did so anyways and everything was "OK". rebooting now.
Joulinar
commented
3 years ago No need if MariaDB is working now. Just do a reboot test
Phil1988
commented
3 years ago It looking good to me:
The only thing not good right now is, that I get this message:
cron will probably be done in a short (5min) time... and the imagick its an seperate problem that came up with upgrading to buster.
I did:
but the message is still there.
Joulinar
commented
3 years ago imagick can be ignored. Usually it is not needed.
Cron can be checked as follow systemctl status cron.service
Phil1988
commented
3 years ago cron seems to be running for me 👍
I might just have to wait
Phil1988
commented
3 years ago The maintenance mode seems to not work:
root@DietPi:~# ncc maintenance:mode --on
An unhandled exception has been thrown:
Doctrine\DBAL\DBALException: Failed to connect to the database: An exception occurred in driver: could not find driver in /var/www/nextcloud/lib/private/DB/Connection.php:72
Stack trace:
#0 /var/www/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(1449): OC\DB\Connection->connect()
#1 /var/www/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(892): Doctrine\DBAL\Connection->getWrappedConnection()
#2 /var/www/nextcloud/lib/private/DB/Connection.php(202): Doctrine\DBAL\Connection->executeQuery()
#3 /var/www/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Query/QueryBuilder.php(206): OC\DB\Connection->executeQuery()
#4 /var/www/nextcloud/lib/private/DB/QueryBuilder/QueryBuilder.php(217): Doctrine\DBAL\Query\QueryBuilder->execute()
#5 /var/www/nextcloud/lib/private/AppConfig.php(345): OC\DB\QueryBuilder\QueryBuilder->execute()
#6 /var/www/nextcloud/lib/private/AppConfig.php(110): OC\AppConfig->loadConfigValues()
#7 /var/www/nextcloud/lib/private/AppConfig.php(301): OC\AppConfig->getApps()
#8 /var/www/nextcloud/lib/private/legacy/OC_App.php(949): OC\AppConfig->getValues()
#9 /var/www/nextcloud/lib/private/Server.php(668): OC_App::getAppVersions()
#10 /var/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php(155): OC\Server->OC\{closure}()
#11 /var/www/nextcloud/3rdparty/pimple/pimple/src/Pimple/Container.php(118): OC\AppFramework\Utility\SimpleContainer->OC\AppFramework\Utility\{closure}()
#12 /var/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php(122): Pimple\Container->offsetGet()
#13 /var/www/nextcloud/lib/private/ServerContainer.php(156): OC\AppFramework\Utility\SimpleContainer->query()
#14 /var/www/nextcloud/lib/private/Server.php(1677): OC\ServerContainer->query()
#15 /var/www/nextcloud/lib/private/Server.php(1017): OC\Server->getMemCacheFactory()
#16 /var/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php(155): OC\Server->OC\{closure}()
#17 /var/www/nextcloud/3rdparty/pimple/pimple/src/Pimple/Container.php(118): OC\AppFramework\Utility\SimpleContainer->OC\AppFramework\Utility\{closure}()
#18 /var/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php(122): Pimple\Container->offsetGet()
#19 /var/www/nextcloud/lib/private/ServerContainer.php(156): OC\AppFramework\Utility\SimpleContainer->query()
#20 /var/www/nextcloud/lib/private/Server.php(1977): OC\ServerContainer->query()
#21 /var/www/nextcloud/lib/private/Files/View.php(118): OC\Server->getLockingProvider()
#22 /var/www/nextcloud/lib/private/Server.php(395): OC\Files\View->__construct()
#23 /var/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php(155): OC\Server->OC\{closure}()
#24 /var/www/nextcloud/3rdparty/pimple/pimple/src/Pimple/Container.php(118): OC\AppFramework\Utility\SimpleContainer->OC\AppFramework\Utility\{closure}()
#25 /var/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php(122): Pimple\Container->offsetGet()
#26 /var/www/nextcloud/lib/private/ServerContainer.php(156): OC\AppFramework\Utility\SimpleContainer->query()
#27 /var/www/nextcloud/lib/private/Server.php(1324): OC\ServerContainer->query()
#28 /var/www/nextcloud/lib/base.php(595): OC\Server->boot()
#29 /var/www/nextcloud/lib/base.php(1091): OC::init()
#30 /var/www/nextcloud/console.php(49): require_once('/var/www/nextcl...')
#31 /var/www/nextcloud/occ(11): require_once('/var/www/nextcl...')As I assume the command didnt changed, so there might be still an issue
Joulinar
commented
3 years ago Issue is still the connection to MariaDB as you have following error
Failed to connect to the database: could not find driver
Phil1988
commented
3 years ago Hmm...
Ok so mariaDB is still kind of broken and also the cron job is not working (are these problems maybe linked?)
and finally I got this:
root@DietPi:~# ncc maintenance:mode --on
Maintenance mode enabledwhoohoo!
so in summary, this should be executed:
apt install php7.4-mysql php7.4-xml php7.4-gd php7.4-curl php7.4-zip php7.4-mbstring
I will report back, what kind of issues I still find :D
EDIT4:
Its weird, that after installing these modules from the console (which obviously helped me getting control back over NC), I get this error message from the NC setting:
MichaIng
commented
3 years ago Due to the migration to Bullseye, the migration from PHP7.3 to PHP7.4 is required, including changing the webserver configs. In this case, a reinstall should be easiest, after purging PHP7.3 packages:
G_AGP 'php7.3-*'
dietpi-software reinstall 114This is good to keep in mind, when creating some general distro upgrade docs. For Stretch => Buster it is also requited for a few cases where PHP7.2 might be installed, which was needed for e.g. ownCloud and phpBB some time ago.
If you don't use theming in Nextcloud, you can get rid of the Imagick warning by disabling the theming app. A long discussion is going on at Nextcloud for years about whether Imagick is enough of a security issue to remove it completely, but while many alternative suggestions have been done, it is not any priority at dev side, so we need to live with this warning, or indeed install the Imagick module, while most participants of the discussion see it as unnecessary overhead in most cases and a security issue as well (as theoretically one can pass faulty code through e.g. SVGs which is then blindly executed by ImageMagick.
Phil1988
commented
3 years ago For knowledge purposes I revert back to the state before I manually installed the php modules and try your suggestion (and of course report back).
I also found your comment regarding imagick from a couple of years ago ;)
MichaIng
commented
3 years ago Ah, nice find. I just checked, at least the php-imagick package on Raspbian Buster (updated 11-Jun-2019, after my post) is now the correct PHP7.3 one, so that has been solved in the meantime 😄.
Phil1988
commented
3 years ago Yeah... well... I may be bad at this linux stuff, but at least I am decent in searching to partially overcome my shortcomes :D
Here we go:
root@DietPi:~# G_AGP 'php7.3-'
[ INFO ] APT purge for: php7.3-, please wait...
[ INFO ] None of the requested packages are currently installed. Aborting...
[ OK ] APT purge for: php7.3-(so no 7.3 installed anymore)
pretty cool, that it automatically installed the needed php modules
[ INFO ] DietPi-Software | APT install for: libapache2-mod-php7.4 php7.4-apcu ph p7.4-curl php7.4-gd php7.4-mbstring php7.4-xml php7.4-zip php7.4-mysql php7.4-sq lite3 php7.4-redis, please wait...
during that, i got this message
After this, I again got the Server error via browser
Internal Server Error
The server encountered an internal error and was unable to complete your request.
Please contact the server administrator if this error reappears multiple times, please include the technical details below in your report.
More details can be found in the server log.root@DietPi:~# ncc maintenance:mode --off
PHP Warning: PHP Startup: Unable to load dynamic library 'redis.so' (tried: /usr/lib/php/20190902/redis.so (/usr/lib/php/20190902/redis.so: undefined symbol: igbinary_serialize), /usr/lib/php/20190902/redis.so.so (/usr/lib/php/20190902/redis.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
Maintenance mode already disabled
root@DietPi:~This is weird... Im going to reboot now and report back
EDIT: Still the internal server error after rebooting.
Services are looking good:
root@DietPi:~# dietpi-services status
DietPi-Services
─────────────────────────────────────────────────────
Mode: status
[ OK ] DietPi-Services | redis-server : active (running) since Sat 2021-07-10 14:05:46 CEST; 4min 8s ago
[ OK ] DietPi-Services | mariadb : active (running) since Sat 2021-07-10 14:05:54 CEST; 4min 0s ago
[ OK ] DietPi-Services | apache2 : active (running) since Sat 2021-07-10 14:06:00 CEST; 3min 54s ago
[ OK ] DietPi-Services | mosquitto : active (running) since Sat 2021-07-10 14:06:00 CEST; 3min 54s ago
[ OK ] DietPi-Services | node-red : active (running) since Sat 2021-07-10 14:06:00 CEST; 3min 54s ago
[ OK ] DietPi-Services | blynkserver : active (running) since Sat 2021-07-10 14:06:00 CEST; 3min 54s ago
[ OK ] DietPi-Services | home-assistant : active (running) since Sat 2021-07-10 14:06:01 CEST; 3min 54s ago
[ OK ] DietPi-Services | cron : active (running) since Sat 2021-07-10 14:06:01 CEST; 3min 53s ago
[ OK ] DietPi-Services | ssh : active (running) since Sat 2021-07-10 14:05:44 CEST; 4min 10s ago
[ OK ] DietPi-Services | pihole-FTL : active (running) since Sat 2021-07-10 14:05:46 CEST; 4min 8s ago
[ INFO ] DietPi-Services | dietpi-vpn : inactive (dead)
[ OK ] DietPi-Services | dietpi-ramlog : active (exited) since Sat 2021-07-10 14:05:27 CEST; 4min 27s ago
[ OK ] DietPi-Services | dietpi-preboot : active (exited) since Sat 2021-07-10 14:05:42 CEST; 4min 13s ago
[ OK ] DietPi-Services | dietpi-boot : active (exited) since Sat 2021-07-10 14:05:43 CEST; 4min 11s ago
[ OK ] DietPi-Services | dietpi-postboot : active (exited) since Sat 2021-07-10 14:05:43 CEST; 4min 11s ago
[ INFO ] DietPi-Services | dietpi-wifi-monitor : inactive (dead)
root@DietPi:~#The issue seems with Redis now
PHP Warning: PHP Startup: Unable to load dynamic library 'redis.so' (tried: /usr/lib/php/20190902/redis.so (/usr/lib/php/20190902/redis.so: undefined symbol: igbinary_serialize), /usr/lib/php/20190902/redis.so.so (/usr/lib/php/20190902/redis.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
Phil1988
commented
3 years ago Yes, the important part during the resinstall is posted here (for faster finding for you):
PHP Warning: PHP Startup: Unable to load dynamic library 'redis.so' (tried: /usr/lib/php/20190902/redis.so (/usr/lib/php/20190902/redis.so: undefined symbol: igbinary_serialize), /usr/lib/php/20190902/redis.so.so (/usr/lib/php/20190902/redis.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
.htaccess has been updated
[ OK ] DietPi-Software | Current setting in /var/www/nextcloud/config/config.php will be preserved: 'memcache.local' => '\\OC\\Memcache\\APCu',
[ INFO ] DietPi-Software | Enabling Redis for transactional file locking.
[ OK ] DietPi-Software | Current setting in /etc/redis/redis.conf will be preserved: unixsocket /var/run/redis/redis-server.sock
[ OK ] DietPi-Software | Desired setting in /etc/redis/redis.conf was already set: unixsocketperm 770
[ OK ] DietPi-Software | usermod -aG redis www-data
[ OK ] DietPi-Software | systemctl restart redis-server
[ OK ] DietPi-Software | Desired setting in /var/www/nextcloud/config/config.php was already set: 'filelocking.enabled' => true,
[ OK ] DietPi-Software | Current setting in /var/www/nextcloud/config/config.php will be preserved: 'memcache.locking' => '\\OC\\Memcache\\Redis',
[ OK ] DietPi-Software | Added setting 'hashingThreads' => 4, to /var/www/nextcloud/config/config.php after line 'version' => '20.0.5.2',
PHP Warning: PHP Startup: Unable to load dynamic library 'redis.so' (tried: /usr/lib/php/20190902/redis.so (/usr/lib/php/20190902/redis.so: undefined symbol: igbinary_serialize), /usr/lib/php/20190902/redis.so.so (/usr/lib/php/20190902/redis.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
Set mode for background jobs to 'cron'
PHP Warning: PHP Startup: Unable to load dynamic library 'redis.so' (tried: /usr/lib/php/20190902/redis.so (/usr/lib/php/20190902/redis.so: undefined symbol: igbinary_serialize), /usr/lib/php/20190902/redis.so.so (/usr/lib/php/20190902/redis.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
All tables already up to date!
PHP Warning: PHP Startup: Unable to load dynamic library 'redis.so' (tried: /usr/lib/php/20190902/redis.so (/usr/lib/php/20190902/redis.so: undefined symbol: igbinary_serialize), /usr/lib/php/20190902/redis.so.so (/usr/lib/php/20190902/redis.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
Check columns of the comments table.
Done.
PHP Warning: PHP Startup: Unable to load dynamic library 'redis.so' (tried: /usr/lib/php/20190902/redis.so (/usr/lib/php/20190902/redis.so: undefined symbol: igbinary_serialize), /usr/lib/php/20190902/redis.so.so (/usr/lib/php/20190902/redis.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
Check indices of the share table.
Check indices of the filecache table.
Check indices of the twofactor_providers table.
Check indices of the login_flow_v2 table.
Check indices of the whats_new table.
Check indices of the cards table.
Check indices of the cards_properties table.
Check indices of the calendarobjects_props table.
Check indices of the schedulingobjects table.
Check indices of the oc_properties table.
Done.
PHP Warning: PHP Startup: Unable to load dynamic library 'redis.so' (tried: /usr/lib/php/20190902/redis.so (/usr/lib/php/20190902/redis.so: undefined symbol: igbinary_serialize), /usr/lib/php/20190902/redis.so.so (/usr/lib/php/20190902/redis.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
Check primary keys.
Done.
PHP Warning: PHP Startup: Unable to load dynamic library 'redis.so' (tried: /usr/lib/php/20190902/redis.so (/usr/lib/php/20190902/redis.so: undefined symbol: igbinary_serialize), /usr/lib/php/20190902/redis.so.so (/usr/lib/php/20190902/redis.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
Maintenance mode enabledsadly I have no I idea how to proceed with this :(
MichaIng
commented
3 years ago Ah sorry, I forgot the wildcard:
G_AGP 'php7.3-*'The issue is the following:
libapache2-mod-php7.4: php7.3 module already enabled, not enabling PHP 7.4to resolve:
a2dismod php7.3
a2enmod php7.4
systemctl restart apache2And the Apache2 PHP7.3 module should then be purged as well:
G_AGP libapache2-mod-php7.3It asks me something I dont even understand :D
root@DietPi:~# a2dismod
Your choices are: access_compat alias auth_basic authn_core authn_file authz_core authz_host authz_user autoindex deflate dir env filter headers mime mpm_prefork negotiation php7.3 reqtimeout rewrite setenvif socache_shmcb ssl status
Which module(s) do you want to disable (wildcards ok)?I guess I should only write: php7.3 right there, correct?
but for the sake of knowledge (and future easier upgrades) would you like me to revert back to my snapshot and perform the
G_AGP 'php7.3-*' before the reinstall?
Joulinar
commented
3 years ago G_AGP 'php7.3-*'
a2dismod php7.3
a2enmod php7.4
systemctl restart apache2
G_AGP libapache2-mod-php7.3done.
working now!
NC dashboard is showing me this
I guess I should do something like:
apt install php7.4-bcmath
apt install php7.4-gmpright?
And I am going to perform an NC update (20.0.5->20.0.11) now, as this tests it pretty good, if everything is fine.
->
I reloaded the page and got the information, with something that its not working and the admin should be contacted.
I just stoped the maintenance mode and pressed the update button again:
root@DietPi:~# ncc maintenance:mode --off
Maintenance mode disabledThen I went back to the browser and could finish the update.. A bit strange, but at least it worked.
I am also wondering, why there is no 21.x version availible as I am now not anymore on debian strecht :)
Creating a bug report/issue
Required Information
DietPi version G_DIETPI_VERSION_CORE=7 G_DIETPI_VERSION_SUB=2 G_DIETPI_VERSION_RC=3 G_GITBRANCH='master' G_GITOWNER='MichaIng'
Distro version stretch
Kernel version
Linux DietPi 4.9.0-16-amd64 #1 SMP Debian 4.9.272-1 (2021-06-21) x86_64 GNU/LinuxSBC model | Virtual Machine (x86_64)
Additional Information (if applicable)
echo $G_HW_UUIDSteps to reproduce
Update from 7.1.2 to 7.2.3
Actual behaviour
mariadb doesnt start. At bootup I get:
[FAILED] Dietpi-Services start : mariadbExtra details
Checked the ownership for mysql files but everything is ok
I hope you have ideas :)