Repository navigation
Bug: mintinstall doesn't show all installed apps #481
Description
Info
Mint 22.2
Cinnamon 6.4.8
Mintinstall 8.3.9 (updated from 8.3.8 via package on GitHub)
Description
When I click "Show installed applications", only four out of all the apps I installed through the Software Manager are shown, see the screenshot below:
Activity
Condobloke commentedon Oct 18, 2025
I am seeing similar in Menu. Linux Mint 22.2, Cinnamon.
At first, I thought it was only apps downloaded from the web....eg balena etcher
But this is not the case.
Gnu image manipulation program (gimp) was initially downloaded from the Software Manager.
Right click on it in the menu and choose uninstall.
I am told that ""This menu item is not associated to any package. Do you want to remove it from the menu anyway ? ""
A single click on that app proves its existence.
RenanLazarotto commentedon Feb 17, 2026
Double that. On a fresh Mint install, I was expecting to see entries for things like LibreOffice that comes pre-installed, along with everything that can be safely uninstalled if the user (aka me) has no use for, like warpinator or simple-scan, as I have no scanner nor my computer is in a network.
fabv12610 commentedon Mar 30, 2026
I believe this is a not a bug and its intentionaly, when you change the code, it shows every package installed included the system requirements. This causes a almost neverending list of packages that you didnt install
erik-mansson commentedon Apr 18, 2026
Confirming this issue also on mintinstall 8.4.0, noticed after I upgraded from LMDE 6 to LMDE 7.
Specifically, I figured out this interesting behaviour:
After I have done step 5 for eight packages, my list of installed applications in mintinstaller shows precisely those eight. I would have expected this list to actually find already installed packages (e.g. installed by apt-get or Synaptic). If it is intended behaviour that it should only find packages you installed and looked at through mintinstaller, a more correct name might be something like "Show only previously viewed installed applications". But I hope that was not the intent.
In response to @fabv12610 : I didn't understand what you mean by "when you change the code". Maybe you mean that fixing what @Antics419 and I perceive as a bug, and starting to show all (possibly thousands) of installed packages, including libraries, will make the list so long that it becomes impractical in mintinstaller? That may be true, but in the long run it would seem better to have an option for a more compact list view and more abilities to sort & filter (e.g. hide libraries) to be able to work with the long list, e.g. as suggested in #440.
For a possible solution, maybe check out the linked mintbackup issue linuxmint/mintbackup#95 where a pull request presumably fixes it by expanding the parsing of a string list of packages, to not not just match "apt:" but also match "a:" at the start. ZahinTapadar/mintbackup@008c0d6 Could something like this be needed under the hood of mintinstall too, in case some lower-level apt tool changed its output format? (In case it matters, I have apt 3.0.3 and dpkg-query 1.22.22.)
As I anyway prefer the Synaptic GUI, I just used mintinstall to reinstall that (which had been removed by the upgrade). The release notes https://www.linuxmint.com/rel_xia_whatsnew.php mentioned a lack of upstream maintenance for some removed tools (although perhaps not Synaptic specifically), which feels a bit ironic when this issue in mintinstall has been open for half a year. My problem is at least solved by using Synaptic to see (and filter by origin) my installed system packages, although it seems I need to use command-line flatpak to get a complete list of installed flatpak packages.
erik-mansson commentedon Apr 18, 2026
If this bug does not affect everyone, it seems to be caused by not having the file "/var/log/installer/initial-status.gz"! I don't have it, but creating a dummy version of it it solves the problem, see below.
Although I am not familiar with the mintinstall source code, a search showed that Application.sync_installed_apps() calls mintcommon.installer.cache.PkgCache.get_manually_installed_packages(), which will just return None on a system without "/var/log/installer/initial-status.gz", not even trying to return a flatpak list then, and not trying alternative direct apt or dpkg-queries for listing packages. I wrote another comment about this possibly problematic behaviour in the seemingly related mintbackup issue, where the same function is being used.
Based on an Askbuntu answer the purpose of the file initial-status.gz seems to have been to record which packages came from the system installer, as opposed to those added later by the user. And some installers have apparently stopped providing initial-status.gz. (I used mintupgrade 2025.11.21.) So if this distinction between package installaction cause can not be made, it would seem better to list all installed packages (regardless of cause) than to list none as installed. Since also mintinstall seem to be relying on this unreliable function, an issue should perhaps be opened for the mintcommon package instead?
So, to test if the missing file was the only problem, I created a plain text file /tmp/initial-status with a single line saying
(It doesn't seem to matter which package name is used, just a space might work too.)
I then ran
gzip /tmp/initial-statusandsudo mv -n /tmp/initial-status.gz /var/log/installer/initial-status.gzto put this gzipped file where mintcommon expects to find a file with at least one line starting with "Package: ".Now, running mintinstall and going to the "Show installed applications" gives me a long list, including both system packages and flatpak packages! Actually, I can also remove the .gz-file, and mintinstall now keeps showing a list of installed packages (cached somewhere, I guess, but clicking to reload the list of packages didn't clear it.)
So, I guess the question now is just where the bug should be considered to be. Is it a requirement that Linux Mint (Debian Edition) installers create /var/log/installer/initial-status.gz? Should mintinstall create a dummy file there if none exists to work around the mintcommon behaviour? Should mintcommon's
get_manually_installed_packages()work even when the file is missing? I would prefer the latter, so I'll open an issue there too.Cherepanov-Pavel commentedon Jun 13, 2026
After a fresh install of lmde 7, none of the tips above helped me solve the problem. When I run mintinstall through the console, I don't see any errors.
apt install gnome-softwaresolved all the problems with program management for me. A fully correct list of applications is displayed there. I will be glad to use mintinstall when this bug is fixed.