Well, but then omv-extras has probably not been upgraded when it gets broken by removing php7.0. You reported that the upgrade was interrupted on your system due to a missing repository key. You haven't described in detail what you did. Maybe you didn't really finish the upgrade process?
Why was not it happening before ?
I cannot describe the exact circumstances. The issue probably involves some kind of sorting order difference in which apt determines the package to install and the package to download. This issue appeared often in the past when people used third party repositories which just rebuilt packages after changing some configuration options. That's why there are rules/recommendations to change the version number (add a local suffix or similar) when rebuilding a package to avoid these kind of clashes. Raspbian systems shouldn't mix in debian-security. Raspbian takes updates from debian-security and rebuilds them for their own repository. That's why mixing in debian-security IMHO is also superfluous. Also debian-backports is not really meant for Raspbian.
You have enabled Debian repositories in a Raspbian system and you are possibly missing the debian-archive-keyring package which contains the keys the Debian repositories are signed with. Please note that you might run into this issue. The keyring package must be installed using apt's --allow-unauthenticated switch because the repository is untrusted at this stage.
Does anyone have any idea ?
Why are you hijacking this thread if your problem is not related to doing an upgrade? Please open a new thread in an appropriate sub-forum and I'm sure you will find people helping you. Necessary information might be the package version of php-fpm installed and possible the contents of the nginx log files and maybe daemon.log.
Again: This is due to mixing repositories of two different operating systems which are not meant to be mixed together. The Raspbian project takes the Debian packages and rebuilds them, leading to different hashsums. So this issue will re-appear again and again.
It seems that there have been efforts though to make the installation of a pristine Debian possible for Raspberry PIs. With a pristine Debian this issue will not appear.
I have the same problem trying to upgrade to openmediavault (5.6.4-1).
No, you don't have the same problem. While the thread is about having a repository listed multiple times as APT source, your's is that the postinst script fails in the configure target. So please start a new thread.
DiffComment: pkg.del_repo: Repo 'deb http://security.debian.org/debian-security buster/updates main contrib non-free' has been removed from /etc/apt/sources.list.d/openmediavault-os-security.list.Repo 'deb http://security.debian.org/debian-security buster/updates main contrib non-free' has been removed from /etc/apt/sources.list.d/openmediavault-os-security.list.
But when doing another apt update the error is still there.
Well, it seems it removes the security repository from /etc/apt/sources.list.d/openmediavault-os-security.list and then re-adds it to the same file. So there is no attempt above to remove the securiry repository from /etc/apt/sources.list to fix the issue. Thus, the error is the same.
If you clone your SSD you should run sudo dpkg-reconfigure grub-pc on the clone before doing anything else (this fixes the debconf entry where to install grub, which is based on the UUID of the target device). Otherwise your upgrade can fail. One of the checks in the upgrade scripts should catch this scenario though and exit the upgrade process.
Can you post the contents of this file?
You do not want to do this unless you can absolutely guarantee that that device will always be /dev/sda.
If grub-pc is installed and this is entry is left empty, grub will not be updated at all in the MBR during updates/upgrades and this will lead eventually to an unbootable system as described here. Even if the dialog shows /dev/sda grub-pc is been storing the device name(s) in the debconf database as /dev/disc/by-uuid/... for some time now.
Now please run the scripts from the post.d/ directory from the upgrade scripts:
sudo run-parts -v --exit-on-error post.d
Without knowing which device /dev/sda is on your system, I cannot answer this question.
You should check sudo dpkg-reconfigure grub-pc and choose the correct device to install the Grub into. If the entry stored in the debconf database is wrong, then what you did will only work temporary.
JFTR: If this is an upgraded system there is likely the APT::Default-Release setting in /etc/apt/apt.conf which gives Debian Buster repositories a pinning of 990 and can be removed. You could have used the sudo apt-get install -t usul switch to install the salt packages from the OMV repository. Or you can use the package version in the installation command sudo apt-get install salt-common=3002.2+ds-1 ...
Everything smooth but than I ran into some issues with installing plugins (wasn´t able to connect). Before I had the bright idea to look at my empty DNS Server (!) I ran "get clean".
After that I added the DNS Server and got this fatal error...
dpkg: unrecoverable fatal error, aborting:
files list file for package 'samba' contains empty filename
E: Sub-process /usr/bin/dpkg returned an error code (2)
When I´m running a update via omv konsole it ist showing:
Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C.UTF-8; apt-get update ': Reading package lists...
So maby this is a direction where the problems comes from?
Nothing of what you say makes any sense. You are very likely not running a DNS server (and there is no such thing as an empty DNS server). Then adding a DNS servers is not related to the package management throwing this error.
A) It sounds like you were having issues with the domain name resolution.
B) You are seeing errors which point to corrupted Debian packages, which itself is an indicator that you might be using third party repositories.
It would help a lot if you could describe, what exactly you did, what files you changed. which commands you ran, and if you could post full error messages.
Type 'sudo' is not known on line 1 in source list /etc/apt/sources.list.d/buster-backports.list
A repository/source list shouldn't contain the word "sudo" in it. You obviously have cruft in /etc/apt/sources.list.d/buster-backports.list.
You didn't comment out the pin-entry for stretch in /etc/apt/preferences.d/99raspberrypiorg as I told you earlier. That still gets in the way. Please remove these lines or comment them out. Then also remove the APT::Default-Release value in /etc/apt/apt.conf. Run sudo apt-get update and try to install openmediavault als the salt-* packages from the OMV repository again. You can also force the installation of the latter using
sudo apt-get install salt-minion=3002.2+ds-1
sudo apt-get install -t usul salt-minion ...
Can you please post the output of
apt-cache policy and apt-cache policy salt-minion
You have a pinning issue.