What happened

During a routine security check on a production Amazon Linux 2023 server, I ran the usual command:

$ sudo dnf updateinfo list --security Last metadata expiration check: 0:12:34 ago # (nothing)

Nothing. So: "zero pending security updates." I reported it as fully patched.

The next day, while working on something else, I ran dnf check-release-update — and the picture changed:

$ sudo dnf check-release-update WARNING: A newer release of "Amazon Linux" is available. Available Versions: Version 2023.9.20261104: Run the following command to upgrade to 2023.9.20261104: dnf upgrade --releasever=2023.9.20261104

A newer release existed. Re-running the security check with --releasever=latest:

$ sudo dnf updateinfo list --security --releasever=latest ALAS2023-2026-xxxx Important/Sec. openssh-* ALAS2023-2026-xxxx Important/Sec. libxml2-* ALAS2023-2026-xxxx Medium/Sec. amazon-ssm-agent-* ALAS2023-2026-xxxx Important/Sec. kernel-*

Four security updates were waiting: openssh, libxml2, amazon-ssm-agent, and the kernel. My "zero" report from the day before was wrong.

The cause — AL2023 pins you to a release

Amazon Linux 2023 uses a design called deterministic upgrades. An instance's repositories are locked to the release it was created with (or last explicitly upgraded to), and a plain dnf only sees updates within that release.

If you come from AL2 or CentOS, a quiet yum check-update means you're current. On AL2023, it only means you're current relative to the pinned release. Security fixes that landed in a newer release are invisible unless you pass --releasever.

It's a stability feature, not a bug — but combined with the assumption that "quiet output = safe," it's a nasty trap.

Gotchas

1. The day after patching, it still shows "zero" 

sudo dnf upgrade --security --releasever=latest

This pulls only the security packages from the new release and leaves system-release untouched. Which means the next day, a check without the option still reports zero — and you make the same mistake again. The fix is to bake --releasever=latest permanently into your check scripts.

2. A false "reboot required"

After applying, dnf needs-restarting -r insisted a reboot was needed because "the kernel was updated." But the updated one was the unused spare kernel line (the 6.1-series kernel package) — the server actually runs the kernel6.12 package line.

$ uname -r 6.12.x-x.amzn2023.x86_64 $ sudo grubby --default-kernel /boot/vmlinuz-6.12.x-x.amzn2023.x86_64

If the running kernel and the default boot kernel are unchanged, you don't need the reboot this warning asks for.

3. "Secure Boot not enabled" is not an error

The Secure Boot not enabled line printed during kernel installation is an informational message from the install scripts, not a failure. It looks scary the first time.

The actual procedure

Since this was production, I dry-ran the transaction first with --assumeno:

# 1. Preview (changes nothing) sudo dnf upgrade --security --releasever=latest --assumeno # → confirmed: 2 installs, 7 upgrades # 2. Apply sudo dnf upgrade --security --releasever=latest -y # 3. Verify the default kernel didn't change uname -r && sudo grubby --default-kernel # 4. Swap the processes holding libxml2 (1–2 seconds) sudo systemctl restart php-fpm httpd # 5. Check key pages return HTTP 200, then confirm the count is now truly zero sudo dnf updateinfo list --security --releasever=latest

No reboot; the only service interruption was the 1–2 seconds of restarting php-fpm / httpd. The final check finally showed a real zero.

Takeaways

  • AL2023 repositories are pinned to a release. "Zero" from a plain dnf updateinfo means "zero within the pinned release" — nothing more.
  • Always pass --releasever=latest for security checks and upgrades, and bake it into your scripts.
  • When needs-restarting demands a reboot for a kernel update, verify with uname -r and grubby --default-kernel whether the running kernel line was actually the one updated.

A "zero" only becomes a fact once you know zero relative to what. Errors stand out, so they get questioned; "nothing to report" never does. The quietest command is the most dangerous one — that was the lesson.