Category: System Setting Other Debugs (系统设置其它排错)

Posted on

[排错] 解决重启系统后无法进入系统，并提示 “/grub2/i386-pc/normoal.mod not found gpt”

报错代码

/grub2/i386-pc/normoal.mod not found gpt

解决方法

步骤一：挂载官方镜像

（步骤略）

步骤二：登录拯救模式

2.1 选择通过光盘启动

（步骤略）

2.2 进入拯救模式

（步骤略）

2.3 登录拯救模式

rescue login:root

步骤三：在救援模式确定系统的根 “/” 目录分区

（步骤略）

（
补充：
1) 物理分区可以使用 lsblk 命令、fdisk -l 或 cat /proc/partitions 命令辅助确定
2) 逻辑分区还可以可以使用 pvs 命令、lvs 命令或 lvdisplay 命令辅助确定
）

步骤四：在救援模式将系统的分区挂载到救援模式的 /mnt 目录

4.1 在救援模式将系统的根 “/” 分区挂载到救援模式的 /mnt 目录

tty1:rescue:~ # mount <root spartition> /mnt

（
补充：
1) 如果是物理分区，系统的根 “/” 分区就在救援模式的 /dev/ 目录里，例如救援模式的 /dev/sda1
2) 如果是逻辑分区，Rocky Linux & RHEL 的系统根 “/” 分区就是救援模式里的 /dev/<volume group>/<logical volume> 例如救援模式里的 /dev/vg/lv，openSUSE & SUSE 的系统根 “/” 分区就是救援模式里的 /dev/mapper/<volume group>-<logical volume> 例如救援模式里的 /dev/mapper/vg-lv
）

4.2 在救援模式将救援模式的 /dev 目录关联到救援模式的 /mnt/dev 目录

tty1:rescue:~ # mount --rbind /dev /mnt/dev

（
补充：
1) 此时所有对救援模式的 /mnt/dev 目录的访问都会变成对救援模式的 /dev 目录的访问
2) 步骤 4.2、步骤 4.3 和步骤 4.4 也可以用以下命令代替：

tty1:rescue:~ # for i in proc sys dev; do mount --rbind /$i /mnt/$i ; done

）

4.3 在救援模式将救援模式的 /proc 目录关联到救援模式的 /mnt/proc 目录

tty1:rescue:~ # mount --rbind /proc /mnt/proc

（
补充：
1) 此时所有对救援模式的 /mnt/proc 目录的访问都会变成对救援模式的 /proc 目录的访问
2) 步骤 4.2、步骤 4.3 和步骤 4.4 也可以用以下命令代替：

tty1:rescue:~ # for i in proc sys dev; do mount --rbind /$i /mnt/$i ; done

）

4.4 在救援模式将救援模式的 /sys 目录关联到救援模式的 /mnt/sys 目录

tty1:rescue:~ # mount --rbind /sys /mnt/sys

（
补充：
1) 此时所有对救援模式的 /mnt/sys 目录的访问都会变成对救援模式的 /sys 目录的访问
2) 步骤 4.2、步骤 4.3 和步骤 4.4 也可以用以下命令代替：

tty1:rescue:~ # for i in proc sys dev; do mount --rbind /$i /mnt/$i ; done

）

4.5 在救援模式将救援模式的 /run 目录关联到救援模式的 /mnt/run 目录 （选做）

tty1:rescue:~ # mount --rbind /run /mnt/run

（补充：此时所有对救援模式的 /mnt/run 目录的访问都会变成对救援模式的 /run 目录的访问）

步骤五：将当前的根 “/” 目录从救援模式的根 “/” 目录切换到系统的根 “/” 目录

5.1 将当前的根 “/” 目录从救援模式的根 “/” 目录切换到系统的根 “/” 目录

tty1:rescue:~ # chroot /mnt

（补充：这里以 /mnt 作为系统根 “/” 目录为例）

5.2 在系统模式挂载所有需要开机自动挂载的目录

bash-4.3# mount -a

5.3 在系统模式确认当前根 “/” 目录下的目录

bash-4.3# ls
bin boot dev home lib lib64 mnt opt proc root run sbin selinux srv sys tmp usr var

（补充：这里显示的是常见的 Linux 根 “/” 目录 下的目录）

步骤六：在系统模式修复 GRUB2

6.1 在系统模式确定系统的 GRUB2 目录分区

（步骤略）

（
补充：
1) 物理分区可以使用 lsblk 命令、fdisk -l 或 cat /proc/partitions 命令辅助确定
2) 逻辑分区还可以可以使用 pvs 命令、lvs 命令或 lvdisplay 命令辅助确定
）

6.2 在系统模式修复 GRUB2

bash-4.3# grub2-install <disk which GRUB2 in>

6.3 在系统模式修复 /boot/grub2/grub.cfg

bash-4.3# grub2-mkconfig -o /boot/grub2/grub.cfg

步骤七：重启系统

