数据库管理-第三十七期 我搞挂了一台一体机（20220925）_printreqerror统信

第三十七期 我搞挂了一台一体机

本周，客户这边IPv6改造，失败了一次，成功了一次，中间因为要彻底断网，因此把数据库全给关了，一周两次加班，还是挺累的。
众所周知，我这有一台X9M-2还在测试，本周成功把其中一个计算节点搞挂了，这一期就讲讲这件事情。
技术向，知道写了些啥。

1 背景

一体机测试嘛，基础功能没啥问题，但是遇上了国庆+20大，正式投产应该要放到11月了。除了数据库功能测试以外，对各个组件还要进行断电、重启测试，这次的问题就是出现在对一个计算节点重启时出现的。

2 GRUB rescue

这个计算节点重启以后，一直连接不上，通过ilom页面使用我Remote Control发现这个计算节点进入了GRUB rescue状态。虽然，多多少少会些Linux（毕竟当年还是讲过主机课程的，基本覆盖了RHCE内容和部分RHCA），但是遇到GRUB出现问题，还是第一次，因此还是开了个SR。

3 问题排查

3.1 硬件

首先收集并提交了ilom snapshot来检查硬件和基础问题，通过后台排查，硬件没有问题，操作系统在启动过程中出现了以下问题：

print_req_error: I/O error, dev dm-16, sector 0^M
1

定位为Linux问题，因此SR又转交给Oracle Linux Team.

3.2 操作系统

Oracle Linux Team经过检查首先确定了当前系统启动过程是进入了grub rescue模式，没有进入rescue mode，因此判断是grub损坏了。通过在grub rescue检查，计算节点是两块Intel 3.84TB NVMe SSD做了RAID，因此在grub rescue里面无法判断系统使用磁盘盘符，因此在grub rescue内修复grub的方案被pass掉了。

4 修复过程

4.1 diag.iso

既然grub rescue不能进行操作，那么就需要进入rescue mode来修复grub。在一体机环境进入rescue mode是需要通过对应image版本的diag.iso来将系统引导到rescue mode的。对应文档为DOC ID 888828.1。ISO挂载文档How to recover from a failed Linux Exadata DB Server dbnodeupdate or rollback (Doc ID 1952372.1)。

4.2 进入rescue mode

下载完成后需要通过ilom remote control挂载对应镜像，并根据文档How to boot Exadata database server with diagnostic ISO image ( Doc ID 1947114.1 ) 进行相关操作。

ssh root@exadb01-ilom
password:
#进入ilom后台

-> set /HOST boot_device=cdrom
#配置下次通过iso启动
-> reset /SYS
#重启操作系统

-> start /SP/console
Are you sure you want to start /SP/console (y/n)? y
#进入console

EXT3-fs: mounted filesystem with ordered data mode.
[date/time]  The current installation has version [Exadata image version]
[date/time]  Choose from the following by typing letter in '()':
[date/time]    (e)nter interactive diagnostics shell.
[date/time]      Use diagnostics shell password to login as root user
[date/time]      (reboot or power cycle to exit the shell),
[date/time]    (r)estore system from NFS backup archive,
Select: **e**
#进入rescue mode

localhost login: root
Password: *********
#登录recsue mode
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

4.3 修复文件系统

根据lvs的内容，使用xfs_repaire对各主要系统挂载点进行修复：

xfs_repaire /dev/mapper/VGExaDb-LVDbSys1
xfs_repaire /dev/mapper/VGExaDb-LVDbTmp
xfs_repaire /dev/mapper/VGExaDb-LVDbVar1
xfs_repaire /dev/mapper/VGExaDb-LVDbVarLog
xfs_repaire /dev/mapper/VGExaDb-LVDbVarLogAudit
xfs_repaire /dev/mapper/VGExaDb-LVDbOra1
xfs_repaire /dev/mapper/VGExaDb-LVDbHome
1
2
3
4
5
6
7

修复过程未出现异常，因此本次故障文件系统并未损坏。

4.2.1 挂载系统

在rescue mode中进行grub修复需要先将指定文件系统按组织结构挂载起来，操作如下：

mkdir /mnt/sysimage
mount /dev/mapper/VGExaDb-LVDbSys1 /mnt/sysimage
#挂载根目录
mount /dev/mapper/VGExaDb-LVDbVar1  /mnt/sysimage/var
#挂载var

mount /proc /mnt/sysimage/proc/ -o bind
mount /dev /mnt/sysimage/dev/ -o bind
mount /sys /mnt/sysimage/sys/ -o bind
#挂载proc、dev、sys

mount /dev/md126p1 /mnt/sysimage/boot
#挂载boot
mount /dev/md126p2 /mnt/sysimage/boot/efi
#挂载efi
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

4.3 修复grub

操作如下：

chroot /mnt/sysimage
grub2-install
1
2

重启后没有再进入grub rescue，但是出现了其他问题：

Invalid signature detected. Check Secure Boot Policy in Setup
1

在rescue mode中通过efibootmgr -v发现efi启动使用错误的启动项导致安全启动验证失败。

4.4 调整启动项

在BIOS/Boot mamager中将启动项调整为正确启动项（使用shim64.efi启动的启动项）。操作系统正常启动。通过多次重启也是正常的。至此修复完毕。

总结

说真的，即使是Linux工程师也很难得遇到grub的问题，更何况我一个DBA。但是大多数根据SR反馈的文档和远程知道，没有开启远程协助就将问题处理，还是让Oracle Linux Team的工程师感到比较惊讶（毕竟没有手把手，而且他们接触的不少DBA对操作系统真心不熟）。
最后MOS也反馈这是一个极低可能出现的问题，作为个技术积累写下这篇文档，当然一般的Linux通过对应版本的iso进入rescue mode操作基本是一致的。
知道写了些啥，但是也希望大家永远也别遇到。