VPN Package Removal Failed in prerm: What to Check First

Uninstalls can stop partway with an error naming a maintainer script, leaving the VPN half-removed: configuration files remain, the service may still run, and the package manager refuses to continue. The tempting fix in an old forum thread is to delete the script and force the removal. That treats the symptom and discards the cleanup step that failed. Read the stage and the package state first.

Which lifecycle step actually failed

Debian packages run preinst and postinst on installation, and prerm and postrm on removal or purge, with each script's exit status driving the next action. An error from prerm means removal stopped before the package's files were deleted; an error from postrm means removal already happened and cleanup failed. Those are different situations with different recovery. Distribution policy also expects scripts to tolerate a repeated run, because a failed stage should be retried rather than avoided.

Capture the first error verbatim, together with the package name, version and distribution release. Later errors are usually consequences.

Read the package state before changing it

Ask the package manager what it thinks happened before issuing another command.

dpkg -l vpn-package
dpkg --audit
apt-get -s remove vpn-package

The listing shows the package's state flags, the audit finds packages left broken or half-configured, and the simulated removal prints what apt would do without touching anything. A simulation that fails at the same script confirms the stage rather than the network. Note the script named in the error and list the package's info files if you need to see which scripts exist. None of that justifies editing those files yet.

Protect the management path before repair

If the VPN carries your only SSH session to this host, removing it ends your access in the middle of the repair. Arrange a console, an out-of-band management interface or a second route first, and confirm it works before starting. Preserve the profile and any re-enrolment instructions you will need afterwards, because a purge may remove generated configuration. Keep credentials out of the notes you paste into a ticket, and keep private keys out of the diagnostics entirely.

Treat a documented manual override as a last resort under the package owner's guidance, with the skipped steps accounted for. Never delete scripts by wildcard, because the package's own cleanup list is the record of what still needs doing.

Separate package, network and credential outcomes

Three results need checking independently once the supported procedure finishes. The package transaction should show a clean state, with no half-configured entries left in the audit. The network should match what you intended: the right service stopped, no stale routes or DNS settings, and a working path for replacement or direct access. The remote side is the third result, and obsolete credentials should be retired through whoever owns that account, since uninstalling a client revokes nothing.

Then reconnect and test one permitted destination. A clean package state with a still-running tunnel is a different outcome from a clean network, and only the second tells you the removal actually took effect.