记一次 Ubuntu 内核升级故障处理

Posted 2021-09-30 cnsre运维博客

文章链接

情况介绍

负责的项目下有一批 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 设备。

重启后自动附加附加卷

1. （可选）创建 /etc/fstab 文件的备份，以便在编辑时误损坏或删除此文件时使用。

   [ec2-user ~]$ sudo cp /etc/fstab /etc/fstab.orig

2. 使用 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

3. 使用任何文本编辑器（如 /etc/fstab 和 nano）打开 vim 文件。

   [ec2-user ~]$ sudo vim /etc/fstab

4. 将以下条目添加到 /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 挂载选项。

5. 要检查条目是否有效，请在 /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 官方文档来进行操作部署，以免再次遇到类似的事情发生。

文章链接