Kali Linux kali-linux-default metapackage rollback fails after dist-upgrade

Short answer

No — installing an older kali-linux-default version does not automatically downgrade the rest of your system, it does not touch the kernel or bootloader, and yes, mixing an old snapshot with the live rolling archive can cause apt to propose removing packages. A metapackage rollback is rarely the right fix; downgrading the specific broken package usually is.

What the metapackage actually is

kali-linux-default contains no software. It is a bundle of Depends entries that pull in the standard Kali tool set. Downgrading it only changes which dependency constraints apt tries to satisfy going forward — it restores no files and reverts nothing the dist-upgrade already did. The metapackage's version number also has no relationship to the versions of the tools it depends on, so an older metapackage does not imply older tools.

Answers to the three questions

Does installing the older version resolve dependencies to match it?

Not automatically. Apt prefers to keep newer installed packages. It will try to satisfy the older metapackage's constraints, but actual downgrades of installed packages only happen if you explicitly request them (for example with --allow-downgrades or by naming exact versions). And because Kali is a rolling release, the live archive normally carries only current versions — apt cannot even find the older metapackage unless you add a snapshot from snapshot.kali.org to your sources.

What about kernel and bootloader compatibility?

Nothing is needed because nothing changes: linux-image packages and GRUB are entirely separate from the metapackage. The newer kernel stays installed and active. The previous kernel remains bootable from the GRUB menu only if it was not autoremoved. Verify before doing anything else:

dpkg -l | grep linux-image
grep menuentry /boot/grub/grub.cfg

Confirm at least one known-good kernel is present and listed. If your real problem is a broken boot after the dist-upgrade, a metapackage rollback will not fix it — boot the older kernel from GRUB instead.

Risk of package removal?

Yes, this is the main hazard. Tools that were renamed, dropped, or replaced between snapshots can leave apt with unsatisfiable chains, and apt's proposed solution may be to remove packages — occasionally important ones. Mixing a snapshot archive with the live rolling archive makes this worse. Use one coherent snapshot, or revert to the live archive immediately after.

If you still want to attempt it

1. Check which versions your configured sources actually offer: apt-cache policy kali-linux-default and apt-cache madison kali-linux-default.
2. Always dry-run first: apt install --simulate kali-linux-default=<version>. Read the full transaction. Abort if core packages are slated for removal.
3. Afterward, remove the snapshot from sources, then run sudo apt update && sudo apt full-upgrade --simulate against the live archive to confirm the system returns to a consistent, upgradeable state.

The safer path

In most cases the dist-upgrade broke one specific tool or library, not the whole tool set. Identify it, then downgrade or reinstall only that package while keeping the rest of the system on the current rolling snapshot. Capture apt list --installed | grep <tool> and the apt error output before and after so you can confirm the targeted fix worked. This avoids the dependency churn and removal risk of a full metapackage rollback.

Caveats

Snapshot availability, metapackage contents, and archive layout change over time; confirm details against current Kali documentation before relying on any specific version string. If a dry-run shows removals you don't understand, stop and post the simulated transaction for review rather than forcing it.