Snap Revert Limits in KDE Neon: Unresolved Behavior After Failed Upgrade

Answer to the Open Questions

1. Configuration files that belong to the snap’s confined data directories (e.g., /var/snap//common) are preserved when you run snap revert. Any files the new revision wrote outside those directories—/etc, user home, or system‑wide units—are not automatically undone; you must delete or restore them manually.
2. Snapd keeps a small pool of revisions per package. KDE Neon follows the default of three retained revisions, but the number can be changed with refresh.retain in /etc/snapd/snapd.conf. You can view the current set with snap list --all.
3. snap revert only affects the snap package itself. A kernel updated by apt is outside snapd’s control, so it must be rolled back with the normal Debian kernel rollback path (apt, grub, systemd‑boot, etc.).

Why the Behavior Occurs

• Snap’s confinement isolates the snap’s runtime and data from the host; therefore configuration outside the snap is considered host‑level work and is left untouched.
• The default three‑revision policy keeps the system lean while still allowing a quick revert; older revisions are automatically purged during a refresh.
• System packages such as the kernel are managed by the host’s package manager, not by snapd, so snap revert cannot influence them.

Practical Steps for a Failed Upgrade

1. Verify Which Revisions Are Still Available

snap list --all

Look for the revision and tracking‑channel columns. The row marked current is the one in use.

2. Adjust Revision Retention (Optional)

# Edit the snapd configuration
sudo nano /etc/snapd/snapd.conf
# Add or change the line
refresh.retain=5
# Restart snapd to apply the change
sudo systemctl restart snapd

After the restart, snap list --all will show up to five revisions per package.

3. Revert to the Previous Snap Revision

sudo snap revert <package-name>

Verify that the snap’s files now match the earlier revision by inspecting /var/snap/<package-name>/current versus /var/snap/<package-name>/common.

4. Clean Up Host‑Level Configuration

Identify any files that the new revision created outside the snap’s data directory. Common locations include:

• /etc/<package>
• ~/.config/<package>
• Systemd unit files in /etc/systemd/system

Restore them from backup or delete them to match the state of the previous revision.

5. Roll Back a Kernel Update (If Needed)

# List installed kernels
apt list --installed | grep linux-image
# Install the older kernel (replace old-version)
sudo apt install linux-image-old-version
# Update the boot loader and reboot
sudo update-grub
sudo reboot

6. Verify the System is Stable

After reboot, check that the snap is running the expected revision and that the kernel version matches your desired state. Test any affected services or user workflows to confirm recovery.

Ask for a Missing Diagnostic Detail

Could you confirm whether the configuration files that changed during the upgrade were stored inside the snap’s common directory or elsewhere (e.g., /etc or the user’s home)? Knowing that will help clarify whether any further manual cleanup is required.