Ubuntu 6.06 LTS Dapper Drake: Release Facts, Kernel 2.6.15, Security

Ubuntu 6.06 LTS "Dapper Drake" was released on 1 June 2006 with Linux kernel 2.6.15.6 and the GNOME 2.14.1 desktop, and it was the first Ubuntu release with long term support: three years on the desktop and five on the server. Desktop support ended on 14 July 2009 and server support ended on 1 June 2011, so every 6.06 system has been without security updates for more than fifteen years.

Dapper matters today for two reasons. It set the support model that every later LTS grew out of, and it still turns up in old appliances, lab machines and forgotten virtual machine images. Below are the release facts with a citation for each, the story of why it shipped six weeks late, what it changed from 5.10 "Breezy Badger", the security defaults it shipped with, and how to recognise and deal with a Dapper system in an inventory. Where an official page does not state a fact, we say so rather than fill the gap from memory.

Key takeaways

• Released 1 June 2006, codename Dapper Drake. The date comes from the official release announcement and Canonical's press release, both cited below. The current release notes page does not state the day.
• Why 6.06: Ubuntu version numbers are year and month of release. Dapper was planned for 20 April 2006 and was moved after Mark Shuttleworth proposed a six week delay for testing, certification, localisation and polish.
• First LTS. The release announcement calls it the first Ubuntu release with a long term support cycle: free security updates for three years on the desktop and five years on the server.
• Kernel Linux 2.6.15.6, with separate kernels tuned for servers, including a "big iron" kernel for systems with more than 8 CPUs.
• GNOME 2.14.1 desktop, OpenOffice.org 2.0.2 and X.org 7.0, plus a new graphical installer that ran from the Live CD.
• Support ended for the desktop on 14 July 2009 and for the server on 1 June 2011. There was never an ESM, Ubuntu Pro or Legacy add-on period for 6.06.
• Security defaults: the root account was locked and the first user administered the system through sudo, a model 5.10 already used. AppArmor, ufw, Secure Boot and installer disk encryption are not mentioned anywhere in the 6.06 notes.
• Upgrade path: the only supported path out of 6.06 was to 8.04 LTS, which is itself long past end of life. Treat any 6.06 machine you find as something to retire or rebuild, not upgrade in place.

What are the Ubuntu 6.06 LTS release facts?

A note on sources. The modern release notes page for 6.06 on documentation.ubuntu.com is a migrated copy of the original wiki notes. The old wiki pages, such as DapperReleaseNotes, no longer resolve, so for dates and context we used the official ubuntu-announce and ubuntu-devel-announce mailing list archives on lists.ubuntu.com, plus archived copies of official ubuntu.com and wiki.ubuntu.com pages from the Wayback Machine. Each archived link above names the original URL and the snapshot date.

When was Ubuntu 6.06 released, and why is it called 6.06?

Ubuntu 6.06 LTS was announced on 1 June 2006 by Matt Zimmerman on the ubuntu-announce list, with desktop and alternate install CDs for Ubuntu, Kubuntu and Edubuntu across several architectures. Xubuntu 6.06 was announced the same day in a separate post, and a SPARC server build followed later in June. Canonical's press release for the launch gives the same date.

Ubuntu version numbers encode the year and month of the release, so 6.06 means June 2006. Every Ubuntu release before it had shipped in April or October: 4.10, 5.04 and 5.10. Dapper broke the pattern because it slipped by six weeks.

The six week delay

The Dapper release schedule on the Ubuntu wiki, as archived on 15 March 2006, ran from open development on 20 October 2005 through feature freeze on 23 February, beta on 23 March, a release candidate on 13 April and the final release on 20 April 2006.

On 10 March 2006 Mark Shuttleworth posted a proposal to the ubuntu-devel-announce list for a six week delay. His reasons, in summary:

• Testing. Dapper users were expected to be newer to Linux and more often in corporate settings, so more testing time would catch more bugs before a long support period began.
• Certification. Hardware and software vendors were certifying Dapper, and the project was working towards LSB 3.0 certification. More time reduced the risk of missing it.
• Localisation. Better support for Chinese, Japanese and Korean fonts, input methods and translations, plus more time for translators in Rosetta.
• Polish. Theming work across Ubuntu, Kubuntu and Xubuntu, and time to make Xubuntu part of main with its own ISOs.

He said the team could still hit 20 April but described Dapper as the first "enterprise quality" release of Ubuntu, one the project would live with for five years. The proposal went to community meetings and then to the Tech Board and Community Council. The final decision message is not in the March 2006 list archive we fetched, so we cannot quote it; what the record does show is that the release shipped on 1 June, which is six weeks after the original date.

What made it the first LTS?

The release announcement states it plainly: 6.06 was the first Ubuntu release with a long term support cycle, with free security updates and commercial support for three years on the desktop and five years on the server. The release notes repeat the same three and five year promise. Before Dapper, Ubuntu releases were supported for 18 months, as the 5.10 release notes say.

Canonical's press release framed the LTS around large organisations, with a turnkey LAMP server install, server tuned kernels and paid support available worldwide. It also stressed that the security updates were free, with no subscription needed per deployment.

The archived wiki page on LTS, from 2010, explains how the model worked in practice. An LTS cycle was more conservative: packages were synced from Debian testing rather than unstable, the alpha stage was shorter and there was an extra beta. The same page notes that the LTS label applied to specific parts of the archive and did not automatically cover every edition. It lists Dapper, Hardy and Lucid as the three LTS releases up to 2010.

The Dapper timeline

One small disagreement between official sources: Canonical's archived news index dates the 5.10 release 13 October 2005, while the archived wiki Releases table gives 12 October 2005. We show both. Neither affects any 6.06 date.

What kernel did Ubuntu 6.06 ship?

The 6.06 release notes list Linux 2.6.15.6 under "Under the hood". Canonical's kernel lifecycle page today only covers releases from 14.04 LTS onward, so it has nothing to add for Dapper, and there was no hardware enablement kernel series for 6.06 in the sense the term is used now.

What the notes do describe is a split between desktop and server kernels, which was new:

• Server kernels tuned for server workloads, described as tuned differently from the desktop kernels for better server performance.
• A low end server kernel that is generic and runs on the same hardware as the desktop kernel.
• A high end "big iron" kernel for systems with more than 8 CPUs, naming ES7000, Summit and BIGSMP platforms.

The exact kernel package names are not stated in the release notes, so we do not list them. If you need to confirm the kernel on a machine you suspect is Dapper, uname -r shows the running kernel; on a stock 6.06 install it would report a 2.6.15 series kernel. The uname -r and hwe-support-status --verbose commands are the ones Canonical's kernel lifecycle page uses for current releases; hwe-support-status did not exist in the Dapper era and you should not expect it on a 6.06 system.

What desktop and installer did Ubuntu 6.06 ship?

GNOME 2.14.1 and the desktop stack

The Desktop CD shipped GNOME 2.14.1, OpenOffice.org 2.0.2 and X.org 7.0. The release notes also list faster startup and login, a simplified menu layout, a graphical shutdown, GNOME Power Manager for power settings, better video playback and an optional NetworkManager for moving between wired and wireless networks. Kubuntu had its own release notes on the old wiki; that page no longer resolves, so we do not state the KDE version.

The Live CD installer

The headline change for most users was the installer. 6.06 introduced "a new, very fast, graphical installer based on the Live CD", so a user could boot the Desktop CD, try Ubuntu without changing the disk and then install from the running session. The release notes link to a list of known issues in Ubiquity, which is the installer's name, and say the alternate install CD remained available if the Desktop CD installer failed.

Other installation and upgrade changes in the notes:

• Install to USB devices, such as removable hard drives and flash memory, through the text mode installer.
• A new upgrade tool for moving from one Ubuntu release to the next, starting with upgrades from 5.10.
• A single stage alternate installer that reboots straight into the complete system. In 5.10 the installer still had a separate second stage after the first reboot.
• The system PATH set in one place, /etc/environment.

