PiHole installation broke nextcloud and phpmyadmin

Creating a bug report/issue

Required Information

  • DietPi version | cat /boot/dietpi/.version
    G_DIETPI_VERSION_CORE=8
    G_DIETPI_VERSION_SUB=8
    G_DIETPI_VERSION_RC=1
    G_GITBRANCH=‘master’
    G_GITOWNER=‘MichaIng’
  • Distro version | bullseye
  • Kernel version | Linux DietPi 3.16.85+ #1 SMP PREEMPT Tue Jun 30 19:02:35 CEST 2020 aarch64 GNU/Linux
  • SBC model | Odroid C2 (aarch64)
  • Power supply used | (EG: 5V 1A RAVpower)
  • SD card used | (EG: SanDisk ultra)

Additional Information (if applicable)

  • Software title | (PiHole)
  • Was the software title installed freshly or updated/migrated?
    Fresh install
  • Can this issue be replicated on a fresh installation of DietPi?
    Don’t know

Hi,

after installing PiHole (via dietpi-software) on a fine running DietPi, my nextcloud instance stopped working (phpmyadmin too)
First installed it with unbound, which didn’t work well with my setup, so I uninstalled both and reinstalled PiHole only.
I noticed, that PiHolein the first run installed PHP again, which had been already installed for phpMyAdmin and Nextcloud.

error.log of lighttpd shows:

2022-09-23 20:15:11: mod_fastcgi.c.487) FastCGI-stderr:PHP message: PHP Fatal error:  Uncaught Doctrine\DBAL\Exception: Failed to connect to the database: An exception occurred in the driver: SQLSTATE[HY000] [2002] No such file or directory in /var/www/nextcloud/lib/private/DB/Connection.php:87
2022-09-23 20:15:11: mod_fastcgi.c.487) FastCGI-stderr:Stack trace:
2022-09-23 20:15:11: mod_fastcgi.c.487) FastCGI-stderr:#0 /var/www/nextcloud/3rdparty/doctrine/dbal/src/Connection.php(1519): OC\DB\Connection->connect()
2022-09-23 20:15:11: mod_fastcgi.c.487) FastCGI-stderr:#1 /var/www/nextcloud/3rdparty/doctrine/dbal/src/Connection.php(1041): Doctrine\DBAL\Connection->getWrappedConnection()
2022-09-23 20:15:11: mod_fastcgi.c.487) FastCGI-stderr:#2 /var/www/nextcloud/lib/private/DB/Connection.php(237): Doctrine\DBAL\Connection->executeQuery()
2022-09-23 20:15:11: mod_fastcgi.c.487) FastCGI-stderr:#3 /var/www/nextcloud/3rdparty/doctrine/dbal/src/Query/QueryBuilder.php(345): OC\DB\Connection->executeQuery()
2022-09-23 20:15:11: mod_fastcgi.c.487) FastCGI-stderr:#4 /var/www/nextcloud/lib/private/DB/QueryBuilder/QueryBuilder.php(287): Doctrine\DBAL\Query\QueryBuilder->execute()
2022-09-23 20:15:11: mod_fastcgi.c.487) FastCGI-stderr:#5 /var/www/nextcloud/lib/private/AppConfig.php(361): OC\DB\QueryBuilder\QueryBuilder->execute()
2022-09-23 20:15:11: mod_fastcgi.c.487) FastCGI-stderr:#6 /var/www/nextcloud/lib/private/AppConfig.php(126): OC\AppConfig->loadConfigValues()
2022-09-23 20:15:11: mod_fastcgi.c.487) FastCGI-stderr:#7 /var/www/nextcloud/lib/pr..

phpmyadmin gives back a

mysqli::real_connect(): (HY000/2002): No such file or directory

via login.

Looks like the DB-connector is broken.
Any idea how to fix this will be greatly appreciated!
Up to now, I didn’t force reinstall PHP.

Thanks for any help
Frans

As a first step, you could try to reinstall PHP

dietpi-software reinstall 89

Thank you, now started the rinstall, but:
Isn’t mariadb missing here?

[ SUB2 ] DietPi-Services > stop
[  OK  ] DietPi-Services | stop : cron
[  OK  ] DietPi-Services | stop : filebrowser
[  OK  ] DietPi-Services | stop : jellyfin
[  OK  ] DietPi-Services | stop : lighttpd
[  OK  ] DietPi-Services | stop : php7.4-fpm
[  OK  ] DietPi-Services | stop : redis-server
[  OK  ] DietPi-Services | stop : smbd
[  OK  ] DietPi-Services | stop : nmbd

lets check it

