Linux Mint Release History: Ubuntu Bases, LMDE and Support Dates

Linux Mint began with version 1.0 "Ada" on 27 August 2006 and has since shipped 22 major versions, each one built on an Ubuntu base, plus seven releases of Linux Mint Debian Edition (LMDE) built on Debian. Since Mint 17 in 2014, every major version has sat on an Ubuntu long term support (LTS) release and been supported for about five years, with point releases in between. The current release is Linux Mint 22.3 "Zena" (13 January 2026, Ubuntu 24.04 base, supported until April 2029), the 21.x series runs until April 2027, and LMDE 7 "Gigi" is built on Debian 13 "Trixie".

The next release breaks the old pattern. In its September 2026 news post, the project said the next version will be called Linux Mint 27 "Adrien", will be based on Ubuntu 26.04, is scheduled for Christmas 2026, and will be followed by 28 and 29 with no more point releases. This post walks through every era, explains LMDE and the editions, shows how updates, kernels and Secure Boot work, retells the February 2016 ISO compromise and what it changed, and ends with a full download, verify, encrypt, snapshot and upgrade walkthrough.

Key takeaways

• Mint has had four release eras. Versions 1.0 to 4.0 (2006 to 2007) followed their own codebase on top of Ubuntu packages. Versions 5 to 16 (2008 to 2013) followed Ubuntu's six month cycle, with an LTS every fourth release. Versions 17 to 22 (2014 to 2026) used only Ubuntu LTS bases and shipped about four point releases per base. Version 27 onward moves to one numbered release per year, named for the year it is meant for.
• Support dates come from Mint, not from Ubuntu. The Linux Mint "all versions" page lists every supported release with its package base and end date: Mint 22.x until April 2029 and Mint 21.x until April 2027. The underlying Ubuntu release may carry on longer under Canonical's paid Expanded Security Maintenance, but Mint's own components stop getting fixes on Mint's date.
• Point releases are not separate support lines. Mint 22, 22.1, 22.2 and 22.3 all share one end date. A point release is a refreshed ISO plus a set of new Mint tools, reachable from the Update Manager in a few clicks.
• LMDE is the safety net. LMDE exists so Mint can keep its desktop and tools running if Ubuntu ever stopped being usable as a base. It tracks Debian stable, comes only in a Cinnamon edition, and each LMDE major maps to one Debian release: LMDE 5 to Debian 11, LMDE 6 to Debian 12, LMDE 7 to Debian 13.
• Mint builds a lot of its own software. Cinnamon, the X-Apps, Update Manager, Software Manager, Driver Manager, Warpinator, the web app manager and the upgrade tool all come from the project's GitHub organisation, and Timeshift is maintained there too. Those components are patched by Mint, not by Ubuntu or Debian.
• ISO verification is a two step job. Check the SHA256 sum for integrity, then check the GPG signature on sha256sum.txt for authenticity. The February 2016 incident, when the website was altered to point at a backdoored 17.3 Cinnamon ISO, is the reason the second step matters.
• Major upgrades are deliberate. Point releases arrive through the Update Manager. Moving between major versions, such as 21.3 to 22, uses the separate mintupgrade tool and requires a Timeshift snapshot first.

This post sits next to our family histories for the two distributions Mint is built from. For the Ubuntu side, see every Ubuntu release from 4.10 onward and how Ubuntu's LTS, interim, ESM and HWE lifecycle works. For the Debian side, see every Debian release, codename and security support date.

Every Linux Mint release from Ada to Zena

The authority for current support dates is the Linux Mint all versions page, which lists each supported release with its codename, editions, package base and status. Release dates for recent versions (20, 22, 22.3 and LMDE 7) were checked directly against their announcements on the Linux Mint blog, whose archive runs back to August 2007. Dates for older versions come from the release table in the Wikipedia Linux Mint article, which cites those blog announcements, and support end dates for 19 to 22 match the user guide's upgrades page. Where a major version shipped its editions on different days, the table uses the date of the first (usually Cinnamon or Main) edition.

Timeline table

Two quirks are worth knowing when you read the table. Version numbers 23 to 26 were never used: the March 2026 news post called the work in progress "Mint 23 Alfa" as a placeholder, and the September 2026 post replaced that with 27, explaining that the number now represents the upcoming year. And the codename alphabet ran out exactly at the turn. The project has used women's names in alphabetical order since Ada in 2006, reached Zena with 22.3, and said Adrien starts a new series of men's names.

Era one: 1.0 to 4.0, a codebase of its own (2006 to 2007)

Mint 1.0 "Ada" was a beta built on Kubuntu with the KDE desktop. Mint 2.0 "Barbara" switched to Ubuntu and GNOME, and from then until 4.0 "Daryna" the project kept its own codebase, building each release from the previous Mint release while pulling packages from the then current Ubuntu repositories. Releases came roughly a month after the matching Ubuntu release. The .1 and .2 numbers in this period were incremental Mint releases on the same Ubuntu base, not the long term point releases of later years.