Images on the CD

The old-releases directory for Dapper lists Desktop, Server, Alternate and DVD images for 6.06 and 6.06.1. For 6.06.2, the directory holds only server install images, for amd64, i386, PowerPC and SPARC. The directory's own description says server images were built for x86, AMD64, PowerPC, SPARC, HP PA-RISC and IA-64, with the desktop CD for x86, AMD64 and PowerPC.

How long was Ubuntu 6.06 LTS supported?

The desktop end of life notice, posted by Steve Langasek on 8 July 2009, says that after 14 July Ubuntu Security Notices would no longer include information or updated packages for the 6.06 desktop. The server edition carried on until June 2011. The same notice pointed to a published list of the source packages that would keep receiving server security updates after the desktop ended; that list was hosted on people.ubuntu.com and we did not fetch it, so we cannot say which packages it named.

On 1 June 2011, exactly five years after release, Matt Zimmerman posted the final notice. It calls 6.06 "a major milestone for the Ubuntu project, being the first long-term release" and repeats the supported path: upgrade to 8.04 LTS Server.

Why there is no ESM for 6.06

Extended Security Maintenance did not exist during Dapper's life. Canonical's current release cycle page and ESM page list ESM and Legacy coverage starting at 14.04 LTS. Nothing on either page covers 6.06, and no official page we fetched offers a paid extension for it. In practice that means a Dapper system has received no security updates from Canonical since June 2011 on the server and July 2009 on the desktop.

For the full picture of how the support model grew from Dapper's three and five years to ten and fifteen years with Ubuntu Pro, see our Ubuntu release support lifecycle explainer and Ubuntu Pro and ESM history.

Where the archive went

When a release reaches end of life, its package archive moves off the main mirrors. The old-releases archive still holds the Dapper suites: dapper, dapper-security, dapper-updates, dapper-proposed and dapper-backports, at old-releases.ubuntu.com/ubuntu/dists. The directory timestamps for dapper-security and dapper-updates are April 2011, just before the server end of life. Those packages are frozen. Nothing new will ever be published there.

What security defaults did Ubuntu 6.06 have?

The 6.06 release notes are about features, not security, so most of what follows comes from other official Ubuntu pages of the period. Where we could not tie a default to 6.06 specifically, we say so.

sudo with the root account locked

The Ubuntu wiki's RootSudo page, as archived in November 2006, describes the default: the root account is locked, so you cannot log in as root or use su. The installer sets up sudo so the user created during installation can run administrative commands, and sudo asks for that user's own password, not a root password. The page notes that sudo remembers the password for 15 minutes by default.

This was not new in 6.06. The archived 5.10 release notes already say the first user account created has administrative rights through sudo. So the sudo model carried over from Breezy into Dapper unchanged, as far as the official pages show.

What it meant in security terms: there was no shared root password to leak or reuse, administrative actions were tied to a named user, and, because root had no password, nobody could log in as root with one. Our 16.04 post shows how far the defaults moved on from here.

No listening network services after install

The Ubuntu Security Team publishes a set of default policies on the wiki. The archived copy we fetched is from July 2011, and it states that a default Ubuntu installation must have no listening network services after the initial install, with exceptions for network infrastructure such as the DHCP client and mDNS. On Ubuntu Server, the administrator chooses which services to add on top.

We could not find an archived copy of this policy from 2006, and the 6.06 release notes do not mention it. So we can say it was the stated policy by 2011, which covers the last two years of Dapper's server support, but not that it was written down at Dapper's launch. The 6.06 notes do describe the server install as a minimal profile designed to have services added on top, which is consistent with it.

The security pocket and security notices

Dapper had a dedicated security suite, dapper-security, separate from dapper-updates. That suite still exists on old-releases.ubuntu.com. Security fixes were announced as Ubuntu Security Notices, and the end of life notices tell users that all security update announcements go to the ubuntu-security-announce mailing list. Today the same notices are on ubuntu.com/security/notices, with a mailing list and RSS feed; our guide on how to subscribe to Ubuntu and Debian security advisories covers how to follow them.

