云服务器启动失败故障提示：
[5.877137] async_tx: api initialized (async)
[6.013920] Btrfs loaded, crc32c=crc32c-intel, zoned=yes, fsverity=yes一直卡在这里，启动不了。
1：进入【Linux 救援系统】
2：挂载原系统盘并检查日志
# 1. 查看磁盘分区（确认你的系统盘，通常是 /dev/vda1 或 /dev/vdb1）
lsblk
# 2. 创建挂载点并挂载根分区（假设是 /dev/vda1）
mkdir -p /mnt/root
mount /dev/vda1 /mnt/root
# 3. 查看系统日志最后几十行，找出卡住前的具体报错
tail -100 /mnt/root/var/log/messages
# 或者查看 dmesg 日志
tail -100 /mnt/root/var/log/dmesg关键：日志中如果出现 I/O error、EXT4-fs error、XFS: metadata I/O error 等，说明文件系统损坏。如果出现 Failed to start ... service 或 Timeout，则是某个服务启动失败。
3：根据系统日志判断问题
# 最后10行日志
Jun 17 12:08:30 Rescue-AiyiWL8721418951 dracut[1299]: *** Creating image file '/boot/initramfs-4.18.0-358.el8.x86_64kdump.img' ***
Jun 17 12:08:30 Rescue-AiyiWL8721418951 dracut[1299]: *** Creating initramfs image file '/boot/initramfs-4.18.0-358.el8.x86_64kdump.img' done ***
Jun 17 12:08:32 Rescue-AiyiWL8721418951 kdumpctl[1014]: kdump: kexec: loaded kdump kernel
Jun 17 12:08:32 Rescue-AiyiWL8721418951 kdumpctl[1014]: kdump: Starting kdump: [OK]
Jun 17 12:08:32 Rescue-AiyiWL8721418951 systemd[1]: Started Crash recovery kernel arming.
Jun 17 12:08:32 Rescue-AiyiWL8721418951 systemd[1]: Startup finished in 2.958s (kernel) + 11.477s (initrd) + 1min 74ms (userspace) = 1min 14.510s.
Jun 17 12:08:40 Rescue-AiyiWL8721418951 systemd[1]: systemd-hostnamed.service: Succeeded.
Jun 17 12:08:54 Rescue-AiyiWL8721418951 chronyd[803]: Selected source 94.237.79.110 (2.centos.pool.ntp.org)
Jun 17 12:09:01 Rescue-AiyiWL8721418951 kernel: EXT4-fs (vdb1): warning: mounting fs with errors, running e2fsck is recommended
Jun 17 12:09:01 Rescue-AiyiWL8721418951 kernel: EXT4-fs (vdb1): mounted filesystem with ordered data mode. Opts: (null)日志最后两行是关键：
vdb1 是一个数据盘（或系统盘），它是 EXT4 文件系统。
系统在救援模式下强行挂载了这个有错误的分区，这通常是为了让你能进去抢救数据，但带着错误启动，正是原系统卡住进不去的原因。
4：修复方案
你现在就在救援系统里，正好可以修复。执行以下命令：
第一步：卸载问题分区
umount /dev/vdb1如果提示 target is busy（分区忙），先执行 fuser -km /dev/vdb1 强制踢出进程，再执行卸载。
第二步：执行文件系统修复
e2fsck -y /dev/vdb1-y 参数会自动回答“是”来修复所有问题，不用一直按确认。
这个过程可能需要几分钟到十几分钟，耐心等待它跑完。如果有大量错误修复输出，是正常的。
第三步：检查主系统盘（vda1）
虽然日志报错的是 vdb1，但你的系统盘通常是 vda1（从之前的启动日志 vda: vda1 vda14 vda15 可以看出）。为了防止主系统也有潜在问题，建议也检查一下：
umount /dev/vda1 # 如果已挂载就先卸载
e2fsck -y /dev/vda1第四步：重新挂载测试
修复完成后，可以重新挂载看看是否正常：
mount /dev/vdb1 /mnt # 假设挂载点存在
ls /mnt # 如果能正常列出目录，说明修复成功5：完成后重启
1：在魔方云控制面板，点击 “退出救援系统”（或“重启至正常系统”）。
2：实例会自动重启，这次应该能正常进入系统了。
如果修复后还是进不去
说明除了文件系统错误，可能还有其他问题：
- 可能是根分区（vda1）也有类似报错， 但日志里没显示。请务必也对 vda1 执行 e2fsck -y /dev/vda1。
- 可能是启动配置文件损坏。 修复后，可以在救援模式下挂载根分区，检查 /mnt/etc/fstab 文件，看是否有错误的分区挂载条目。
- 如果 e2fsck 提示“无法修复”或出现大量“坏块”， 说明磁盘可能物理损坏，那就只能备份数据后重装系统了。
补充建议
- 修复完成后，进入原系统后第一时间备份重要数据，因为文件系统报错往往是磁盘寿命下降的早期信号。
- 如果你不熟悉命令行操作，魔方云通常也有工单支持，可以把这段日志发给客服，他们会协助你进行修复。
你先按 e2fsck 步骤操作，把修复过程的输出结果发给我，如果有新的报错我再帮你分析。
评论 (0)