Unwanted factory-image package: prove it, remove it

01What you will learn

• How to find a trail showing where a package came from — and why a trail is not a verdict.
• How to see which other package requires it, before you touch it.
• Why removing one package can give autoremove licence to sweep away more programs — and how to prevent it.
• How to write about harm so that it is true: measured or not.
• How to do a dry run, a real removal and a record the next person will understand.

02Before you start

• A machine running Debian or a system of the same family 🔒 local, on which you have administrator rights.
• You know the name of the package that bothers you (<package> below).
• A backup of what matters and a clear idea of which scripts run on the machine.
• Administrator rights are entered only by the machine's owner. The password is not written in scripts, notes or chat.

03Steps

1. The trail: when and with what it arrived

   The dpkg log keeps when each package was installed (default path: /var/log/dpkg.log; older ones are in dpkg.log.1 and so on). Find the package's line and see what else was installed in the same hour. If hundreds of packages arrived in one minute, it was most likely the image or a bulk install, not a command of ours.

   bash · when the package was installedcopy

   # the lines for the package; replace <package>
   grep " install <package>" /var/log/dpkg.log*
   # packages installed manually (explicitly requested)
   apt-mark showmanual

   ⚠️

   A trail, not a verdict

   "It came with the image" is an inference from a date and neighbouring installs. Record it as an inference. The log may have been rotated and old lines may be gone.

2. Who holds it: reverse dependencies

   Before removing anything, see who requires it. If another installed package depends on it, removing it drags that package along. Be especially careful with metapackages — packages that are only a list of other packages (for example "the whole desktop").

   bash · who requires it and what the metapackage carriescopy

   # only installed packages that depend on it
   apt-cache rdepends --installed <package>
   # what the metapackage itself requires
   apt-cache depends <metapackage>

   ✅

   Rule

   If the reverse dependencies are only metapackages, do not remove "blind". Read the metapackage's list first — step 5 explains why.

3. What it actually does: measured or not

   The most common mistake is to write "it does harm" without numbers. So for every claim of harm, mark it: measured (there is a number, a log or a before-and-after copy) or observation (it seemed so to us). Typical things you can measure: space used, processes that hang and eat CPU, errors in the logs.

   One classic cause of a hanging process: a program that on start launches another, helper process. When the caller's time runs out and it kills only the first, the helper is left an orphan and keeps running. So with "a core at 100%", look at the parent too, not only the program's name.

   bash · which processes use the most CPU (not run)copy

   ps aux --sort=-%cpu | head -n 10

   ℹ️

   The honest record

   Write "measured: …; not measured: …". That way the next person knows what is fact and what is assumption.

4. Check your own code

   A package that is unwanted by you may be needed by a script of yours that nobody recorded as a dependency. Search for the program's name in all your scripts before you remove the package. If you find a call, first prepare a replacement and test it, then remove.

   bash · where the program is calledcopy

   grep -rI "<program>" <scripts-folder>

5. Dry run, and marking the rest

   apt-get -s (--simulate) works out what would happen and changes nothing. The Remv lines are what would be removed. Read them one by one — if you see a program you want, stop.

   If the package is part of a metapackage, removing it also removes the metapackage, and everything the metapackage brought becomes "unneeded", so a later autoremove may clear it. The cure is to mark the rest as manually installed before you remove.

   bash · dry run, then markingcopy

   # 1. dry run: what would go
   apt-get -s purge <package>
   # 2. review what the metapackage carries and choose what stays
   apt-cache depends <metapackage>
   # 3. mark the chosen ones as manual (the list is yours)
   apt-mark manual <package-1> <package-2>

   ⚠️

   Trap: a blind autoremove

   After removal, apt-get autoremove removes packages that were installed automatically and are no longer needed. If you have not marked the rest, it can take more programs with it. Run it as a dry run first: apt-get -s autoremove.

6. The real removal, the check and the record

   When the dry-run result satisfies you, remove the package. purge also removes configuration files; remove leaves them. Choose deliberately: if you may need to go back, remove is gentler.

   bash · removal and checkcopy

   apt-get purge <package>
   # check: the program is gone
   command -v <program> || echo "gone"
   # autoremove — dry run only
   apt-get -s autoremove

   Finally, write the decision down: what was removed, when, why, what replaces it and how to go back. Without a record, the next update or the next person may bring the package back and start over.

   ✅

   Rule

   Dry run first, real run second, and never an automatic clean-up done blind. Every step leaves a trace.

04Check

05What's next

06Sources

1. apt-get(8) — -s/--simulate, purge, remove, autoremove (apt 3.0.3; checked 03.10.2026).
2. apt-mark(8) — manual, auto, showmanual.
3. apt-cache(8) — depends, rdepends, --installed.
4. dpkg(1) — the /var/log/dpkg.log log.
5. KAGAMI's own earlier case with an unwanted package on an AI machine — generalised into a method; the specific data is not published and was not repeated for this revision.