dietpi-software list | grep "ID 88"

What exactly you remove during uninstallation of PiHole. Do you recall what you selected?

dietpi-software list | grep "ID 88"
ID 88 | =2 | MariaDB: Persistent cached file-per-table database server | | https://dietpi.com/docs/software/databases/#mariadb

Just checked PiHole and Unbound for deinstallation. Left most of the dependencies installed. If I had been asked to remove mariadb, I never agreed.

As I performed a backup before the reinstall of PHP, I’ve seen that rsync deleted all my mariadb files from my last backup. Not my best idea, I guess…

at least this means MariaDB should be installed and has not been removed using our script.

let’s check the packages installed

dpkg -l mariadb*
dpkg -l mariadb*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                       Version             Architecture Description
+++-==========================-===================-============-=================================
un  mariadb-client-10.0        <none>              <none>       (no description available)
rc  mariadb-client-10.1        10.1.48-0+deb9u2    arm64        MariaDB database client binaries
un  mariadb-client-10.2        <none>              <none>       (no description available)
rc  mariadb-client-10.3        1:10.3.29-0+deb10u1 arm64        MariaDB database client binaries
un  mariadb-client-5.5         <none>              <none>       (no description available)
un  mariadb-client-core-10.1   <none>              <none>       (no description available)
un  mariadb-client-core-10.3   <none>              <none>       (no description available)
un  mariadb-common             <none>              <none>       (no description available)
un  mariadb-galera-server      <none>              <none>       (no description available)
un  mariadb-galera-server-10.0 <none>              <none>       (no description available)
un  mariadb-galera-server-5.5  <none>              <none>       (no description available)
un  mariadb-server-10.0        <none>              <none>       (no description available)
rc  mariadb-server-10.1        10.1.48-0+deb9u2    arm64        MariaDB database server binaries
un  mariadb-server-10.2        <none>              <none>       (no description available)
rc  mariadb-server-10.3        1:10.3.29-0+deb10u1 arm64        MariaDB database server binaries
un  mariadb-server-5.5         <none>              <none>       (no description available)
un  mariadb-server-core-10.1   <none>              <none>       (no description available)
un  mariadb-server-core-10.3   <none>              <none>       (no description available)
un  mariadb-test               <none>              <none>       (no description available)
un  mariadb-tokudb-engine-10.0 <none>              <none>       (no description available)
un  mariadb-tokudb-engine-10.1 <none>              <none>       (no description available)
un  mariadb-tokudb-engine-5.5  <none>              <none>       (no description available)

At least the databases seem to be alive:

du -h /mnt/usb_1/dietpi_userdata/mysql
8.0K	/mnt/usb_1/dietpi_userdata/mysql/performance_schema
49M	/mnt/usb_1/dietpi_userdata/mysql/nextcloud
2.0M	/mnt/usb_1/dietpi_userdata/mysql/phpmyadmin
1.9M	/mnt/usb_1/dietpi_userdata/mysql/mysql
225M	/mnt/usb_1/dietpi_userdata/mysql

this is not good sign. rc means

  • r: package has been marked to be removed
  • c: configuration files still exist on your system

I still wonder how this could happen to have MariaDB removed.

ok let’s try to create a copy of your DB folder first

cp -p -r /mnt/usb_1/dietpi_userdata/mysql /mnt/usb_1/dietpi_userdata/mysql.bak

ok let’s try to reinstall MariaDB again.

dietpi-software reinstall 88

dietpi-software still shows mariadb as installed:

[*] 82   LLMP: Lighttpd + MariaDB + PHP
[*] 88   MariaDB: Persistent cached file-per-table database server
[*] 90   phpMyAdmin: Optional MariaDB web interface admin tools

Now copy and reinstall

we take that information from a stupid configuration file and assume you don’t remove it on a different way. We don’t check if the package is installed in reality :wink:

Perfect, your wonderful scripts did it again!

mariadb has been reinstalled without replacing any of the former files.
Nextcloud and phpmyadmin are running again, all their data and credentials left intact.

Not sure, what happened- I definitely didn’t remove mariadb manually from the commandline.
In the future, I will save the terminal window for later reference when installing/uninstalling.

Thank you for your help in the late evening.
As always a pleasure!

ok perfect. Keep in mind to perform a backup BEVORE starting any install or uninstall. This way you can go back if thinks are failing :slight_smile:

At least I’m using the dietpi-sync for a daily clone of the userdata to a second drive.
Just stumbled upon this issue too late.
But I will perform an additional backup in the future too.
Thank you again for helping me with your Linux-dictionary skills.

1 Like