Beiträge von dleidert

    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.

    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.

    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.

    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.

    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 ...

    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.

    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


    or


    sudo apt-get install -t usul salt-minion ...