Era two: 5 to 16, following Ubuntu every six months (2008 to 2013)

From Mint 5 "Elyssa" in June 2008, Mint dropped minor version numbers, adopted Ubuntu's six month rhythm and marked every fourth release as LTS, matching Ubuntu's LTS years: 5 on 8.04, 9 on 10.04 and 13 on 12.04. From Mint 6 "Felicia" the project stopped carrying its own codebase forward and built each release directly from the latest Ubuntu release. Non LTS versions in this era were supported for about 18 months until Ubuntu cut interim support to nine months in 2013, which is why Mint 15 "Olivia", released in May 2013, ended in January 2014.

This was also the era of many editions. Alongside the Main edition, the project and its community shipped KDE, Xfce, Fluxbox, LXDE and "x64" variants, often weeks or months after the Main release. Mint 12 "Lisa" in November 2011 shipped GNOME 3 with Mint's own GNOME Shell extensions, an approach that led directly to the Cinnamon fork. Mint 13 "Maya" in May 2012 was the first release offered in Cinnamon and MATE editions.

Era three: 17 to 22, LTS bases and point releases (2014 to 2026)

In 2014 the project decided to stop rebasing every six months. Mint 17 "Qiana" sat on Ubuntu 14.04 LTS, and the next three releases, 17.1, 17.2 and 17.3, kept the same base while shipping new versions of Cinnamon, MATE and the Mint tools. That pattern held for six bases: 17 on 14.04, 18 on 16.04, 19 on 18.04, 20 on 20.04, 21 on 22.04 and 22 on 24.04. Each base got about two years of point releases and five years of support.

A few changes in this era shape what you can run today. Mint 19 "Tara" in 2018 dropped the KDE edition, leaving Cinnamon, MATE and Xfce. Mint 20 "Ulyana" in 2020 was offered only as 64-bit (amd64) ISOs, with no 32-bit build. Major releases in this era came out roughly two to three months after the Ubuntu LTS they were built on, so 22 "Wilma" arrived in July 2024 on top of Ubuntu 24.04 from April 2024.

Era four: 27 onward, one release a year (from late 2026)

The project announced the change in stages on its blog. In February 2026 it said it was at a crossroads. On 16 April 2026 (the March news post) it said Mint would adopt a longer development lifecycle, that the next release was planned for Christmas 2026, and that Mint would use the same installer as LMDE, the live-installer, replacing the Ubuntu derived installer. The same post listed the work in progress as Ubuntu 26.04 LTS as the package base, Linux 7.0, a development Cinnamon with a new Wayland screensaver, and a live installer that "supports OEM installations, BIOS/EFI, SecureBoot, and LVM/LUKS".

Ubuntu 26.04 LTS "Resolute Raccoon" itself was released on 23 April 2026, according to Ubuntu's list of releases. On 30 April 2026 the Mint project started publishing HWE ISOs for 22.3, so new hardware would not have to wait a year for a newer kernel on install media. On 13 October 2026 it named the next release Linux Mint 27 "Adrien", said it will be based on Ubuntu 26.04, will ship in at least Cinnamon, Xfce and MATE editions, and said "We'll no longer use point releases". Users will upgrade from 27 to 28 to 29. As of this writing the project has not published a support end date for 27, so do not assume it until the all versions page shows one.

What is LMDE, and how do its releases map to Debian?

Linux Mint Debian Edition is Mint built on Debian instead of Ubuntu. It uses the same Cinnamon desktop and the same Mint tools, but its packages come from Debian plus Mint's own repository. The LMDE 7 announcement on 14 October 2025 gives the reason in one line: LMDE's goal is "to ensure Linux Mint would be able to continue to deliver the same user experience, and how much work would be involved, if Ubuntu was ever to disappear." The same post calls LMDE "one of our development targets, to guarantee the software we develop is compatible outside of Ubuntu", and says it "aims to be as similar as possible to Linux Mint, but without using Ubuntu."

The first LMDE appeared in 2010 as a semi rolling distribution that tracked Debian testing. That model proved hard to keep stable, and the project replaced it. From LMDE 2 "Betsy" in 2015, each LMDE major has been pinned to one Debian stable release. Today LMDE comes in a single Cinnamon edition, and the LMDE download page offers LMDE 7 as a 64-bit Cinnamon ISO.

The LMDE 7 date comes from its announcement and its base from the all versions page. Earlier LMDE dates and end dates come from the project's announcements as collected in the Wikipedia Linux Mint article, which we used as a cross-check rather than a primary source. Debian's own dates for those bases are on the Debian releases page: Debian 13 Trixie was released on 9 August 2025, with regular security support to 9 August 2028 and LTS to 30 June 2030.

