【OPS.0x03】将 EOL 的 Ubuntu 升级为 LTS 版本
本文最后更新于:2024年10月10日 晚上
欸你怎么死了(指 EOL Release)
0x00. 一切开始之前
最近笔者手上又多了台服务器的使用权,按照惯例每次登入一台新的服务器首先要做的第一件事自然是得先跑跑 neofetch
看看实力,但是发现没法安装软件包:
也没法打 update & upgrade
的组合拳,因为这是非 LTS 的寿命只有短短 9 个月的 Ubuntu 19.04 Disco
版本:
虽然笔者不太理解为什么会有运维在服务器上安装这种短命版本,但是 新软件包都没法安的服务器自然是没法用的 ( 难道真有人在服务器上就用一个自带的 gcc 用到死? ),因此当务之急是先升级到下一个可用版本(通常是最近的一个 LTS 版本),但是当笔者运行 sudo do-release-upgrade
的时候服务器对笔者说 别急 :
因此这篇博客简单记录一下怎么恢复短命 Ubuntu 版本的可用性并正常升级到下一个长命版本(指 long-term support
)
这就是为什么大家都应该在服务器上使用企业级的 Linux 发行版 openSUSE Leap (或是 Slowroll),而不是莫名其妙安一个短命的 Ubuntu 版本:)
0x01. 从 Ubuntu 19.04 升级到 LTS 版本
注:理论上应当不仅适用于 19.04,而应当也适用于其他短命版本
注2:如果你的网络连接似乎没有那么稳定,请在 分离式终端 (例如 tmux )中进行这一系列操作,以避免升级到一半断连了任务中断了导致系统环境直接炸了
恢复 19.04 Disco 可用性
首先备份一下原来的源,虽然说这个源已经没什么用了但是还是希望能在万一失败的情况下 恢复案发原现场 :
1 |
|
然后把软件源里的老源换成 old-releases.ubuntu.com
:
1 |
|
现在可以开始进行传统系统更新了:
1 |
|
之后就可以正常安装软件了,这里笔者先安了一个 sshd,因为非常奇异搞笑的是笔者拿到的服务器上边居然没有安装 sshd,而是使用 ToDesk 进行远程连接(
不知道原运维人员怎么想的,安这种生命周期只有 9 个月的版本也就算了服务器上连基础设施建设都没有),万幸的是笔者还有内网中另一台机器的控制权,因此有 sshd 的话就算万一 ToDesk 没法正常自启动笔者也能正常连接进去(事实证明 ToDesk 在重启之后确实没法直接重新连接 ,虽然在 systemctl 里看这个服务似乎仍是正常运行的)
1
2
$ sudo apt-get install -y openssh-server
$ sudo systemctl enable --now sshd.service
处理软件包间依赖,然后重启系统:
1 |
|
从 19.04 Disco 升级至 19.10 Eoan
笔者本以为可以直接 do-release-upgrade
从 19.04 升级到 20.04 LTS 然后再继续升级:
没有想到的是这个升级工具并不支持:
因此我们需要先升级到下一个 短命 版本 19.10
,首先 手动 将软件源从 19.04
换为 19.10
:
1 |
|
然后更新系统:
1 |
|
可能会有人认为万幸的是我们还有 手动进行自动升级 这一条路可以走,即首先前往 https://changelogs.ubuntu.com/meta-release 找到
19.04
的下一个版本19.10
:下载 19.10 的升级工具,解压,运行:
1
2
3
4
5
6
$ wget http://old-releases.ubuntu.com/ubuntu/dists/eoan-updates/main/dist-upgrader-all/current/eoan.tar.gz
$ mkdir eoan
$ mv eoan.tar.gz eoan/
$ cd ./eoan
$ tar -zxvf eoan.tar.gz
$ sudo ./eoan然后就 segmentation fault 了,因此这个方法至少在笔者手上的服务器上似乎是不太可行的:
从 19.10 升级至 20.04 LTS
万事俱备,现在让我们迈向下一个发行版本:
1 |
|
成功升级至 20.04 LTS 版本:
为什么截图上是用密码登录是因为笔者拿到服务器后第一时间想的先是升级,因此还没有配置密钥登录,
同时也可以看出原运维并没有把 sshd 的密码登录给关闭
从 20.04 升级到 24.04
如果想要继续升级到更新的系统版本,继续一路运行 sudo do-release-upgrade
即可:
0xFF. REFERENCE
感谢 Ask Ubuntu
社区提供的核心解决方案: