Ubuntu 13.10→14.04 Is Historical: EOL Migration, Upgrade, and Recovery Guide

The 2014 source described upgrading Ubuntu 13.10 (Saucy) to the then-development version of 14.04 (Trusty). That route had a specific historical context. Both releases are now in Ubuntu's old-release archive, so the source's update-manager –d, its chained update/upgrade/autoremove command, and its claim about an offline CD/DVD in-place upgrade must not be treated as current instructions.

This guide is for someone authorized to maintain the device. Its goal is to preserve data and recovery options before choosing a supported sequential upgrade, a clean installation, or an EOL multi-hop investigation performed only on a copy. Ubuntu release status changes; check the official lifecycle table and the target's official release notes before starting.

Hard stop: Do not upgrade, repartition, or reinstall without a backup whose restore was tested on another medium or location, the disk-encryption recovery material, and positive identification of the installer's target disk. A snapshot is not an independent backup, and being able to list files is not a restore test.

Table of Contents

1. Identify the system, support status, and failure boundary

Collect read-only evidence before changing repositories or removing packages:

cat /etc/os-release
uname -r
findmnt -no SOURCE,FSTYPE,OPTIONS /
lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINTS
df -h /
apt-mark showhold
systemctl --failed --no-pager

Before sharing output, remove host names, user names, customer names embedded in mount paths, and other internal identifiers. Then classify the installation using official pages:

Current state	Route you can rely on	Default decision
The release is in standard support and the upgrader offers the next hop	LTS to the next LTS, or interim to the next interim; sequential paths only	Read the target release notes, then use the official upgrader
Standard support ended, but the organization has a valid extended-maintenance entitlement	Coverage depends on release, package, and entitlement	Have the administrator confirm actual coverage on the account and machine before deciding
The release is EOL and normal repositories or the upgrader no longer offer a path	`old-releases.ubuntu.com` is only a frozen archive	Prefer backup plus clean install; assess multi-hop only on a disposable copy
The system does not boot reliably, reports disk errors, or has broken package state	Recover data and bootability first	Do not use a release upgrade as a repair method

The Ubuntu old-release archive lists 13.10 and 14.04. The ability to download an old image or package does not mean it still receives security maintenance, nor does it establish a supported direct upgrade to a current release. Standard support, extended maintenance, and EOL are different states, and an Ubuntu flavor can have a different lifecycle.

2. Establish a verified backup and rollback gate

Build a recovery inventory before any write operation:

Desktop data: home directories, project files, browser or mail data, application settings, and keys stored only on the machine. Never put recovery keys or private keys in public logs.
Server data: services and packages, selected configuration from /etc, certificate sources, scheduled jobs, container volumes, and vendor-supported application-consistent database backups. Copying a live database directory is generally not a verified backup.
Storage and boot: partition layout, UEFI or legacy mode, RAID/LVM state, disk health, cloud console access, and snapshot capability. Resolve a degraded array, I/O errors, or inadequate capacity first.
Encryption: confirm that a LUKS passphrase or recovery material works and is stored off the machine. TPM-bound encryption may request a recovery key after firmware, Secure Boot, or boot-chain changes. See Ubuntu's full-disk encryption documentation; do not bypass an unlock failure by disabling security features.
Restore exercise: restore representative files on another machine, disk, or isolated environment; actually open the database or start the service. Record backup date, scope, verification result, and custody location.

The rollback plan also needs verified official media for the target, a network-recovery path, and a working local or cloud console. A remote server with only the current SSH session and no out-of-band console is not ready for an upgrade that can change networking or the boot stack.

3. Choose a route instead of running the old commands

Route A: a supported sequential in-place upgrade

Current Ubuntu documentation supports sequential upgrades only: one LTS to the next LTS, or one interim release to the next interim release. A new LTS upgrade is generally offered after its first point release. Arbitrary releases cannot be skipped.

Only after the lifecycle, target release notes, and upgrader all confirm the path, and the restore test has passed, run these one at a time:

sudo apt update
sudo apt upgrade
sudo do-release-upgrade

Continue only when each step succeeds. If requested, reboot and confirm the new kernel works before starting the release upgrade. do-release-upgrade presents a summary of packages to install, remove, and leave unsupported; save and review it before accepting. Do not add -d or --devel-release: those select a development release and do not repair a missing upgrade path.

On a desktop, follow the Ubuntu Desktop upgrade guide and use Software Updater. On servers and cloud images, follow the Ubuntu Server upgrade guide and use interactive do-release-upgrade. Schedule a maintenance window, inspect service dependencies, and retain console access. Do not answer configuration-file conflicts unattended; compare the local and maintainer versions case by case.

Route B: back up an EOL system and clean-install (usually more controllable)

When several EOL releases separate the system from support, a clean install is usually shorter and easier to validate than serial upgrades on the only system:

Select a still-supported release and matching hardware architecture from the lifecycle table. Do not assume that the “latest” release necessarily supports a driver, application, or CPU.
Download the image from an official Ubuntu release site and follow the image-verification tutorial to verify the signature and SHA-256 checksum.
Follow the official bootable-USB guide. Writing media destroys the USB stick's existing data, so identify that medium first; this article deliberately gives no dd command with a guessed device name.
For a desktop, use the live environment to test storage, networking, display, input, suspend, and encrypted-volume access. For a server, validate installation and networking on identical spare hardware, a clone, or the provider console.
Prefer a new disk or a rollback-capable clone. At the installer's erase-disk, partitioning, encryption, and bootloader confirmation screens, stop again and compare model, capacity, partition table, and the backup-restore record.
Rebuild applications and migrate data. Do not overlay an old /etc, driver set, or entire old home directory onto the new system. Restore databases, containers, and services through their supported export/import processes.

Retain the old disk or read-only image until application checks, reboot checks, and a restore test of a new backup pass on the replacement system. Downgrading in place is unsupported; if the old release is needed again, roll back from a verified image or backup.

Route C: EOL multi-hop migration (a controlled exception only)

If compliance or a legacy application requires preserving the environment, first clone the disk into an isolated VM or spare medium. Design each hop from Ubuntu's EOL upgrade page and the release notes for that hop. Use the old-release site only to retrieve that generation's historical packages. Do not change a suite codename to impersonate a skipped upgrade, and do not use third-party PPAs to bridge broken dependencies.

After every hop, require a bootable system, consistent package state, readable data, and passing service tests before taking a new snapshot and considering the next hop. Stop if the official target upgrader is unavailable, package signatures cannot be verified, hardware is no longer supported, or dependency resolution fails. Success in the multi-hop experiment does not guarantee success on production; still plan to migrate to a clean, supported baseline.

4. Diagnose desktop, server, encryption, and boot recovery separately

After a failure, record the last complete message and current boot stage. Do not power off while the package manager is active. Useful evidence includes:

journalctl -b -p warning --no-pager
systemctl --failed --no-pager
dpkg --audit
apt-get -s --fix-broken install

The last line only simulates dependency repair; it does not approve a real change. Do not execute a simulated proposal blindly. Establish the cause, backup, and rollback point first.

Symptom	Evidence to confirm first	Do not immediately do this
Desktop black screen or login loop	Whether TTY/recovery mode works, root-filesystem space, display manager, and current-boot logs	Purge every display driver or delete user configuration
Server network or SSH loss	Out-of-band console, interface names, routes, firewall, and network-configuration differences	Reboot repeatedly or experiment with network writes in the only session
Encrypted volume will not unlock	Passphrase/recovery key, LUKS/TPM type, and firmware or boot-chain changes	Format, rebuild a header, clear the TPM, or disable Secure Boot
GRUB, initramfs, or kernel-stage failure	Exact UEFI/legacy mode and ESP/root mapping, and whether an older kernel boots	Run `grub-install` against a guessed disk or rewrite a partition table
Package configuration interrupted	`dpkg --audit`, upgrade logs, free space, and the specific conflicting package	Loop “fix” commands or remove packages in bulk

A desktop can use an older kernel or recovery mode from GRUB as a diagnostic entry; a live USB can provide read-only inspection and data copy. A server should use a physical, BMC, serial, or cloud console. Boot recovery media in the same mode as the installed system. Before any writable mount, bootloader reinstall, initramfs rebuild, or encryption-metadata action, resolve the exact devices and versions. This guide intentionally provides no generic write command for those operations.

5. Post-change validation and stop conditions

After an upgrade or reinstall, verify system identity, kernel, failed services, and official repository status first:

cat /etc/os-release
uname -r
systemctl --failed --no-pager
sudo apt update
apt list --upgradable

Then check desktop login, display, and suspend, or the server's network, firewall, time synchronization, databases, queues, scheduled jobs, containers, monitoring, and backups. Use read-only health checks and small application tests instead of treating a successful boot as completion. Perform one controlled reboot, create a new backup, and sample-restore it. Do not destroy the old disk or rollback image until the new baseline is stable.

Stop and escalate to an administrator familiar with the deployment or to an Ubuntu support channel if any of these apply:

No backup has passed a restore test, or encryption recovery material is missing.
The disk reports I/O errors, RAID is degraded, the filesystem is abnormal, or capacity is inadequate.
Official documentation does not list the needed hop, or target architecture/hardware support is uncertain.
A remote server has no out-of-band console, or a critical workload lacks a maintenance window or consistent backup.
Package signatures, repository origin, third-party kernel/driver, or local modifications cannot be explained.
The installer target, UEFI/legacy mode, ESP, or encryption layout cannot be identified uniquely.

Official sources

This guide was checked on 2026-09-01. Support and upgrade availability change; at execution time, rely on the official lifecycle, target release notes, and the sequential route actually offered by the upgrader.

Historical source archive (provenance only)

The complete visible body from source_export follows verbatim. Nothing was deleted, rewritten, whitespace-normalized, or redacted for privacy or safety. It contains a 2014 development-release command and operational assumptions that are no longer valid. The entire block is inert plain text: its commands are not executable and it does not replace the maintained guide above.

虽然Ubuntu 14.04 按计划不会近期发布正式版，但那些想要尝试最新软件和系统的人现在可以从Ubuntu 13.10 就地升级到 14.04了。

Ubuntu 14.04 目前计划在2014.4.17发布，但是你不必等那么长的时间来升级尝试。这个简要的教程给你展示了如何就地从Ububtu 13.10 升级到 14.04。

就地升级是你在已存在的Ubuntu上运行update-manager命令来升级到下一版。它允许你保留你大多数的文档，设定和一些程序。

大多数就地升级依赖于一个可靠的网络连接。没有良好稳定的连接,可能无法使用这个方法升级Ubuntu。

如果你无法使用网络升级，你还可以通过CD/DVD盘来就地升级。这个方法允许你不通过网络连接离线升级Ubuntu。

升级到 Ubuntu 14.04

为了升级到Ubuntu 14.04, 你首先要给你要升级的电脑做好准备工作。请运行下面的命令更新所有存在的包和内核。

sudo apt-get update && sudo apt-get dist-upgrade && sudo apt-get autoremove


完成上述更新后，你可能需要重启来在升级前应用新的包和内核。

接着，按下键盘上的Ctrl+Alt+T键来打开Ubuntu上的命令窗口。当窗口打开后，输入下面的命令并按下回车。

update-manager –d


Ubuntu接着应该带着升级选项会打开update-manager。按下Upgrade 开始升级你的机器。