Two things follow from that mapping. First, an LMDE release ends long before its Debian base does. Debian gives each stable release about three years of security support plus two years of LTS, but LMDE majors have typically been retired a year or so after the next one ships, because the project has no reason to maintain Mint tools on two Debian bases for long. Second, LMDE receives Debian's security updates directly from the Debian security archive, so the speed of fixes for packages such as OpenSSL or the kernel depends on Debian, while fixes for Cinnamon and the Mint tools depend on Mint.

Since 2025, new desktop features have tended to land in LMDE shortly after the Ubuntu based release that introduced them. The project's July 2026 news post, for example, described a new kernel manager that "supports both Linux Mint and LMDE", and the move to live-installer for the main edition means both bases will share one installer from Mint 27.

Editions: Cinnamon, MATE and Xfce

Every Ubuntu based Mint release since 19 ships in three editions, and the all versions page lists all three for every supported release:

• Cinnamon is the flagship. It is developed by the Mint project itself and is the edition the project calls its most modern and feature rich.
• MATE continues the GNOME 2 desktop. Mint did not create MATE, but it has shipped and supported it since Mint 13 and contributes to it.
• Xfce is the lightest of the three and suits older or low memory machines.

All three editions share the same package base, the same Mint tools and the same support dates. Choosing an edition is a desktop preference, not a support decision. LMDE comes only in Cinnamon.

Historically there were more. KDE editions ran from Mint 1.0 through 18.3, Fluxbox and LXDE editions appeared during the six month era, and Mint 5 to 12 had a "Main" edition with GNOME 2 plus codec free and OEM variants. The KDE edition was the last of the extras to go, with 18.3 "Sylvia" its final release.

What the Mint project builds itself

A large share of what you see on a Mint desktop is code the project writes and maintains in its GitHub organisation. That matters for security because those packages get fixes only from Mint, on Mint's schedule, and they are present on every Mint system whatever the Ubuntu or Debian base.

The Cinnamon repository and the Timeshift repository are the places to check release tags and changelogs. In its August 2026 news post (published 11 September 2026) the project also gave the X-Apps their own site at xapp-project.org, noting that X-Apps libraries and applications are now used in other desktops and distributions.

How the support model works

Mint's support model has three pieces: point releases inside a base, a separate upgrade between bases, and a fixed end date that the project sets for each base.

Point releases inside a base

Within a major version, each point release is a new ISO and a new set of Mint components on the same Ubuntu base. A Mint 22 system and a Mint 22.3 system install the same Ubuntu 24.04 packages from the same archive. What differs is the version of Cinnamon, the Mint tools and the default configuration.

You do not reinstall to move between point releases. When a point release is out, the Update Manager offers it from its Edit menu, and accepting it switches the Mint repository to the new codename and pulls the newer Mint packages. Point release upgrades within one base have always been the low risk path, and the project advertises them in each release announcement.

The project also states that you do not have to take point releases. Every point release on a base shares the same end date, so a Mint 22 machine that never moved to 22.3 is still supported until April 2029, as long as it keeps installing updates. In practice, staying current on point releases matters because bug fixes in Mint's own tools land in the newest point release first.

Upgrades between major versions

Moving from one base to the next, for example from 21.3 to 22, is a different operation. The user guide's upgrades page lists every supported path and is strict about it: "There are no other upgrade paths than the ones listed above. For instance, you cannot upgrade version 21 to version 22 directly, you first need to upgrade it to 21.3, then to 22." It calls point release upgrades "Minor" ("They take just a few minutes") and base changes "Major" ("They can take up to a few hours").

For the 21.3 to 22 upgrade, the user guide says "This is a major upgrade. It can take several hours. You will be asked to be up to date and to prepare system snapshots. Do not rush, do not take shortcuts." It also warns that the upgrade "overwrites files in /etc/ with default configuration files", which you can restore individually from the Timeshift snapshot taken beforehand.

From Mint 27 the shape changes. With no point releases, every yearly release is a major one, and the project has said users will upgrade from 27 to 28 to 29. It has not yet published how long each yearly release will stay supported, or whether the Ubuntu base will change every year or only every two years when a new Ubuntu LTS appears. Until it does, plan on the conservative reading: treat each yearly release as something you upgrade to promptly.

What happens when the Ubuntu base reaches end of standard support

Ubuntu LTS releases get about five years of standard security maintenance from Canonical, then further years under Expanded Security Maintenance (ESM) through Ubuntu Pro. Ubuntu's list of releases, linked from the Ubuntu wiki releases page, gives the end of standard support for each one.

Mint's end dates sit just inside the end of Ubuntu's standard support, not ESM. Ubuntu's list of releases gives standard support until May 2025 for 20.04, June 2027 for 22.04, June 2029 for 24.04 and May 2031 for 26.04. Mint ends each base in April of the same year: Mint 20 in April 2025, Mint 21 in April 2027 and Mint 22 in April 2029. The user guide's upgrade page states the rule plainly: "Each major Linux Mint release is supported for 5 years."

Ubuntu Pro and ESM are Canonical products for Ubuntu systems, and Mint does not document them as a way to extend a Mint release. When a Mint base ends, the supported path is to upgrade to the next base.

There is one exception worth recording. In June 2026 the project said it had sent fixes for a severe mintupdate flaw, CVE-2026-59159, "in both supported and EOL (End-of-Life) Linux Mint and LMDE releases". That was a choice made for one serious bug in a Mint tool, not a policy. Do not count on it.

How updates and kernels work in Mint

Mint uses APT and dpkg underneath, like Ubuntu and Debian, but it puts its own tool in front of them and makes a few choices that differ from its parents.

The Update Manager and its policies

The Update Manager is the graphical way to install updates, and the Linux Mint user guide gives it a full chapter. The policy it describes is short: "it is recommended to apply all available updates and to set up system snapshots, so that you can restore your system in case something goes wrong." The guide recommends automating "daily and boot snapshots" in Timeshift, and notes that snapshots "only cover the operating system itself" and not personal data.

The Update Manager sorts updates into three types, and the guide defines each one:

The guide is candid about the tension with kernels: kernel updates "bring both security patches and bug fixes" and are "important from a security point of view, but also prone to regressions". Its answer is not to skip them, but to keep older kernels installed so you can pick one from the GRUB "Advanced options" menu (hold the left Shift key at boot if the menu is hidden), remove the faulty kernel and reboot.

Its preferences add a package blacklist, mirror selection and automation options. For scripts and cron jobs the guide documents mintupdate-cli:

mintupdate-cli list            # all pending updates
mintupdate-cli list -s         # security updates only
mintupdate-cli list -k         # kernel updates only
sudo mintupdate-cli upgrade -r -s   # refresh the cache, then apply security updates

Plain sudo apt update && sudo apt upgrade also works, but the Update Manager handles Mint specific behaviour such as offering point releases, so it is the path the project documents.

Kernel flavours and HWE kernels

Mint ships the Ubuntu kernel for its base, not a kernel of its own. Within a base, Ubuntu offers the general availability (GA) kernel that the LTS shipped with and, from each later Ubuntu interim release, a hardware enablement (HWE) kernel backported to the LTS. Mint 22 shipped with kernel 6.8, and its "What's new" page said "Linux Mint 22.x point releases will follow the HWE series". By 22.3 the ISO carried kernel 6.14.

When you install a kernel update, the guide explains, "you install a new kernel alongside the existing one", and the computer boots the newest by default. Proprietary drivers such as NVIDIA, AMD and Broadcom modules are rebuilt for each kernel through DKMS, and the guide suggests running dkms status after any kernel change. It also warns that new kernel series usually arrive before proprietary drivers support them, so users of those drivers should stick to the recommended series. You install and remove kernels from the Update Manager under View, then Linux Kernels.

From April 2026 the project began publishing separate HWE ISOs for the latest release. The HWE ISOs page describes them as images that include "a kernel which is newer than the one in the regular ISO", lists kernel 6.14 for the regular 22.3 ISO and 6.17 and 7.0 for the HWE ISOs, and warns that proprietary drivers and third party modules such as NVIDIA, Broadcom and VirtualBox "may have limited support with newer kernels". The project's own advice is to use an HWE ISO only if the regular ISO does not work on your hardware.

That model is about to change. The July 2026 news post said kernel management "was removed from the Update Manager and re-implemented within the System Administration tool" for the next release. The new tool works on kernel series rather than individual kernels: you pick which series to track and how many older kernels to keep, updates for tracked series arrive through the Update Manager, older kernels are removed automatically each week, and a kernel marked as protected is never removed. The post said it supports both Mint and LMDE.

Flatpak in the Software Manager, and no Snap by default

The Software Manager lists APT packages and Flatpaks side by side and shows which is which, with Flathub configured as a Flatpak source. Mint 22 tightened this. Its "What's new" page linked a project blog post explaining why unverified Flatpaks were "a very important security issue", said users "REALLY need to trust where they get their software from", and listed the changes: verified Flatpaks show their maintainer name, "Unverified Flatpaks are disabled by default", and when enabled they are clearly marked and carry no reviews or score. Snap is a different story. The Mint 20 "What's new" page says "Snapd is disabled by default and APT packages are not allowed to install it." The user guide's Snap Store page explains the reasoning: some Ubuntu APT packages had started to install snapd as a dependency and connect the machine to the Snap Store, which the project calls "a store we can't audit". The guide also shows how to re-enable it if you want it: remove /etc/apt/preferences.d/nosnap.pref, run apt update, then apt install snapd. The practical effect is that a Mint system pulls browser style applications either from Mint's own APT builds or from Flathub, not from the Snap Store.

The February 2016 ISO compromise and what it changed