7.1 从当前系统的根 “/” 目录切换回救援模式的根 “/” 目录

bash-4.3# exit

7.2 重启系统

bash-4.3# reboot

补充：boot 分区的文件系统损坏的情况

如果以上步骤都不起作用，且 /boot 是单独分区的话，则可能是 boot 分区的文件系统损坏，可以尝试以下补充：

1) 重复本文步骤五和之前步骤的内容
2) 将 /boot 目录里的内容全部拷贝出来
3) 取消挂载 /boot 目录的分区
4) 将挂载 /boot 目录的分区重新格式化成 ext4 格式
5) 格式化后分区的 UUID 会改变，所以需要更新 /etc/fstab 文件中挂载 /boot 目录分区的 UUID
6) 将格式化后的分区重新挂载 /boot 目录
7) 将刚刚从 /boot 目录拷贝出来的内容拷贝回 /boot 目录
8) 重复此文的步骤六

（注意：不建议使用 Btrfs 文件系统给 /boot 目录分区）

参考文献：

https://www.suse.com/support/kb/doc/?id=000018770

Posted on

[排错] 解决 SSH 远程登录时很慢但 ping 时延迟很低

分析

ssh 远程某台服务器时很慢，但是 ping 时延迟却很低。这可能是 DNS 解析出现问题造成的，禁用服务器上 sshd 的 GSSAPIAuthentication 参数和 UseDNS 参数可以解决，这两个参数的作用是：
1) GSSAPIAuthentication，当服务器的 sshd 服务此参数处于开启状态时，客户端 SSH 登录此服务器时，客户端会对服务器的 IP 地址进行 PTR 反解析，获得服务器的域名，再通过服务器的域名对服务器进行 DNS A 正向 IP 地址解析，通过此方法来防止欺骗。
2) UseDNS，当服务器的 sshd 服务此参数处于开启状态时，客户端 SSH 登录此服务器时，服务器会对客户端的 IP 地址进行反解析，获得客户端的域名，再通过客户端的域名对客户端进行 DNS A 正向 IP 地址解析，通过此方法来防止欺骗。

解决方法

方法一：忽略 DNS

1.1 修改 SSH 的配置文件

# vim /etc/ssh/sshd_conf

将以下内容：

......
UseDNS yes
......
GSSAPIAuthentication yes
......

修改为：

......
UseDNS no
......
GSSAPIAuthentication no
......

1.2 让修改的 SSH 配置文件生效

# systemctl restart sshd

方法二：重启 systemd-logind

2.1 重启 dbus

# systemctl restart dbus

2.2 重启 systemd-logind

# systemctl restart systemd-logind

（注意：如果不重启 dbus 直接重启 systemd-logind 则可能会报错）

Posted on

[排错] 解决 Linux 运行时报错 “watchdog: Bug: soft lockup – CPU……” （CPU 软锁）

报错代码

watchdog: Bug: soft lockup - CPU......

分析

当 CPU 的负载过高时，一个 CPU 在运行某一个进程时，在内核模式下超过 20 秒没有回应，则看门狗程序会将系统所有 CPU 软锁住，然后会让这些 CPU 显示各自正在运行的进程堆栈跟踪

缓解方法

方法一：通过 /proc/sys/kernel/watchdog_thresh 文件延长看门狗软锁 CPU 的时间

# echo 20 > /proc/sys/kernel/watchdog_thresh

（补充：这里以将看门狗的值延长到 20 为例，也可以根据自己的需求延长更多，默认值为 10）

方法二：通过新建文件延长看门狗软所 CPU 的时间

2.1 通过新建文件延长看门狗软所 CPU 的时间

# echo "kernel.watchdog_thresh = 20" >> /etc/sysctl.conf

（补充：这里以将看门狗的值延长到 20 为例，也可以根据自己的需求延长更多，默认值为 10）

2.2 让新建文件立刻生效

# sysctl -p /etc/sysctl.conf

深究方法

开启 Kdump，等此报错再次发生时分析 Kdump 在内核崩溃时搜集信息 vmcore

Linux Kdump 的开启
（用于收集内核崩溃时的信息）
Linux Kdump 内核奔溃信息的分析
Posted on

[排错] 解决 Linux 执行 curl 命令时报错 “curl: (35) error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure”

报错代码

curl: (35) error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure

分析

Rocky Linux 8 & RHEL 8 已经默认废弃 TLSv1.2
可以使用 TLSv1.3 替代 TLSv1.2 或者将 update-crypto-policies 参数设置为 DEFAULT 以解决此报错

解决方法

步骤一：显示当前的 update-crypto-policies 参数

# update-crypto-policies --show
FUTURE

（补充：从这里可以看出目前的 update-crypto-policies 参数是 FUTURE）

步骤二：将 update-crypto-policies 参数设置为 DEFAULT

# update-crypto-policies --set=DEFAULT

（补充：这里以将 update-crypto-policies 参数设置为 DEFAULT 为例）