Linux故障排查需分层验证：从GRUB引导（检查模块、设备名、root参数）、只读文件系统（查dmesg/smartctl，再fsck/xfs_repair）、OOM Killer（调oom_score_adj、控内存使用）到磁盘空间假满（用lsof找deleted文件），每层须用对应工具链定位根因。
Linux 系统故障排查不是靠运气，而是靠分层验证：从引导链、内核态、文件系统到用户服务，每层都有对应信号和工具。关键在于别跳步——比如看到 Read-only file system 就直接 fsck，却漏看 dmesg 里早有的磁盘 I/O timeout。
GRUB 卡在 GRUB> 提示符怎么临时进系统
这不是配置没生效，是 GRUB 根本没加载到有效配置，必须手动指定内核和 initramfs 路径才能启动。常见于误删 /boot 下的 vmlinuz 或 initramfs-*.img，或 LVM/RAID 设备名变更后 grub.cfg 仍指向旧路径。
- 先确认文件系统类型：
insmod xfs（XFS）或insmod ext2（ext4/ext3），错用模块会报unknown filesystem -
set root=(hd0,msdos1)中的分区编号要对得上实际——UEFI 系统可能是(hd0,gpt1)，加一块硬盘后原hd0可能变成hd1 - 内核参数里的
root=必须和真实根设备一致：/dev/mapper/centos-root（LVM）、/dev/sda2（普通分区）、UUID=xxx（推荐但需先用ls查出 UUID） - 进系统后立刻执行
grub2-mkconfig -o /boot/grub2/grub.cfg，否则重启又卡住；若为 UEFI，目标路径常是/boot/efi/EFI/centos/grub.cfg
Read-only file system 错误背后的真实原因
这个错误从来不是“权限设错了”，而是内核主动将文件系统只读挂载，通常因为检测到不可修复的元数据损坏或底层硬件故障。强行 mount -o remount,rw 多数会失败，且可能加速数据丢失。
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
- 先跑
dmesg | grep -i "error\|I/O\|ext4\|xfs"—— 如果看到end_request: I/O error或device sda1: unable to read superblock，说明磁盘已出问题 -
smartctl -a /dev/sda看Reallocated_Sector_Ct和UDMA_CRC_Error_Count，>0 就该换盘 - 如果是 ext4，卸载后用
fsck -y /dev/sda1；XFS 必须先umount，再用xfs_repair /dev/sda1（不能加-y，XFS 修复不交互就失败） - 修复后若仍只读，检查
/etc/fstab是否误写成ro，或mount输出中是否含errors=remount-ro
OOM Killer 杀掉进程后该怎么收场
Killed process XXX (java) total-vm:XXXXkB, anon-rss:XXXXkB, file-rss:0kB 这类日志出现，说明内存已彻底耗尽，OOM Killer 是最后手段，不是 bug。重点不是阻止它触发，而是让它别杀错人。
- 查当前内存压力：
free -h看available列（不是free），vmstat 1看si/so（交换入/出）是否持续 >0 - 降低关键进程被杀概率：
echo -1000 > /proc/<pid>/oom_score_adj</pid>（-1000是最低值，0是默认，+1000最易被杀） - 避免治标不治本：调大
vm.swappiness（如设为 10）可减少 swap 使用，但若物理内存真不足，只是延缓 OOM；真正解法是限制容器内存、优化 Java-Xmx、或清理/var/log/journal这类膨胀源 - 注意：
oom_score_adj在进程重启后失效，需写入服务 unit 文件的ExecStartPre=或使用systemd-sysusers配置持久化
df -h 显示 100% 但 du -sh /* 加起来远小于此
这是典型的“已删除但未释放”现象——进程还在占用已 unlink 的大文件（如日志、临时上传），磁盘空间不会返还，直到进程退出或关闭 fd。
- 定位罪魁：
lsof +L1（列出所有链接数为 0 的打开文件），或更准的lsof -n | grep deleted | awk '{print $2,$NF}' | sort -k2nr - 常见场景：
rsyslogd、journalctl、Java 应用的logback持有滚动日志句柄；nginxworker 进程持有已删 access.log - 释放方式：重启对应进程（如
systemctl restart rsyslog），或用kill -USR1触发日志 reopen（需服务支持） - 预防：对
/var/log做 logrotate 配置，或定期执行journalctl --vacuum-size=200M控制 journal 大小
最常被忽略的一点：很多故障表象相似（比如都卡在启动），但根因差着三层——GRUB 配置错、initramfs 缺驱动、磁盘 firmware 故障，各自要用完全不同的工具链验证。别依赖单一命令，dmesg、journalctl -b -1（上一次启动日志）、cat /proc/cmdline 这三个输出，往往比 top 更早告诉你问题在哪。