On 21 February 2016 the project posted "Beware of hacked ISOs if you downloaded Linux Mint on February 20th!" on its blog. The post said attackers had made a modified Linux Mint ISO "with a backdoor in it" and had hacked the project's website to point download links at it. According to the post, only the Linux Mint 17.3 Cinnamon edition was affected, only on 20 February, and only for people who downloaded through the website's links: torrents and direct HTTP mirror links were not affected.

The project told users to check the ISO's MD5 sum against the published values, and gave a file path whose presence in a live session showed an infected image. For anyone who had installed it, the advice was to take the machine offline, back up personal data, reinstall, and change passwords for sensitive sites, starting with email. The website was taken down while the team cleaned it up. A second post the same day said the forums database had been compromised in the same attack and that the attackers had acquired a copy of it, including usernames, encrypted passwords and email addresses. It told every forum user to change their passwords on sensitive sites, starting with email.

What changed afterwards

The incident made two weaknesses plain. The checksums lived on the same website the attackers controlled, so an attacker who could change the link could also change the sum. And MD5 was no longer a sound integrity check against a deliberate attacker.

Mint's answer was to move to SHA256 sums and to sign the sums file with a dedicated GPG key, so authenticity no longer depends on the website. The ISO verification chapter of the installation guide now describes two checks: an integrity check, which confirms the download is an exact copy of the file on the servers, and an authenticity check, which confirms the ISO "was signed by Linux Mint, and thus that it isn't a modified or malicious copy made by somebody else". The signing key the guide uses, "Linux Mint ISO Signing Key", was created on 7 June 2016 and has the fingerprint 27DE B156 44C6 B3CF 3BD7 D291 300F 846B A25B AE09. Current Mint releases also include a mint-iso-verify command, and a right click "Verify" action on ISO files, that run both checks.

The broader lesson is not specific to Mint. A checksum published next to the download only proves you got what the server meant to give you. A signature made with a key that you obtained separately, and whose fingerprint you checked against a second source, is what tells you the server was not tampered with.

How Secure Boot and the shim work on Mint installs

Ubuntu based Mint releases boot on UEFI machines with Secure Boot enabled by using the same chain Ubuntu uses. The firmware trusts Microsoft's third party UEFI certificate authority. That CA signs shim, a small first stage loader. Shim carries Canonical's certificate, and Canonical signs GRUB and the Ubuntu kernels. Because Mint uses Ubuntu's shim, GRUB and kernel packages for its base, the signatures carry through to a Mint install unchanged.

One visible sign of that inheritance is in the firmware boot menu. The installation guide's EFI chapter notes: "For technical reasons Linux Mint uses ubuntu as its EFI boot name." If you list boot entries with sudo efibootmgr, the Mint entry is the one called ubuntu.

Two practical consequences follow. Out of tree kernel modules, such as proprietary NVIDIA drivers or VirtualBox modules built by DKMS, are not signed by Canonical. On a Secure Boot system, the driver package asks you to set a password and enrol a Machine Owner Key (MOK) on the next boot through the MokManager screen, after which modules signed with that key load. If that step goes wrong, the machine can stop at a "Secure Boot Violation". The EFI chapter's advice for that case is to restart the installation connected to the Internet without ticking the option to install third party software for graphics and Wi-Fi hardware, or, failing that, to disable Secure Boot in the firmware settings.

You can confirm the state of an installed system from a terminal:

mokutil --sb-state          # SecureBoot enabled or disabled
mokutil --list-enrolled | grep -i 'Subject:'   # MOKs you have enrolled
sudo efibootmgr -v          # boot entries; Mint appears as "ubuntu"

LMDE follows Debian's chain instead: a shim signed by Microsoft that trusts Debian's key, with Debian signed GRUB and kernels. The March 2026 news post noted that the live-installer the main edition will adopt "supports OEM installations, BIOS/EFI, SecureBoot, and LVM/LUKS", so Secure Boot support carries into the installer change.

If you want to remove Microsoft's CA from the chain and enrol your own platform key, see Secure Boot with your own keys. That is an advanced setup with a real risk of an unbootable machine, and it is not something the Mint documentation covers.

Linux Mint, LMDE, Ubuntu LTS and Debian stable compared

The short version: Mint and Ubuntu share most packages and their security fixes, but differ on desktop, Snap and who sets the end date. LMDE and Debian share most packages and fixes, but LMDE ends far earlier than its Debian base.

Walkthrough: download, verify, install encrypted, snapshot and upgrade

This walkthrough uses Linux Mint 22.3 Cinnamon because it is the current release on the download page. Replace file names with the release and edition you download.

Step 1: download the ISO and both sums files

Download the ISO from the download page or a mirror, then download sha256sum.txt and sha256sum.txt.gpg from the same directory. The installation guide says to save the files themselves rather than copying their contents, and not to modify them.