The release notes mention that the alternate CD can be added to an upgrade through Synaptic and update-manager, so both tools existed in 6.06. The notes do not describe the update notifier, its default schedule or whether security updates were installed automatically. We mark automatic installation of updates as not stated.

What the 6.06 notes do not mention

These are the security features later Ubuntu posts in this series cover. For Dapper, none of them appears in the official 6.06 notes or the announcement:

We have not filled any of these in from memory. If you need to know whether a specific Dapper system has a firewall or mandatory access control enabled, inspect the system itself, and assume it does not.

A CVE example: the Debian OpenSSL weak key bug on 6.06

The best known Ubuntu security event of Dapper's lifetime is CVE-2008-0166, announced on 13 May 2008 in USN-612-1. A Debian specific change to OpenSSL's random number generator made generated keys predictable, which affected SSH keys, OpenVPN keys and SSL certificates. The Ubuntu CVE page gives it Ubuntu priority Critical.

The interesting detail for Dapper is in the CVE tracker's status table:

The CVE description says the flaw was in OpenSSL 0.9.8c-1 up to versions before 0.9.8g-9 on Debian based systems, and USN-612-1 lists 7.04, 7.10 and 8.04 LTS as affected releases. Dapper's own OpenSSL was not vulnerable. Dapper still received an OpenSSH update and the blacklist package, because a weak key generated on an affected machine and copied onto a Dapper server is just as guessable there. The USN notes that other systems can be indirectly affected if weak keys are imported into them.

The lesson carries over to any old release: "not affected" for the package does not always mean "nothing to do" for the host. The fix for Dapper was to update OpenSSH so it could reject known weak keys, and to regenerate any keys that came from an affected system. To confirm a host has a fix, compare the installed package version with the fixed version in the tracker. Our post on checking distro backported security fixes walks through that comparison.

What changed from Ubuntu 5.10 "Breezy Badger" to 6.06 LTS?

The documentation.ubuntu.com release notes index starts at 6.06 and has no page for 5.10; the 5.10 URL returns 404. The original Breezy release notes on wiki.ubuntu.com survive in the Wayback Machine (snapshot of 10 November 2006), and that is what the 5.10 column uses.

The interim releases between Dapper and the next LTS (6.10 Edgy Eft, 7.04 Feisty Fawn and 7.10 Gutsy Gibbon) are covered in the series hub, the Ubuntu release history. Official notes for 6.10 and 7.04 are not on documentation.ubuntu.com either.

Why is Ubuntu 6.06 still relevant?

Nobody should be deploying Dapper in 2026. It still matters for three practical reasons.

It set the template. The LTS idea, a release every two years with a longer promise attached, started here. Every support date you plan around today, from 22.04 to 26.04, descends from the three and five year commitment in the 6.06 announcement.

It still turns up. Long lived hardware is the usual source: appliances, lab and test equipment, industrial controllers, thin clients and old virtual machine templates that were built once and copied for years. A five year server promise made in 2006 encouraged exactly that kind of long deployment. Some of those systems outlived the support window and were never rebuilt.

It shows what "end of life" means at the extreme. A Dapper server has gone more than fifteen years without an Ubuntu security update. Every vulnerability published since June 2011 in OpenSSH, OpenSSL, the kernel, Apache, PHP, Samba or any other package it ships is, unless proven otherwise, unfixed on that host.

How to recognise a 6.06 system in an inventory

You will usually meet Dapper as a line in an asset list or a scan result, not as a desktop. Signals that point to it:

• Release strings. Any tool that reads the distribution release will report 6.06 or the codename dapper. The Ubuntu Desktop docs use lsb_release --description to show the release; whether lsb_release is present on a given minimal Dapper install is not stated in the 6.06 notes.
• Kernel version. A running kernel in the 2.6.15 series on an Ubuntu host is a strong hint.
• Package versions. Ubuntu package versions carry release specific suffixes. The CVE tracker lists, for example, OpenSSH 1:4.2p1-7ubuntu3.4 as the Dapper fix for CVE-2008-0166. A package inventory showing OpenSSH 4.2p1 with an ubuntu suffix points to Dapper.
• Package sources. An APT source line naming dapper, dapper-security or dapper-updates, or pointing at old-releases.ubuntu.com for those suites, identifies the release directly.
• Toolchain and library versions. glibc 2.3.6 and GCC 4.0.3 in an SBOM of an Ubuntu based image or appliance firmware are consistent with 6.06.

Our guides on checking whether a base image operating system is end of life and on where to get end of life dates cover the same checks for newer releases.

How do you check and handle a suspected 6.06 system?

These steps only read state until the last one. Commands come from Canonical's current documentation; where a command would not exist on a Dapper machine, we say so.

Step 1: Confirm the release

The Ubuntu Desktop docs use this to show the installed release:

lsb_release --description

On a Dapper machine the description should name Ubuntu 6.06. If the command is not installed, look at the APT source configuration for the dapper suites, as described in the inventory section above.

Step 2: Confirm the running kernel

uname -r

The kernel lifecycle page uses uname -r to identify the running kernel. A 2.6.15 series result matches the 6.06 release notes. Do not expect hwe-support-status on Dapper; it belongs to later releases.

Step 3: Accept that there is no coverage to check

On a supported release you would run pro status or pro security-status next. Neither applies to 6.06. Canonical's release cycle and ESM pages list nothing older than 14.04 LTS, and the 2011 end of life notice is the last official word on security updates for Dapper.

Step 4: Isolate it while you plan

If the machine must keep running for now, take it off any network it does not strictly need, remove inbound access from the internet and untrusted segments, and record who owns it and why it still exists. Our post on end of life software: upgrade, extend, isolate or retire lays out the options.

Step 5: Rebuild rather than upgrade in place

The supported upgrade path in 2009 and 2011 was 6.06 to 8.04 LTS. Today's Ubuntu Server upgrade guide says you can only upgrade from one LTS to the next sequential LTS and cannot skip releases, so reaching a supported release from 6.06 would mean a chain through 8.04, 10.04, 12.04, 14.04, 16.04, 18.04, 20.04, 22.04 and 24.04 to 26.04, every intermediate one long out of support and with its archive moved to old-releases. For a current release, that guide documents the process as:

sudo apt update
sudo apt dist-upgrade -o APT::Get::Always-Include-Phased-Updates=true
sudo do-release-upgrade

Those commands are documented for current releases. The 6.06 notes describe upgrades through update-manager and a new upgrade tool, not these commands, so do not expect them to work on Dapper. The practical answer for a 6.06 system is to build a fresh machine on a supported LTS, move the data and the workload across, test, and retire the old host. If the system is a vendor appliance, the fix has to come from the vendor.

Where to get official Ubuntu 6.06 ISOs, and why not to run them on a network

The official images are on old-releases.ubuntu.com/releases/dapper/, which also answers to the 6.06, 6.06.1 and 6.06.2 paths. The directory carries MD5SUMS, SHA1SUMS and SHA256SUMS files with matching .gpg signature files, so you can verify an image before use. Do not download Dapper from third party mirrors or archive sites. The old releases index lists every retired release in one place.

Legitimate reasons to boot one: reproducing a historical bug, testing whether a legacy application can be migrated, forensic comparison with an appliance, or teaching. Do it in an isolated virtual machine with no network, or a host only network at most. A Dapper install has an OpenSSH, OpenSSL, kernel and browser stack from 2006 to 2011 with no fixes after that; exposing it to the internet or a shared network gives anyone on that network a target with more than fifteen years of public vulnerabilities. Our package signing post explains how to check the signature chain on Ubuntu images and packages.

Common mistakes

