The "Repository changed its Label value" notification appears when apt detects that a package repository has modified its metadata, such as its Label, Origin, or Suite fields. This is a security feature that requires explicit acknowledgment. You can resolve this by running apt update with the --allow-releaseinfo-change flag to approve the changes.
APT (Debian/Ubuntu package manager) implements strict validation of repository metadata to protect against malicious or compromised mirrors. Each repository publishes metadata including fields like Label (the repository's name/description), Origin (the organization), and Suite (distribution version). When the maintainers modify these fields, APT detects the change and halts operations until you explicitly acknowledge and trust the change. This could happen when a repository is renamed, rebranded, or reorganized by its maintainers. The notification appears as a "N:" (notice) message rather than an error, but it prevents apt update and install operations from proceeding.
The simplest solution is to tell apt that you trust and accept the repository's metadata changes. Run apt update with the --allow-releaseinfo-change flag:
# With apt (preferred on newer systems)
sudo apt update --allow-releaseinfo-change
# Or with apt-get
sudo apt-get update --allow-releaseinfo-change
# Then proceed with regular installations
sudo apt install package-nameThis single command allows the label change and updates your package lists. The change is applied only for this command execution.
Before accepting the change, you may want to see exactly what changed. The error message shows:
- The repository URL
- The field that changed (Label, Origin, Suite, etc.)
- The old value
- The new value
Look at your apt sources to identify which repository is changing:
# View all enabled repositories
cat /etc/apt/sources.list
ls /etc/apt/sources.list.d/
# Search for the repository URL mentioned in the error
grep -r "repository-url" /etc/apt/sources.list.d/Verify that the repository is legitimate before proceeding. If you don't recognize it, it's best to remove it rather than accept unknown changes.
If you want to allow only certain field changes (Label, Suite, Codename, Version), you can use more specific flags:
# Allow only Label changes
sudo apt update --allow-releaseinfo-change-label
# Allow only Suite changes (e.g., focal to jammy)
sudo apt update --allow-releaseinfo-change-suite
# Allow only Codename changes
sudo apt update --allow-releaseinfo-change-codename
# Allow Version field changes
sudo apt update --allow-releaseinfo-change-versionThese flags are more granular if you want to permit specific changes while being cautious about others.
If you want this change to be accepted permanently without needing the flag each time, create an apt configuration file:
# Create a configuration file to always allow metadata changes
echo 'Apt::Get::AllowReleaseInfoChange "true";' | sudo tee /etc/apt/apt.conf.d/99allow-releaseinfo-change
# Verify it was created
cat /etc/apt/apt.conf.d/99allow-releaseinfo-change
# Test that apt update now works without flags
sudo apt updateNow apt commands will automatically accept repository metadata changes. This is safe if you trust your repository sources and keep them updated.
If the changing repository is unfamiliar or untrusted, it's safer to remove it entirely rather than accept unknown changes:
# List all repositories with details
apt policy
# Remove a repository by disabling it
sudo nano /etc/apt/sources.list # Edit and comment out or delete lines
# Or remove a PPA:
sudo add-apt-repository --remove ppa:username/ppaname
# Remove a repository added via sources.list.d:
sudo rm /etc/apt/sources.list.d/repository-name.list
# Update after removing
sudo apt updateRemoving the repository is the most conservative approach if you don't recognize it or don't need it anymore.
Why this security feature exists: APT validates repository metadata to prevent man-in-the-middle attacks and ensure you're downloading packages from the expected source. A compromised mirror could change the Label field to disguise itself. This strict validation protects system integrity.
Common repository changes: Docker changed from 'Docker CE' to 'Docker EE' (Community vs Enterprise), Ubuntu Pro repositories changed labeling when transitioning from 'UA Client' to 'Ubuntu Pro Client', and various PPAs rename themselves for clarity or branding updates.
In CI/CD pipelines: Docker containers and CI systems frequently encounter this error because repositories update their metadata. The --allow-releaseinfo-change flag is standard in many Dockerfile base images and CI configuration files.
GitHub Actions workaround: If you're using GitHub Actions, you may need to add this to your workflow:
- name: Update package lists
run: sudo apt update --allow-releaseinfo-changeContainer images: When building Docker containers with older base images, the parent image's repositories may have changed. This is why it's recommended to use recent base image tags (e.g., ubuntu:22.04 instead of ubuntu:16.04).
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