mkdir -p ~/mint-iso && cd ~/mint-iso
ls -l
# expected: linuxmint-22.3-cinnamon-64bit.iso  sha256sum.txt  sha256sum.txt.gpg

Step 2: check integrity with SHA256

sha256sum -b linuxmint-22.3-cinnamon-64bit.iso
grep linuxmint-22.3-cinnamon-64bit.iso sha256sum.txt

The two hashes must match exactly. A shortcut that compares for you:

sha256sum --ignore-missing -c sha256sum.txt
# linuxmint-22.3-cinnamon-64bit.iso: OK

On macOS use shasum -a 256 linuxmint-22.3-cinnamon-64bit.iso. If the sums do not match, download again; do not try to fix the file.

Step 3: check authenticity with GPG

Import the Linux Mint signing key using the full fingerprint from the installation guide, then confirm the fingerprint before you trust it.

gpg --keyserver hkp://keys.openpgp.org:80 --recv-key 27DEB15644C6B3CF3BD7D291300F846BA25BAE09
gpg --list-key --with-fingerprint A25BAE09
# pub   rsa4096 2016-06-07 [SC]
#       27DE B156 44C6 B3CF 3BD7 D291  300F 846B A25B AE09
# uid   [ unknown] Linux Mint ISO Signing Key <root@linuxmint.com>

gpg --verify sha256sum.txt.gpg sha256sum.txt
# gpg: Good signature from "Linux Mint ISO Signing Key <root@linuxmint.com>"

GPG will warn that the key is not certified with a trusted signature. The guide says this is expected. What matters is "Good signature" and the fingerprint. Ideally, compare the fingerprint against a second copy, for example the installation guide page and the key listing on a different keyserver, rather than trusting one source.

If you already run Mint, the built in tool does both checks:

mint-iso-verify linuxmint-22.3-cinnamon-64bit.iso

Step 4: write the USB stick (destructive)

Warning: writing an image erases everything on the target device. Check the device path first, every time.

lsblk -o NAME,SIZE,MODEL,TRAN,MOUNTPOINTS
# Identify the USB stick by size, model and TRAN=usb. Example: /dev/sdb
# Unmount any mounted partitions on it:
sudo umount /dev/sdb* 2>/dev/null

Only after confirming the path:

sudo dd if=linuxmint-22.3-cinnamon-64bit.iso of=/dev/sdb bs=4M status=progress conv=fsync

On Mint, the USB Image Writer tool does the same job with a device picker, which reduces the chance of choosing the wrong disk.

Step 5: install with full disk encryption

Boot the stick, and in the live session start the installer. The Mint 22.x installer is the Ubiquity based installer inherited from Ubuntu.

1. Choose language, keyboard and whether to install multimedia codecs.
2. At "Installation type", choose "Erase disk and install Linux Mint". In the Ubuntu derived installer, the encryption option sits under "Advanced features", alongside LVM.
3. Select "Encrypt the new Linux Mint installation for security". The installation guide confirms this "refers to full disk encryption".
4. Enter a strong passphrase. The guide warns that at this stage the keyboard layout is still set to en_US, so a passphrase typed on another layout may not match what you type at boot. Stick to characters that sit in the same place on both layouts, or check carefully. Losing the passphrase means losing the data; there is no recovery.
5. Optionally choose to overwrite empty disk space, which takes much longer but removes old data.
6. Finish the installation, reboot, and confirm the passphrase prompt appears before the login screen.

The guide also notes "there are issues with this option and some NVIDIA drivers", and suggests that people new to Linux use home directory encryption instead. Full disk encryption is the stronger choice for a laptop that could be stolen, because it also protects system files, logs and swap; just test the NVIDIA driver path on that hardware before you rely on it.

Warning: "Erase disk" wipes the selected disk. On a machine with more than one drive, confirm which disk the installer has selected before you continue.

After first boot, confirm the encryption is in place:

lsblk -f
# look for a crypto_LUKS partition with an LVM volume group inside it
sudo cryptsetup luksDump /dev/nvme0n1p3 | head -20
# Version: 2 and the cipher in use; adjust the device to your system

The installer's encryption covers the root filesystem and swap inside LVM. The EFI system partition and /boot stay unencrypted so the firmware and GRUB can read them, which is why Secure Boot matters as a second layer.

Step 6: take a Timeshift snapshot

Mint's welcome screen and the Update Manager both prompt you to set up Timeshift. Snapshots cover system files; by default Timeshift excludes home directories, so it is not a backup of your documents.

sudo timeshift --list-devices
sudo timeshift --create --comments "fresh install 22.3" --tags O
sudo timeshift --list

Use rsync mode on ext4, or Btrfs mode if you installed on Btrfs with Ubuntu style @ and @home subvolumes. Store snapshots on a separate disk if you can, since a snapshot on the same failing disk does not help.

Step 7: keep it updated