• Treating "LTS" as "still supported". Dapper is an LTS and has been end of life since 2011. LTS is a promise with an end date, not a permanent status.
• Assuming 6.06 has ESM or a Legacy option. It never did. Canonical's ESM and release cycle pages start at 14.04 LTS.
• Reading desktop and server dates as one. The desktop ended on 14 July 2009, the server on 1 June 2011. Inventory tools that record only one date can be wrong in either direction.
• Calling it 6.04. The release was planned for April and shipped in June, which is why it is 6.06.
• Trying to upgrade in place across nine LTS releases. The supported path from 6.06 was only ever to 8.04, and every hop after that is also unsupported. Rebuild on a current LTS.
• Pointing a Dapper machine at old-releases and calling it patched. The dapper-security suite there is frozen as of 2011. Installing every update from it brings the machine to 2011, not to safety.
• Concluding "not affected" means "no action". CVE-2008-0166 did not affect Dapper's OpenSSL, yet Dapper still needed an OpenSSH update and key regeneration for keys made elsewhere.
• Running an old ISO on a live network "just to check something". Use an isolated virtual machine.
• Filling missing facts from memory. The official notes do not state Dapper's AppArmor, firewall or hardening defaults. Inspect the system rather than assume.

FAQ

When was Ubuntu 6.06 released?

On 1 June 2006, according to the official release announcement on the ubuntu-announce list and Canonical's press release. It was originally scheduled for 20 April 2006.

Why is it called Ubuntu 6.06 and not 6.04?

Ubuntu versions are the year and month of release. Dapper was delayed by six weeks to allow more testing, certification, localisation and polish, so it shipped in June 2006 and became 6.06.

Was Ubuntu 6.06 the first LTS release?

Yes. The release announcement describes it as the first Ubuntu release with a long term support cycle, and the 2011 end of life notice calls it the first long term release.

What kernel does Ubuntu 6.06 use?

Linux 2.6.15.6, according to the 6.06 release notes. The server edition had separate tuned kernels, including one for systems with more than 8 CPUs.

What desktop does Ubuntu 6.06 use?

GNOME 2.14.1, with OpenOffice.org 2.0.2 and X.org 7.0. Kubuntu 6.06 had its own release notes, which no longer resolve, so we do not state its desktop version.

Is Ubuntu 6.06 still supported?

No. Desktop support ended on 14 July 2009 and server support on 1 June 2011. There is no ESM, Ubuntu Pro or Legacy coverage for 6.06.

How long was Ubuntu 6.06 LTS supported?

Three years on the desktop and five years on the server, as stated in the release notes and the release announcement.

Can I upgrade Ubuntu 6.06 to a current release?

Not in any practical way. The supported path was to 8.04 LTS, and current Ubuntu documentation says LTS upgrades cannot skip releases. Build a new system on a supported LTS and migrate the workload.

Where can I download Ubuntu 6.06?

From old-releases.ubuntu.com/releases/dapper/, which has the 6.06, 6.06.1 and 6.06.2 images with signed checksum files. Use them only in isolated test environments.

Did Ubuntu 6.06 have a root password?

No. The root account was locked by default, and the user created during installation ran administrative commands through sudo with their own password.

Fix it without waiting for upstream

A Dapper system is the extreme case of an operating system nobody patches anymore: no USNs since 2011, no ESM, no Legacy add-on. The workloads that used to run on it, and the applications built on its libraries, often carry their own dependencies that were never updated either. When you rebuild on a supported release, the operating system packages are back under Canonical's care, but the npm, PyPI, Maven, Go and Rust dependencies pinned in your services are still your job.

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

Safeguard scans repositories, container images and SBOM files and matches the components it finds against vulnerability databases, so an image or exported file system built on an old Ubuntu base shows its OS packages and versions next to its application dependencies:

safeguard scan --dir .
safeguard scan --image your-image:tag
safeguard scan --sbom sbom.json

Results are written as JSON under ./output, and the platform shows every project that contains a given component and version, which is how you would find every image or SBOM still carrying Dapper era packages such as OpenSSH 4.2p1. Safeguard does not patch a 6.06 host, its kernel or a vendor's appliance firmware, and it cannot bring back security updates Canonical stopped in 2011. What it can do is make the old components visible and help move the services you own onto supported bases with fixed dependencies.

