This error occurs when apt attempts to downgrade packages using the -y flag without explicitly allowing downgrades. The --allow-downgrades flag is required when using automated yes (-y) with package downgrades.
APT (Advanced Package Tool) detected that a package downgrade would occur, but you used the -y (automatic yes) flag without including --allow-downgrades. Since package downgrades can potentially break system stability, apt requires explicit permission via the --allow-downgrades flag when combined with automated approval. This safety mechanism prevents accidental downgrades in automated scripts or configurations.
When using apt with -y to install a specific older version of a package, include the --allow-downgrades flag:
sudo apt install -y --allow-downgrades package-name=versionExample:
sudo apt install -y --allow-downgrades docker-ce=5.20.10~3-0~ubuntu-focalIf you are using Ansible, ensure your apt module includes the allow_downgrade parameter:
- name: Install specific package version
ansible.builtin.apt:
name: "{{ package_name }}={{ package_version }}"
state: present
allow_downgrade: yesNote: Even with allow_downgrade set, you may need to ensure the generated apt command includes --allow-downgrades for Ansible versions that have this limitation.
If running automated upgrades via cron or CI/CD pipelines, modify your upgrade command:
Old (failing):
apt update && apt upgrade -yNew (if downgrades are needed):
apt update && apt upgrade -y --allow-downgradesBetter alternative - use unattended-upgrades:
sudo apt install unattended-upgrades
sudo dpkg-reconfigure unattended-upgradesThe unattended-upgrades package handles version conflicts intelligently without manual flag management.
Before applying the --allow-downgrades flag, understand why the downgrade is happening:
# Check currently installed version
apt list --installed | grep package-name
# Check available versions in repositories
apt policy package-name
# Check what apt would do with a dry run
apt install -y --allow-downgrades --simulate package-name=versionOnly proceed with the actual installation if the simulation looks correct.
The --allow-downgrades flag was introduced in APT 1.1 as a replacement for the deprecated --force-yes option, which was considered too permissive. The --allow-downgrades flag is intentionally strict because downgrading packages can introduce dependency conflicts and break system stability. In production environments, prefer using unattended-upgrades over manual apt commands, as it intelligently handles version conflicts. If you frequently need to downgrade packages, consider investigating why (e.g., Docker version incompatibilities, conflicting package sources) and address the root cause rather than treating downgrades as a routine operation. On systems with multiple package sources, pin specific packages using /etc/apt/preferences to prevent unexpected downgrades.
E: Could not connect to proxy server
Could not connect to proxy server
E: Package 'package:i386' has no installation candidate
How to fix "Package package:i386 has no installation candidate" in apt
E: The value 'value' is invalid for APT::Default-Release
How to fix invalid APT::Default-Release value in APT
dpkg: error: unable to create new file 'path': Permission denied
How to fix dpkg permission denied errors in APT
subprocess installed post-removal script returned error exit status 1
How to fix "subprocess installed post-removal script returned error exit status 1" in APT