sudo apt update
apt list --upgradable

Then apply updates from the Update Manager, which also offers new point releases from its Edit menu when they appear. Check what you are running at any time:

cat /etc/linuxmint/info
# RELEASE=22.3
# CODENAME=zena
# EDITION="Cinnamon"
grep -E 'UBUNTU_CODENAME|VERSION=' /etc/os-release
uname -r

Step 8: upgrade between major versions

The same steps apply to any base change: 20.3 to 21, 21.3 to 22, and from late 2026, 22.3 to 27. Read the project's upgrade post for the specific version first, because each one lists prerequisites and known issues.

1. Bring the current base up to its last point release through the Update Manager, and apply all updates.
2. Take a Timeshift snapshot and confirm it is listed.
3. Back up home directories separately; Timeshift does not cover them by default.
4. Install and run the upgrade tool, as the user guide describes for 21.3 to 22:

sudo apt update
sudo apt install mintupgrade
sudo mintupgrade

5. Follow the instructions on screen. The guide warns that font rendering may break during the upgrade and become unreadable; do not interrupt the upgrade or close the terminal attached to it.
6. When the tool reports success, remove it and reboot:

sudo apt remove mintupgrade
sudo reboot

7. After reboot, check that /etc/linuxmint/info and /etc/os-release show the new release, compare any customised files in /etc against your snapshot, then take a new Timeshift snapshot.

If mintupgrade cannot be found, the guide says to switch to the default Linux Mint mirror and refresh the APT cache. If the computer no longer boots, it says to boot the live ISO of the new release, run Boot Repair, and if that fails, run Timeshift from the live session, which "is able to scan your drives from the live session and restore your snapshot from there". That is the rollback path; there is no supported downgrade.

Common mistakes

• Treating an Ubuntu date as a Mint date. Ubuntu 22.04 can be extended through ESM, but Mint 21.x ends in April 2027 on Mint's page. Plan from the all versions page.
• Assuming a point release has its own support window. Mint 21.1 does not end before 21.3. They all end together, and newer fixes land in the newest point release first.
• Checking only the SHA256 sum. A matching hash proves the download is intact, not that it is genuine. If the sum came from the same compromised website, it proves nothing. Verify the GPG signature too.
• Trusting a key because GPG imported it. Compare the full fingerprint against a second source. The short ID A25BAE09 alone is not enough to identify a key.
• Upgrading across two bases at once. Go one base at a time: 20.3 to 21, then 21.3 to 22. Skipping is not supported.
• Running mintupgrade without a snapshot. The tool asks for one for a reason. Without it, a failed upgrade means a reinstall.
• Using Timeshift as a backup. Default Timeshift snapshots exclude home directories and usually live on the same disk. Keep a separate backup of personal data.
• Picking LMDE for longer support. LMDE releases end well before their Debian base. Choose LMDE for the Debian base, not for a longer life.
• Using an HWE ISO by default. The project says to use HWE ISOs only when the regular ISO does not work, because third party drivers can lag behind newer kernels.
• Disabling Secure Boot permanently to load a driver. Enrolling a MOK for DKMS modules keeps the chain intact. Turning Secure Boot off is a fallback for broken firmware, not a default.

FAQ

When did Linux Mint start?

Linux Mint's first release was 1.0 "Ada", released on 27 August 2006 and built on Kubuntu 6.06 with the KDE desktop. Version 2.0 "Barbara" in November 2006 moved to Ubuntu 6.10 and GNOME, and the project has been Ubuntu based since. The project's footer says Linux Mint is "copyrighted since 2006".

What is the latest version of Linux Mint?

As of October 2026, the latest release is Linux Mint 22.3 "Zena", released on 13 January 2026 on an Ubuntu 24.04 base and supported until April 2029. The latest LMDE is LMDE 7 "Gigi", based on Debian 13 Trixie. The next release, Linux Mint 27 "Adrien", is scheduled for Christmas 2026.

How long is Linux Mint 21 supported?

All Linux Mint 21.x releases, 21 "Vanessa", 21.1 "Vera", 21.2 "Victoria" and 21.3 "Virginia", are supported until April 2027, according to the Linux Mint all versions page. They are built on Ubuntu 22.04 "Jammy". Upgrade to 22.x before then.

Is Linux Mint 20 still supported?

No. Linux Mint 20.x, built on Ubuntu 20.04, reached end of life in April 2025. It no longer appears on the project's list of supported releases. Upgrade to 21.3 and then to 22.x, one base at a time, or reinstall.

What is the difference between Linux Mint and LMDE?

Linux Mint uses Ubuntu LTS as its package base and comes in Cinnamon, MATE and Xfce editions. LMDE uses Debian stable as its base and comes only in Cinnamon. Both share the Mint tools and desktop. LMDE exists so the project could continue if Ubuntu stopped being usable as a base, and it gives users a Debian based option.

Why is there no Linux Mint 23, 24, 25 or 26?

Because the project changed its numbering. In 2026 it moved to one release a year and decided the version number should represent the upcoming year. The placeholder "Mint 23 Alfa" used during development was replaced with Linux Mint 27 "Adrien" in the September 2026 news post, and the following releases will be 28 and 29.

Does Linux Mint have point releases anymore?

Through Mint 22.3, yes: each base had point releases about every six months. From Linux Mint 27 the project said it will no longer use point releases, so each yearly release is a full version and you upgrade from 27 to 28.

Does Linux Mint work with Secure Boot?

Yes. Ubuntu based Mint uses Ubuntu's Microsoft signed shim, Canonical signed GRUB and Ubuntu kernels, so it boots with Secure Boot on. Third party kernel modules such as NVIDIA drivers need a Machine Owner Key enrolled at the next boot. LMDE uses Debian's signed boot chain.

Does Linux Mint use Snap?

Not by default. Since Mint 20 the project has blocked snapd from being installed implicitly through APT. Users can install it deliberately. The Software Manager offers APT packages and Flatpaks from Flathub instead.

How do I check which Ubuntu version my Linux Mint is based on?

Run cat /etc/os-release and look at UBUNTU_CODENAME, or run cat /etc/upstream-release/lsb-release. Mint 22.x shows noble (Ubuntu 24.04) and Mint 21.x shows jammy (Ubuntu 22.04). /etc/linuxmint/info shows the Mint release and edition.

Where software supply chain hygiene fits on a Mint machine

Mint's packages get their fixes from Ubuntu, Debian or Mint itself, and nothing below changes that, so the fit here is indirect. But a Mint workstation is often where developers build software, and the npm, PyPI, Maven, Go and container dependencies pulled on that machine are not covered by any distribution's security archive and are pulled again every time a laptop is reinstalled or moved to a new base.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. On a Mint workstation that is the route for scanning the repositories and container images you build there, for example before and after a major upgrade changes the system libraries your local builds link against.

Click through it at your own pace, or open it full screen.

The second demo is a real Safeguard CLI session: asked to fix a lodash CVE, the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. The same flow applies to an application dependency in a project you develop on Mint, where a fixed version exists upstream and the change belongs in your repository rather than in a distribution package.

Click through it at your own pace, or open it full screen.

The third demo is a real Android session: you send work to a computer running the CLI and approve each command on the phone with Allow once, Allow for turn or Deny. That fits a Mint desktop left running at home or in an office, where you want to start a dependency check from your phone without giving the assistant free rein over the machine.

Click through it at your own pace, or open it full screen.

To try the CLI, download Safeguard and follow the CLI documentation.

Quick check

Sources

• Linux Mint: all versions (currently supported releases)
• Linux Mint: download LMDE 7
• Linux Mint: HWE ISOs
• Linux Mint: What's new in Linux Mint 22
• Linux Mint: What's new in Linux Mint 20
• Linux Mint blog: Beware of hacked ISOs if you downloaded Linux Mint on February 20th! (21 February 2016)
• Linux Mint blog: All forums users should change their passwords (21 February 2016)
• Linux Mint blog: Linux Mint 20 "Ulyana" Cinnamon released! (27 June 2020)
• Linux Mint blog: Monthly News, January 2024 (31 January 2024)
• Linux Mint blog: Linux Mint 22 "Wilma" released! (25 July 2024)
• Linux Mint blog: LMDE 7 "Gigi" released! (14 October 2025)
• Linux Mint blog: Linux Mint 22.3 "Zena" released! (13 January 2026)
• Linux Mint blog: Monthly News, March 2026 (16 April 2026)
• Linux Mint blog: Monthly News, April 2026 (30 April 2026)
• Linux Mint blog: Monthly News, June 2026 (8 July 2026)
• Linux Mint blog: Monthly News, July 2026 (10 August 2026)
• Linux Mint blog: Monthly News, August 2026 (11 September 2026)
• Linux Mint blog: Monthly News, September 2026 (13 October 2026)
• Linux Mint Installation Guide: verify your ISO image
• Linux Mint Installation Guide: install Linux Mint
• Linux Mint Installation Guide: EFI
• Linux Mint User Guide
• Linux Mint User Guide: Update Manager
• Linux Mint User Guide: Snap Store
• Linux Mint User Guide: Upgrades
• Linux Mint User Guide: How to upgrade to Linux Mint 22
• Linux Mint on GitHub: Cinnamon
• Linux Mint on GitHub: Timeshift README
• Ubuntu wiki: Releases
• Ubuntu project documentation: list of releases
• Debian: releases
• Wikipedia: Linux Mint (used only to cross-check older release and LMDE dates)

Last reviewed: 24 October 2026. Linux Mint support dates and the release plan for Mint 27 can change; check the Linux Mint all versions page and the project blog before planning an upgrade.