共计 4117 个字符，预计需要花费 11 分钟才能阅读完成。
文章链接
状况介绍
负责的我的项目下有一批 ubuntu 18.04 的服务器在 AWS 上，因为平安的问题，须要把内核从 5.3.0 降级到 5.4.0。
首次降级为测试环境测两台都是 ubuntu 18.04 的版本 内核也都为 5.3.0。第一台降级停顿很顺利。软件更新，而后内核进行独自降级。等到须要重启的时候呈现了问题。
解决问题及解决思路
问题 1
无奈挂载磁盘
首先遇到的第一个问题
解决思路：
降级内核导致 boot 空间越来越小，而后导致无奈疏导进入零碎。因为之前遇到过 boot 空间占满的状况。然而那是在 kvm 的 vm 中，能够通过 VNC 进行链接修复。这在 aws 上怎么办？
解决办法：
一开始我抉择了将改服务器的根磁盘勾销挂载。而后挂载到同一可用区的其余服务器上，进行修复。因为磁盘格式的问题，始终挂载不上，为了避免浪费工夫，只能以快照复原的形式将根磁盘进行扩容。
以快照的形式复原了回复，在快照复原的过程中将根磁盘扩容的办法果然将服务器运行起来了。
前面就接着尝试进行内核降级 ….
问题 2
内核降级数据库依赖报错？
具体内容如下：
解决思路：
这个问题，真的是没有思路。解决了很久，都没有解决这个问题。还心愿有思路的能到领导下。
解决办法:
为了疾速解决内核降级的问题，我将 mysql 以及相干的依赖都卸载掉了。
问题 3
降级完重启失败？
这个问题也是最大的问题，最显著的体现就是。降级没有报错，然而降级完须要重启，服务器进行重启的时候无奈进入操作系统。
此时曾经是凌晨 4 点多钟了，曾经很迷糊了。而后就把服务器复原到降级内核前的样子。打算今天启动快照进行复现。
解决思路：
又是挂载失败？怎么又会遇到挂载失败呢？最初发现重启主动挂载磁盘的配置并没有依照官网的批示去做应用 UUID 的配置开启挂载盘符。从而零碎会检测磁盘的过程中会检测到该谬误。无奈失常进如零碎。
解决办法：
如果是物理机，或者是能够通过其余形式进行管制疏导的话还能够修复。然而云主机怎么修复呢？只能去修复磁盘了
在云主机上有两种拜访磁盘卷的办法
办法 1：应用 EC2 控制台
（摘自 AWS 文档）
如果您为 Linux 启用了 EC2 串行控制台，则能够应用它来排查受反对的基于 Nitro 的实例类型问题。串行控制台可帮忙您排查启动问题、网络配置和 SSH 配置问题。串行控制台无需网络连接即可连贯到您的实例。您能够应用 Amazon EC2 控制台或 AWS 命令行界面 (AWS CLI) 拜访串行控制台。
在应用串行控制台之前，请在账户层面授予对串行控制台的拜访权限。而后，创立 AWS Identity and Access Management (IAM) 策略，授予对 IAM 用户的拜访权限。此外，每个应用串行控制台的实例都必须至多蕴含一个基于明码的用户。如果您的实例无法访问，并且尚未配置对串行控制台的拜访权限，请依照办法 2 中的阐明进行操作。无关为 Linux 配置 EC2 串行控制台的信息，请参阅配置对 EC2 串行控制台的拜访权限。
留神：如果在运行 AWS CLI 命令时遇到谬误，请确保您应用的是最新版本的 AWS CLI。
办法 2：挂载到其余实例上
创立一个长期救济实例，而后将您的 Amazon Elastic Block Store (Amazon EBS) 卷从新挂载到该救济实例上。从该救济实例中，您能够将 GRUB 配置为应用以前的内核进行启动。
重要提醒：请勿在实例存储反对的实例上执行此操作。因为此复原办法须要首先进行而后再重启实例，该实例上的任何数据都将失落。无关更多信息，请参阅确定实例的根设施类型。
- 为根卷创立 EBS 快照。无关更多信息，请参阅创立 Amazon EBS 快照。
- 关上 Amazon EC2 控制台。
- 留神： 请确保您位于正确的区域。
- 从导航窗格中抉择 实例，而后抉择受损的实例。
- 抉择 Instance State（实例状态）、Stop Instance（进行实例），而后抉择 Stop（进行）。
- 在 Storage（存储）选项卡的 Block devices（块贮存设施）下，为 /dev/sda1 或 /dev/xvda 抉择 Volume ID（卷 ID）。
- 顺次抉择 操作 、 断开卷 ，而后抉择 是，请拆散。记下可用区。
- 在同一可用区中启动一个救济 EC2 实例。
- 启动救济实例后，从导航窗格中抉择 卷，而后抉择受损实例已拆散的根卷。
- 顺次抉择 操作 、 附加卷。
- 抉择救济实例 ID (id-xxxxx)，而后设置一个未应用的设施。在本示例中为 /dev/sdf。
- 应用 SSH 连贯到救济实例。
- 运行 lsblk 命令以查看可用的磁盘设施：
lsblk
# 输入如下：xvda 202:0 0 20G 0 disk
└─xvda1 202:1 0 20G 0 part /
xvdb 202:16 0 100G 0 disk
xvdf 202:80 0 15G 0 disk
└─xvdf1 202:81 0 15G 0 part # 该磁盘为故障集服务器根磁盘查看磁盘格式
lsblk -f
NAME FSTYPE LABEL UUID MOUNTPOINT
xvda
└─xvda1 ext4 cloudimg-rootfs d32458a7-7f4c-415f-9a66-b579f14fb82d /
xvdb ext4 eb0e325a-471c-4a99-a9be-a3ee296c2405
xvdf
└─xvdf1 ext4 cloudimg-rootfs d32458a7-7f4c-415f-9a66-b579f14fb82d 挂载磁盘
sudo -i
mount /dev/xvdf1 /mnt而后查看挂载目录，发现根磁盘曾经挂载到了 mnt 下
查看配置文件
ubuntu@ip-10-0-20-27:~$ cat /etc/fstab
LABEL=cloudimg-rootfs / ext4 defaults,discard 0 0
/dev/nvme0n1 /data ext4 defaults 0 0查看官网挂载文档如下：
重启后主动挂载附加的卷
(摘自 AWS 官网文档)
要在每次零碎重启时附加附加的 EBS 卷，可在 /etc/fstab 文件中为该设施增加一个条目。
您能够在 /dev/xvdf 中应用设施名称（如 /etc/fstab），但倡议改为应用设施的 128 位通用惟一标识符 (UUID)。设施名称能够更改，但 UUID 会在整个分区的使用寿命期间保留。通过应用 UUID，您能够缩小零碎在硬件重新配置后无奈启动的机会。无关更多信息，请参阅辨认 EBS 设施。
重启后主动附加附加卷
-
（可选）创立
/etc/fstab文件的备份，以便在编辑时误损坏或删除此文件时应用。[ec2-user ~]$ sudo cp /etc/fstab /etc/fstab.orig -
应用 blkid 命令查找设施的 UUID。记下要在重新启动后挂载的设施的 UUID。在下一步中您将须要用到它。
例如，以下命令显示有两个设施挂载到实例上，并显示了两个设施的 UUID。
[ec2-user ~]$ sudo blkid /dev/xvda1: LABEL="/" UUID="ca774df7-756d-4261-a3f1-76038323e572" TYPE="xfs" PARTLABEL="Linux" PARTUUID="02dcd367-e87c-4f2e-9a72-a3cf8f299c10" /dev/xvdf: UUID="aebf131c-6957-451e-8d34-ec978d9581ae" TYPE="xfs"对于 Ubuntu 18.04，请应用 lsblk 命令。
[ec2-user ~]$ sudo lsblk -o +UUID -
应用任何文本编辑器（如
/etc/fstab和 nano）关上 vim 文件。[ec2-user ~]$ sudo vim /etc/fstab -
将以下条目增加到
/etc/fstab以在指定的挂载点挂载设施。这些字段是 blkid（或用于 Ubuntu 18.04 的 lsblk）返回的 UUID 值、挂载点、文件系统以及倡议的文件系统挂载选项。无关必填字段的更多信息，请运行man fstab以关上 fstab 手册。在以下示例中，咱们将 UUID 为
aebf131c-6957-451e-8d34-ec978d9581ae的设施挂载到挂载点/data，而后咱们应用xfs文件系统。咱们还应用defaults和nofail标记。咱们指定0以避免文件系统被转储，并且咱们指定2以批示它是非根设施。UUID=aebf131c-6957-451e-8d34-ec978d9581ae /data xfs defaults,nofail 0 2留神
如果您要在未附加此卷的状况下启动实例（例如，将卷挪动到另一个实例之后），
nofail附加选项容许该实例即便在卷附加过程中呈现谬误时也可启动。Debian 衍生物 (包含早于 16.04 的 Ubuntu 版本) 还必须增加nobootwait挂载选项。 -
要查看条目是否无效，请在
/etc/fstab中运行以下命令以卸载设施，而后挂载所有文件系统。如果未产生谬误，则阐明/etc/fstab文件失常，您的文件系统会在重启后主动挂载。[ec2-user ~]$ sudo umount /data [ec2-user ~]$ sudo mount -a如果收到谬误音讯，请解决文件中的谬误。
正告
/etc/fstab文件中的谬误可能显示零碎无奈启动。请勿敞开/etc/fstab文件中有谬误的零碎。如果您无奈确定如何更正
/etc/fstab中的谬误并且您在此过程的第一步中创立了一个备份文件，则能够应用以下命令从您的备份文件还原。[ec2-user ~]$ sudo mv /etc/fstab.orig /etc/fstab
查看批改日期核查批改工夫
问题都解决了。接下来持续降级内核吧。
sudo apt-get install linux-image-5.4.0-1055-aws
期待重启查看
终于胜利了。。。
问题总结
- 问题 1
更新内核导致疏导分区存储占满。 - 优化
在 ubuntu 进行内核补丁软件更新时须要留神 boot、root 分区的容量。以防止重启后无奈失常疏导进入零碎。 - 问题 2
更新下载软件，提醒were encountered while processing - 优化
后测试发现更新下载任何软件都会呈现这种状况，暂未解决。 - 问题 3
磁盘开机主动挂载配置问题。 - 优化
当前须要严格依照 AWS 官网文档来进行操作部署，免得再次遇到相似的事件产生。
文章链接