While updating PHP packages on Debian 12 (Bookworm), I encountered this APT error:
E: Release file for https://packages.sury.org/php/dists/bookworm/InRelease
is not valid yet.
At first, it looked like a problem with the PHP repository. However, the actual cause was the system clock being out of sync.
APT validates repository metadata timestamps. If the system clock is behind the metadata's validity time, APT may reject the repository even when the repository itself is working correctly.
The correct troubleshooting sequence is:
- Check and synchronize the system clock.
- Configure NTP if necessary.
- Update APT package indexes.
- Configure the Sury PHP repository if it is not already configured.
- Upgrade installed PHP packages.
- Verify the PHP version and running services.
This guide uses Debian 12 Bookworm as the example.
Step 1: Check the system clock
Start by checking the current system time and NTP synchronization status.
date
date -u
timedatectl status
Look for these fields in the timedatectl output:
System clock synchronized: yes
NTP service: active
The exact output may differ depending on your system configuration.
If the system clock is incorrect or synchronization is disabled, fix it before troubleshooting the repository further.
Step 2: Enable NTP synchronization
Debian 12 supports systemd-timesyncd as an NTP client.
First, check whether the service is available:
systemctl status systemd-timesyncd
If it is installed, enable NTP synchronization:
sudo timedatectl set-ntp true
Check the status again:
timedatectl status
timedatectl timesync-status
If systemd-timesyncd is unavailable, check whether another NTP client, such as chrony, is already managing the system clock. Avoid running multiple competing time-synchronization services.
Configure an NTP server
If you need to specify your own NTP servers, edit the configuration file:
sudo nano /etc/systemd/timesyncd.conf
Configure the [Time] section:
[Time]
NTP=0.my.pool.ntp.org 1.my.pool.ntp.org 2.my.pool.ntp.org
FallbackNTP=0.pool.ntp.org 1.pool.ntp.org
Save the file and restart the service:
sudo systemctl restart systemd-timesyncd
sudo timedatectl set-ntp true
Verify the synchronization status:
timedatectl status
timedatectl timesync-status
Important: If the clock is significantly wrong, synchronization may take some time. Make sure the system clock is correct before continuing.
If the service is missing and you cannot install it because APT is already failing, correct the clock using an available trusted time source or your infrastructure's existing time service first. You can install the package after APT works again.
Step 3: Update APT package indexes
Once the system clock is synchronized, refresh the package indexes:
sudo apt update
Check the output for errors.
The following error should no longer appear:
Release file ... is not valid yet
If it persists, investigate the system time, NTP connectivity, repository metadata, and any HTTP proxy or caching layer between the server and the repository.
Do not bypass repository signature or validity checks to work around a clock problem.
Step 4: Install the Sury PHP repository
If packages.sury.org/php is already configured on your system, you can skip this step.
The Sury repository provides additional PHP versions and packages for Debian. It is a third-party repository, not an official Debian repository.
First, install the required utilities:
sudo apt install -y ca-certificates curl lsb-release
Download and install the Sury archive keyring package:
sudo curl -fsSL \
https://packages.sury.org/debsuryorg-archive-keyring.deb \
-o /tmp/debsuryorg-archive-keyring.deb
sudo apt install /tmp/debsuryorg-archive-keyring.deb
Configure the repository for the installed Debian release:
sudo tee /etc/apt/sources.list.d/php.sources > /dev/null <<EOF
Types: deb
URIs: https://packages.sury.org/php/
Suites: $(. /etc/os-release && echo "$VERSION_CODENAME")
Components: main
Signed-By: /usr/share/keyrings/debsuryorg-archive-keyring.gpg
EOF
On Debian 12, the suite should resolve to bookworm.
Update the package indexes:
sudo apt update
Check the available PHP package versions:
apt-cache policy php
apt list --upgradable 2>/dev/null | grep -i php
This confirms which versions and upgrades APT can see. It does not, by itself, prove that every installed PHP package is up to date.
Step 5: Identify the installed PHP packages
Before upgrading PHP, identify which packages are already installed.
dpkg-query -W \
-f='${binary:Package}\t${Version}\n' \
'php*' 2>/dev/null
You may see packages such as:
php8.2-cliphp8.2-commonphp8.2-fpmphp8.2-mysqlphp8.2-xmlphp8.2-curlphp8.2-mbstring
The actual list depends on your applications and installed PHP versions.
Check the PHP CLI version:
php -v
Remember that the CLI version may differ from the version used by your web server or PHP-FPM.
Step 6: Upgrade installed PHP packages only
A tempting command is:
sudo apt --only-upgrade install 'php*'
However, a wildcard can match packages that are not currently installed. That is not ideal when the goal is to upgrade existing PHP packages without introducing additional packages or PHP versions.
Instead, build a list of installed PHP packages and simulate the upgrade first.
Run the following commands in Bash:
mapfile -t PHP_PACKAGES < <(
dpkg-query -W -f='${binary:Package}\n' 'php*' 2>/dev/null |
grep -E '^php([0-9.]|[-:])'
)
printf '%s\n' "${PHP_PACKAGES[@]}"
Review the package list.
If the list is empty, stop and investigate rather than running the upgrade command.
Simulate the upgrade:
sudo apt-get -s install --only-upgrade "${PHP_PACKAGES[@]}"
Review the proposed changes carefully. Confirm that APT is not removing important packages or making unexpected changes to your PHP setup.
If the proposed changes are appropriate, perform the upgrade:
sudo apt-get install --only-upgrade "${PHP_PACKAGES[@]}"
The --only-upgrade option limits the operation to upgrading packages that are already installed.
This approach is useful when you want to apply available updates to your existing PHP packages without intentionally installing every PHP version provided by Sury.
Step 7: Verify the PHP upgrade
Check the installed CLI version:
php -v
Check the PHP configuration:
php --ini
Check whether additional PHP packages remain upgradeable:
apt list --upgradable 2>/dev/null | grep -i php
No matching output generally means that APT has no PHP upgrades to report through that command.
For PHP-FPM installations, check the available services:
systemctl list-units \
--type=service \
--all \
'php*-fpm.service'
Inspect the relevant PHP-FPM service:
systemctl status php8.2-fpm
Replace php8.2-fpm with the actual service installed on your server.
If you use Apache or Nginx, verify that the web application is still working and that the web server is connected to the expected PHP runtime.
Step 8: Check security patch status
A successful package upgrade does not automatically mean that every security vulnerability has been addressed.
Check the installed package versions and the available repository versions:
apt-cache policy php8.2-cli
apt-cache policy php8.2-fpm
Replace the package names with those relevant to your installation.
Review the applicable security advisories and package changelogs. Debian packages may include security fixes without using the same version numbering as upstream PHP releases.
For production servers, also test your Laravel applications, extensions, scheduled jobs, and PHP-FPM processes after the update.
Troubleshooting checklist
If the repository error persists, check these items:
- [ ]
date -ureports a plausible UTC time. - [ ]
timedatectl statusreports successful clock synchronization. - [ ] The configured NTP server is reachable.
- [ ]
sudo apt updatecompletes without repository validity errors. - [ ] The Sury repository points to the correct Debian suite.
- [ ] The Sury archive keyring is correctly configured.
- [ ] No proxy or cache is returning stale repository metadata.
- [ ] The PHP upgrade simulation shows only expected changes.
Conclusion
The important lesson from this incident is that not every APT repository error is caused by the repository itself.
In this case, the system clock was out of sync, causing APT to reject the Sury repository's InRelease metadata as not yet valid.
The recovery process was straightforward:
# 1. Synchronize the system clock
sudo timedatectl set-ntp true
# 2. Update package indexes
sudo apt update
# 3. Upgrade installed PHP packages
# First review the installed package list and simulate the upgrade.
# Then execute the approved upgrade.
# 4. Verify the PHP version
php -v
For reliable server maintenance, always verify system time before investigating repository validity errors. Correct time synchronization also matters for TLS certificates, logs, scheduled jobs, and security auditing.
References
