-
-
Notifications
You must be signed in to change notification settings - Fork 494
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PHP 7.4 autoremove error in bookworm update script #6559
Comments
|
Many thanks for your report. Strangely it tries to install packages while it should purge them. Probably there is one explicitly depending on one of those PHP 7.4 packages. And then it looks like PHP 8.2 is already installed, but broken, while it should actually be installed afterwards. And the APT purge command actually checks for and attempts to purge only installed packages, while on your case or tried to purge a lot more which are not installed. It should even adjust the list on every retry, in case some have been purged already prior to the error. Can you show the output of the following commands: dpkg -l | grep 'php'
apt upgrade
apt purge php7.4-common # in case, confirm
dpkg -l | grep 'php'
dmesg -l 0,1,2,3 |
Thanks for your help. Here comes the requested output:
|
Ah this is the reason: You set all PHP 7.4 packages on hold. This way of course they cannot be upgraded or removed. For packages from the Debian repo of a stable Debian version, it should never be required to set any package on hold, and it is harmful, since it prevents security upgrades. Please unhold all packages: apt-mark unhold $(apt-mark showhold) Please use the bash -c "$(curl -sSf 'https://raw.githubusercontent.com/MichaIng/DietPi/dev/.meta/dietpi-bookworm-upgrade')" |
Thanks for your help. I went through this commands. In between there was another issue with mariadb, but I could jumped over this point. Next issue was known warning to IcePHP. The script runs until the end including My problem is still this following php-error, which blocks all php-related commands.
|
Is this an additional module or somehow a wrapper for the PHP CLI? I found the IcePHP project with a matching issue here: zeroc-ice/ice#1405 Can show: which php
php -m So whatever it is exactly, and why it is invoked when you just call the PHP CLI, it may require an update to include this patch: zeroc-ice/ice#1423 Btw, on GitHub and Markdown in general you can create nicer code and log blocks like this: ```console
root@DietPi:~# sudo -u www-data php /var/www/nextcloud/ occ db:add-missing-indices
PHP Warning: IcePHP_Properties::__toString() implemented without string return type in Unknown on line 0
PHP Warning: Ice\ObjectPrx::__toString() implemented without string return type in Unknown on line 0
PHP Warning: IcePHP_Logger::__toString() implemented without string return type in Unknown on line 0
PHP Warning: IcePHP_Endpoint::__toString() implemented without string return type in Unknown on line 0
PHP Warning: IcePHP_Connection::__toString() implemented without string return type in Unknown on line 0
``` The "console" behind the open syntax highlights part of the console logs a way that the command prompt, command and output can be nicely seen. Skipping this will remove the colouring, but still have the nicely readable multi-line monotype block. |
I do not know why I have or why I need this IcePHP. If there is a possible way without this, I would kick it away. ;o) When I try to reinstall mariadb I run into this error:
|
Please show the output of the commands I posted above, and additionally: apt install mariadb-server |
|
|
There it is, the dpkg -l | grep ice Disable it for now. For Nextcloud it is definitely not required. If you have another PHP application, which requires it, it needs to be updated first anyway: phpdismod ice
php -v And lets see why apt install mariadb-client |
|
mariadb seems to be fine now. But my nextcloud is still offline... |
Okay, so this PHP ice module is a Debian package. Indeed it has last been updated (January) on the Debian repo before the fix for these warnings has been merged (February): The update is however on the way, at least Trixie has v3.7.9 from March already: https://packages.debian.org/trixie/php-zeroc-ice What is disturbing is that even we ran
I assume you do not do this manually, so what the hack marks these packages on hold? Are there more? apt-mark showhold And to check for Nextcloud, let's see whether all required services are running successfully: journalctl -u mariadb-server -u php8.2-fpm -u nginx -u redis |
In between I reinstalled nginx (
Above I miss some message reaction to mariadb.
|
All PHP 7.4 packages are still there. I thought you purged them previously? Did one of those commands throw an error? apt-mark unhold $(apt-mark showhold)
G_AGP '*php7.4*' 'php-zeroc-ice' I added the ice module as well to be purged. PHP reinstalls always enable all modules, so let's get rid of it. It can be reinstalled at any time when really required for something. About the service status, I am missing Redis: systemctl status redis Ah, probably because "redis" is just an alias for "redis-server", so probably this shows all logs:
"mariadb" is the correct service name instead, so basically I switched around the "-server" appendix. |
|
In between I updated my nextcloud server to the newest and highest available version. But still no luck when I try to call the local ip or global URL in my browser.
|
The services seem to be all running. I have never seen this kind of APT database mismatch/error. The link from the error message contains some info: https://wiki.debian.org/Teams/Dpkg/FAQ#set-selections /boot/dietpi/func/dietpi-set_software apt clean
apt update
apt-mark showhold
apt-mark unhold $(apt-mark showhold) If the same errors are thrown, let's try the first solution from the guide: apt-cache dumpavail | dpkg --merge-avail
apt-mark unhold $(apt-mark showhold) The |
|
When I try to connect to my nextcloud server via mobile apps like "Nextcloud" and "Talk"-App on Android, then there is also no connection: "Server unavailable". |
Okay, there are three databases with different information. Let's check where exactly those packages are present: sed -n '/^Package: php7.4$/,/^$/p' /var/lib/dpkg/status
sed -n '/^Package: php7.4$/,/^$/p' /var/lib/dpkg/available
sed -n '/^Package: php7.4$/,/^$/p' /var/lib/apt/extended_states The first contains the hold status. But it contains (should so) only installed packages, hence I have no idea how it is possible that an uninstalled package can have a hold state saved in any of them. |
|
Okay, these look like intended dummy entries to store the hold state for not-installed packages. And at the same time, these hold states cannot be removed if the package is not installed and not available anymore. Why exactly is it possible to cause such a situation, i.e. why does APT just do what it is asked for and remove those entries, regardless whether they are still in any repo or not, or better especially if they are not available in any repo anyway 😄. Let's temporarily re-add the Bullseye repo, which should allow unholding the packages: echo 'deb https://deb.debian.org/debian bullseye main' > /etc/apt/sources.list.d/bullseye.list
apt update
apt-mark unhold $(apt-mark showhold)
apt-mark showhold |
|
Okay, now removing it again: rm /etc/apt/sources.list.d/bullseye.list
/boot/dietpi/func/dietpi-set_software apt clean So at least these cannot be responsible for the Nextcloud access issues. Can you access it locally? curl -IL 127.0.0.1/nextcloud If you use HTTPS, try the same after replacing |
|
Good news from my side!! I renewed the https-certificates with your |
Does Certbot on Bullseye probably create an Nginx SSL config which is not compatible with the Nginx version on Bookworm? The syntax must be correct, as otherwise the server would not start, but probably some format, cipher or any such is not supported (anymore). The connection seems to fail exactly when the first HTTPS request is attempted. If the certificate was expired, there would be a different error message. About the nasty package hold thing: Looks like we should unhold all packages before adjusting the list files. There are potential strong reasons to keep individual packages on hold, especially with 3rd party repos, but on the other hand, a distro upgrade is a major thing as well, one should have a backup or mentioned hold DEB files available somewhere, and often such mark becomes obsolete when the distro upgrade resolves the underlying reason for the hold state. EDIT: Done. |
- dietpi-bookworm-upgrade | Mark all packages unhold before touching list files. If hold packages are not available anymore afterwards, they remain as dummy entries in "status" and "available" DPKG databases to preserve their hold state. At the same time, "apt-mark unhold" cannot be performed on packages which are neither installed nor available in any installed APT list/repo: #6559
I'll mark this as closed. Will keep the Certbot Bullseye vs Bookworm question in mind, in case others report a similar issue, and in case add a prompt for a cert update. |
│
Details:
Linux DietPi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux
Steps to reproduce:
Expected behaviour:
Actual behaviour:
Extra details:
Additional logs:
The text was updated successfully, but these errors were encountered: