#7 - Installing Cisco Packet Tracer 9.0 on Linux Mint 22.3 without XDG, MIME, and icon errors

#7 - Installing Cisco Packet Tracer 9.0 on Linux Mint 22.3 without XDG, MIME, and icon errors
⚠️ Laboratory Simulation Environment Notice:The procedures, diagrams, and configurations described in this article were simulated in a controlled lab environment (e.g., EVE-NG, PNETLab) with basic and/or evaluation licenses. Always test and validate changes in a staging environment before applying them to production systems.

Recently, I installed Cisco Packet Tracer 9.0 on Linux Mint using the official Ubuntu .deb package provided by Cisco Networking Academy.

Cisco provides Packet Tracer through the NetAcad Resource Hub, where the installer is available for Windows, Linux, and macOS:

https://www.netacad.com/resources/lab-downloads

Cisco also provides a simple PDF with the official download and installation instructions:

https://www.netacad.com/skillsforall/files/Cisco_Packet_Tracer_Download_and_Installation_Instructions.pdf

The official process is simple: download the .deb package, authenticate that exact artifact, and install it with apt.

Because a Debian package runs maintainer scripts as root, HTTPS and a hash calculated from the same download are not independent proof of authenticity. Continue only when Cisco provides a signature or digest through an authenticated channel that is separate from the package download. If no such proof is available, stop rather than grant the file root privileges; use a disposable lab VM and the current vendor documentation instead.

That method is correct. However, on my Linux Mint system, I noticed that the Packet Tracer installer may produce some annoying desktop integration errors related to XDG paths, MIME registration, icon cache generation, and file ownership under the user profile.

This post documents what happened, why it happened, and the clean installation procedure that worked for me.


Assumptions

In this post, I will use the following example user:

bwotec

So the home directory used in the commands will be:

/home/bwotec

If your Linux username is different, replace bwotec with your own username.

You can check your username with:

whoami

You can also check your home directory with:

echo "$HOME"

In this example, I assume the Packet Tracer installer was downloaded to:

/home/bwotec/Downloads/CiscoPacketTracer_900_Ubuntu_64bit.deb

or, using the home shortcut:

~/Downloads/CiscoPacketTracer_900_Ubuntu_64bit.deb

The normal Cisco installation method

After the authenticity check described in step 4 succeeds, pass that same absolute path to apt. The complete fail-closed command sequence appears there so an installation command is never separated from its verification gate.

In many Ubuntu-like environments, this is enough.

The installer should:

Install Packet Tracer
Ask for the EULA
Create desktop launchers
Register MIME types
Register icons
Update icon caches
Allow Packet Tracer to start from the menu or terminal

However, on my Linux Mint system, the application installed, but the post-installation scripts produced desktop integration errors.


The problem

During installation, I saw messages like:

Directory '/home/bwotec/.local/share/mime/packages' does not exist!
xdg-icon-resource: No writable system icon directory found.
gtk-update-icon-cache: No theme index file.
ln: failed to create symbolic link '/home/bwotec/.local/share/icons/gnome/index.theme': File exists

Later, when launching Packet Tracer, I also saw a permission error similar to this:

mkdir: cannot create directory ‘/home/bwotec/.local/.packettracer/lib’: Permission denied

So Packet Tracer itself was installed, but some user-level desktop integration files were created incorrectly.


Root cause

The problem was not Linux Mint itself.

The issue came from how the Cisco Packet Tracer .deb package handles some post-installation tasks.

The package runs its installation scripts with root privileges, but those scripts also try to modify files inside the normal user’s home directory:

/home/bwotec/.local

The installer detects the non-root user correctly:

Non-root user: bwotec
Non-root home: /home/bwotec

However, because the package scripts run through sudo, some files under ~/.local may be created as root.

That can later cause permission problems when Packet Tracer tries to write to:

/home/bwotec/.local/.packettracer

Another issue is related to the local icon theme path:

~/.local/share/icons/gnome/index.theme

The Cisco script may expect this file to point to:

/usr/share/icons/gnome/index.theme

But on my Linux Mint system, that file did not exist.

My system had icon themes such as:

/usr/share/icons/hicolor
/usr/share/icons/Adwaita
/usr/share/icons/Mint-Y
/usr/share/icons/Mint-Y-Orange

but not:

/usr/share/icons/gnome/index.theme

Because of that, the installer could create or reuse a broken gnome/index.theme link, and then gtk-update-icon-cache would complain:

gtk-update-icon-cache: No theme index file.

Clean installation procedure

This procedure prepares the expected user-level folders before installing Packet Tracer.

The goal is to avoid the XDG, MIME, icon cache, and permission errors during the first installation.

Again, replace bwotec with your actual Linux username.


1. Prepare the local user directories

Create the user-level directories expected by the installer:

mkdir -p ~/.local/share/mime/packages
mkdir -p ~/.local/share/applications
mkdir -p ~/.local/share/icons
mkdir -p ~/.local/share/icons/gnome

These directories are inside your own home folder.

They do not modify system-wide directories like:

/usr/share/icons
/usr/share/applications
/usr/share/mime

2. Create a local gnome icon theme file

This avoids the broken symlink problem related to:

/usr/share/icons/gnome/index.theme

Create a local index.theme file:

cat > ~/.local/share/icons/gnome/index.theme <<'EOF'
[Icon Theme]
Name=gnome
Comment=Local compatibility icon theme for Cisco Packet Tracer
Directories=48x48/apps,48x48/mimetypes

[48x48/apps]
Size=48
Context=Applications
Type=Fixed

[48x48/mimetypes]
Size=48
Context=MimeTypes
Type=Fixed
EOF

This file is created only inside the user profile:

/home/bwotec/.local/share/icons/gnome/index.theme

It does not change any system theme.

This was the key step that prevented the installer from relying on a broken symlink to a non-existent GNOME icon theme file.


3. Inspect ownership before installing

Before installing, inspect ~/.local for unexpected root-owned entries. Do not run a recursive chown over the whole directory: it is broader than Packet Tracer needs, and a symbolic link placed in a writable tree can redirect an ownership change outside that tree.

find -P ~/.local -xdev -maxdepth 6 -user root -ls 2>/dev/null

The expected result is no output. If the command lists anything, stop and inspect it before installing. Do not pass paths discovered inside a writable home directory to a privileged ownership command: a local process can replace an intermediate directory between inspection and use. Back up the affected application data, remove the incomplete Packet Tracer installation using your distribution’s package workflow, and continue only from a clean user-owned directory tree.


4. Authenticate and install the exact file

Keep the installer in your private Downloads directory. Do not copy a privileged installer to a predictable shared path. First resolve and inspect the exact file without following a symbolic-link surprise:

installer_input="$HOME/Downloads/CiscoPacketTracer_900_Ubuntu_64bit.deb"
test -f "$installer_input" && test ! -L "$installer_input" || exit 1
installer="$(realpath -- "$installer_input")" || exit 1
case "$installer" in
  "$HOME"/Downloads/*) ;;
  *) echo "Installer escaped Downloads" >&2; exit 1 ;;
esac
test "$(stat -c '%U' -- "$installer")" = "$(id -un)" || exit 1

Obtain the expected digest from Cisco through an authenticated channel independent of the package download. Replace the deliberately invalid placeholder below; do not calculate the expected value from the downloaded file itself:

expected_sha256='VENDOR-PUBLISHED-SHA256'
test "$expected_sha256" != 'VENDOR-PUBLISHED-SHA256' || exit 1
printf '%s  %s\n' "$expected_sha256" "$installer" \
  | sha256sum --check --strict - \
  || exit 1

If Cisco supplies a signature instead, use its documented verifier and a key fingerprint confirmed through an independent official channel. If neither a signature nor an authenticated digest is available, stop here.

After that first verification succeeds, copy the exact file into a private, root-owned staging directory. Recalculate the authenticated digest as root over the staged copy, then install only that copy. This closes the interval in which another local process could replace the user-owned installer between the check and the privileged package operation:

staging_dir="$(sudo -- mktemp -d /var/tmp/packettracer-install.XXXXXXXX)" || exit 1
case "$staging_dir" in
  /var/tmp/packettracer-install.*) ;;
  *) echo "Unexpected staging directory" >&2; exit 1 ;;
esac
staged_installer="$staging_dir/packettracer.deb"

cleanup() {
  sudo -- rm -f -- "$staged_installer"
  sudo -- rmdir -- "$staging_dir"
}
trap cleanup EXIT HUP INT TERM

sudo -- install --owner=root --group=root --mode=0600 -- "$installer" "$staged_installer" || exit 1
printf '%s  %s\n' "$expected_sha256" "$staged_installer" \
  | sudo -- sha256sum --check --strict - \
  || exit 1
sudo -- apt install -- "$staged_installer"

Do not forward HOME, XDG_DATA_HOME, or another user-writable directory into a root package script. The user-level directories were prepared before installation; any remaining desktop integration should be repaired later as the unprivileged user or with Cisco’s supported procedure.

When the installer asks for the EULA:

1) Show EULA text again
2) Accept EULA
3) Decline EULA
#?

choose:

2

With the local folders prepared and the gnome/index.theme file created, the installation should complete with messages like:

gtk-update-icon-cache: Cache file created successfully.

In my final installation, the previous errors disappeared.

I no longer saw:

Directory ... mime/packages does not exist
Note that '/home/bwotec/.local/share' is not in the search path
xdg-icon-resource: No writable system icon directory found
gtk-update-icon-cache: No theme index file
ln: failed to create symbolic link ... File exists

5. Check Packet Tracer ownership after installation

Even with the cleaner installation method, the Cisco installer may still create files inside ~/.local as root.

Inspect only the Packet Tracer-related roots without crossing a filesystem boundary:

packet_tracer_paths=(
  "$HOME/.local/share/applications"
  "$HOME/.local/share/icons"
  "$HOME/.local/share/mime"
  "$HOME/.local/.packettracer"
)

for target in "${packet_tracer_paths[@]}"; do
  [ -e "$target" ] || continue
  find -P "$target" -xdev \( -type f -o -type d \) -user root -print
done

The expected result is no output. If a path appears, do not automate an ownership change from that pathname. Stop Packet Tracer, preserve the data you need, and use the package vendor’s recovery/uninstall procedure before repeating the clean installation above. This avoids a time-of-check/time-of-use race in which another local process swaps a writable path before a privileged tool resolves it.

You can repeat the read-only check with:

find -P ~/.local -xdev -maxdepth 6 -user root -ls 2>/dev/null

If something unrelated appears, investigate it separately before deleting or changing anything.

In my case, I once found this file owned by root:

/home/bwotec/.local/share/lesshst

That file was not related to Packet Tracer. It was probably created by running commands with sudo while forcing HOME=/home/bwotec.

Because that file was unrelated to Packet Tracer, it should not be modified as part of this procedure.


6. Final validation

Run:

sudo dpkg --audit
apt list --installed | grep packettracer
which packettracer
find -P ~/.local -xdev -maxdepth 6 -user root -ls 2>/dev/null
packettracer

Expected results:

sudo dpkg --audit

should return nothing.

This command:

apt list --installed | grep packettracer

should show something like:

packettracer/now 9.0 amd64 [installed,local]

This command:

which packettracer

should return:

/usr/local/bin/packettracer

The find command should return nothing, meaning there are no root-owned files left under ~/.local.

Finally, Packet Tracer should start normally:

Cisco_Packet_Tracer_9.0.0:...:/opt/pt/packettracer.AppImage

Do I need to run dpkg-reconfigure packettracer?

In my final clean installation, I did not need it.

I used dpkg-reconfigure packettracer only during troubleshooting to test the package configuration scripts after fixing the icon theme issue.

If Cisco support explicitly asks you to rerun it, use the root environment rather than forwarding user-writable HOME or XDG paths:

sudo -- dpkg-reconfigure packettracer

However, after preparing the directories and creating the local gnome/index.theme before installation, the normal apt install completed cleanly.

So, for a fresh installation, dpkg-reconfigure should not be necessary.


Cleanup

The verified copy in Downloads can be removed if you do not want to keep it:

rm -i ~/Downloads/CiscoPacketTracer_900_Ubuntu_64bit.deb

I used rm -i here so the shell asks for confirmation before deleting the original downloaded installer.


Final notes

The official Cisco installation method is correct for a normal Ubuntu/Linux environment. Cisco’s own installation guide shows the Linux installation using a local .deb package and apt.

The issue in my case was not the apt install command itself. The problem was the Packet Tracer post-installation script behavior on Linux Mint.

The script tries to integrate the application with the desktop environment by registering MIME types, icons, and desktop launchers, but it does this in a fragile way:

It runs as root.
It writes into the normal user's ~/.local directory.
It expects a gnome icon theme path that does not exist on my Linux Mint installation.

Authenticating the exact installer, keeping it out of shared staging directories, preparing the expected user directories, and avoiding user-controlled HOME/XDG values in root package scripts provides the safer installation boundary. A vendor package that cannot be authenticated independently should not be run as root on a trusted workstation.

The application installed correctly, dpkg reported no package issues, the packettracer command was available, and no root-owned files remained inside my ~/.local directory.

Was this configuration guide helpful?

If you have questions, encountered issues during setup, or want to discuss networking and security, connect or reach out on LinkedIn.

Connect on LinkedIn