In this Safeguard CLI session you install the CLI, run safeguard to open the interactive terminal and ask it to fix the lodash CVE in a repository. It 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. When you migrate a workload off a Dapper machine, this is the same flow you would use to bring the application's own dependencies up to fixed versions on the way.

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

This demo sets up the Safeguard runner on your own machine, approves it with its device code, then scans from the terminal. For an old appliance image or a file system copied off a legacy host, that means the scan runs on a machine you control, inside the isolated network where the old system should already live. Our guide to how the local runner and offline mode work covers the details.

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

This demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. Once connected, you can ask Claude which of your projects still carry a component version you are tracking, for example the OpenSSH or OpenSSL versions that shipped with 6.06, while you decide which legacy systems to retire first. Our post on using an SBOM to find affected products fast shows the same question asked during an incident.

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

To try it yourself, download Safeguard from safeguard.sh/download and follow the CLI docs.

For every Ubuntu version with its kernel and support dates, see the Ubuntu release history hub. For a release that is still in extended coverage, see Ubuntu 16.04 LTS Xenial Xerus, and for how Ubuntu relates to Debian and Kali, our Ubuntu vs Kali vs Debian comparison.

Quick check

Sources

• Ubuntu release notes: Ubuntu 6.06 LTS
• Ubuntu release notes index
• Ubuntu release notes: older releases
• Ubuntu release notes: 5.10 page (returns 404, checked 23 October 2026)
• ubuntu-announce: Announcing Ubuntu 6.06 LTS, 1 June 2006
• ubuntu-announce: June 2006 index (Xubuntu 6.06 and SPARC server announcements)
• ubuntu-announce: Ubuntu 6.06 LTS Desktop Edition reaches end of life on July 14, 2009
• ubuntu-announce: Ubuntu 6.06 (Dapper Drake) reaches end of life on June 1 2011
• ubuntu-announce: Ubuntu 6.06 LTS (Dapper Drake) End of Life
• ubuntu-devel-announce: Proposal for additional QA and localisation time on Dapper, 10 March 2006
• ubuntu-devel-announce: March 2006 index
• Canonical press release: Ubuntu 6.06 LTS released (original www.ubuntu.com/news/606released, Wayback Machine snapshot of 13 June 2006)
• Ubuntu wiki: DapperReleaseSchedule (original wiki.ubuntu.com/DapperReleaseSchedule, Wayback Machine snapshot of 15 March 2006)
• Ubuntu wiki: Releases (original wiki.ubuntu.com/Releases, Wayback Machine snapshot of 4 June 2011)
• Ubuntu wiki: LTS (original wiki.ubuntu.com/LTS, Wayback Machine snapshot of 25 February 2011)
• Ubuntu wiki: RootSudo (original wiki.ubuntu.com/RootSudo, Wayback Machine snapshot of 27 November 2006)
• Ubuntu wiki: SecurityTeam/Policies (original wiki.ubuntu.com/SecurityTeam/Policies, Wayback Machine snapshot of 19 July 2011)
• Ubuntu wiki: BreezyReleaseNotes (original wiki.ubuntu.com/BreezyReleaseNotes, Wayback Machine snapshot of 10 November 2006)
• Ubuntu wiki: Releases (current page)
• Old Ubuntu releases index
• Ubuntu 6.06.2 LTS (Dapper Drake) images
• Old Ubuntu package archive: dists
• Ubuntu: Release cycle
• Ubuntu: Kernel lifecycle and enablement stack
• Ubuntu: Expanded Security Maintenance
• Ubuntu Security Notices
• Ubuntu security notice USN-612-1: OpenSSL vulnerability
• Ubuntu CVE tracker: CVE-2008-0166
• Ubuntu Server documentation: How to upgrade your Ubuntu release
• Ubuntu Desktop documentation: Switch between an LTS and interim release

Last reviewed: 23 October 2026.