文章目录
前言：第1步：开机进入recovery模式第2步：查看系统最近一次的启动日志总结
前言：
环境：组装台式机Ubuntu20.04 TLS 64位系统 问题描述： 重启了下系统，重启后就停在开机主板的界面，提示： 按Ctrl + c可以取消正在进行的所有文件系统检查
一开始的时候还以为只是进行文件系统检查，结果检查了1天，又重启了好几次都是停在这个界面，这才意识到系统出问题了
结果这一搞半个春节加 一个周末都搭进去了。不过当问题解决的时候是真的痛快
现总结下问题解决的过程
第1步：开机进入recovery模式
选择Advanced options for Ubuntu 选择recovery mode 你的系统可能下载有多个内核，随便选一个都可以
然后进入如下界面 选择root Drop to root shell prompt选项 然后回车，系统会提示你输入root用户的密码 输入即可进入root用户的recovery模式 上面的紫红色的界面是shell模拟出来的， 多敲几下回车就又回到Linux的命令行界面了
当然如果你连root用户的密码都忘了的话就再百度吧
第2步：查看系统最近一次的启动日志
想知道系统为什么进不去必须知道它报了什么错对吧， 查看系统最后一次启动日志的命令是：
journalctl -b -1
-b：意思为只查看系统的启动（boot)日志 -1：意思为只查看最近一次的启动日志，同事如果想查看上上一次的启动日志的话就是 -2
此时Linux的启动日志就一页一页显示出来了， 可以按空格翻页，按上下键一行一行上下移动 也可以按左右键查看及返回超出隐藏的部分 日志会很长，其中包含内核日志，系统服务日志，大致如下：
-- Logs begin at Sun 2021-01-31 13:39:47 CST, end at Sun 2021-02-28 00:38:46 CST. --
Feb 27 23:40:14 i75930 kernel: microcode: microcode updated early to revision 0x44, date = 2020-05-27
Feb 27 23:40:14 i75930 kernel: Linux version 5.8.0-44-generic (buildd@lgw01-amd64-054) (gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #50~20.04.1-Ubuntu SMP Wed Feb 10 21:07:30 UTC 2021 (Ubuntu 5.8.0-44.50~20.04.1-generic 5.8.18)
Feb 27 23:40:14 i75930 kernel: Command line: BOOT_IMAGE=/vmlinuz-5.8.0-44-generic root=UUID=8790487f-9c59-4df1-9994-1977413b1b41 ro quiet splash vt.handoff=7
Feb 27 23:40:14 i75930 kernel: KERNEL supported cpus:
Feb 27 23:40:14 i75930 kernel: Intel GenuineIntel
Feb 27 23:40:14 i75930 kernel: AMD AuthenticAMD
Feb 27 23:40:14 i75930 kernel: Hygon HygonGenuine
Feb 27 23:40:14 i75930 kernel: Centaur CentaurHauls
Feb 27 23:40:14 i75930 kernel: zhaoxin Shanghai
Feb 27 23:40:14 i75930 kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
Feb 27 23:40:14 i75930 kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
Feb 27 23:40:14 i75930 kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
Feb 27 23:40:14 i75930 kernel: x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256
Feb 27 23:40:14 i75930 kernel: x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format.
Feb 27 23:40:14 i75930 kernel: BIOS-provided physical RAM map:
Feb 27 23:40:14 i75930 kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable
Feb 27 23:40:14 i75930 kernel: BIOS-e820: [mem 0x0000000000100000-0x00000000b4b3ffff] usable
Feb 27 23:40:14 i75930 kernel: ACPI: DMAR 0x00000000B63C0100 0000C4 (v01 ALASKA A M I 00000001 INTL 20091013)
Feb 27 23:40:14 i75930 kernel: ACPI: ASF! 0x00000000B63C01C8 0000A0 (v32 INTEL HCG 00000001 TFSM 000F4240)
Feb 27 23:40:14 i75930 kernel: ACPI: Local APIC address 0xfee00000
Feb 27 23:40:14 i75930 kernel: SRAT: PXM 0 -> APIC 0x00 -> Node 0
Feb 27 23:40:14 i75930 kernel: SRAT: PXM 0 -> APIC 0x02 -> Node 0
。。。
。。。
。。。
Feb 27 23:40:14 i75930 systemd[1]: Listening on Journal Socket (/dev/log).
Feb 27 23:40:14 i75930 systemd[1]: Listening on Journal Socket.
Feb 27 23:40:14 i75930 systemd[1]: Listening on udev Control Socket.
Feb 27 23:40:14 i75930 systemd[1]: Listening on udev Kernel Socket.
Feb 27 23:40:14 i75930 systemd[1]: Mounting Huge Pages File System...
Feb 27 23:40:14 i75930 systemd[1]: Mounting POSIX Message Queue File System...
Feb 27 23:40:14 i75930 systemd[1]: Mounting Kernel Debug File System...
Feb 27 23:40:14 i75930 systemd[1]: Mounting Kernel Trace File System...
其中以kernel开头的都是系统的内核芯片及硬件接口的日志， 这部分的报错不用管，一般来说你的误操作只会影响到系统级别， 要是内核出错大概率是因为你电脑摔了，进水了，把主板芯片损坏了，
以systemd开头的都是系统服务日志，这部分的报错才是需要关注的地方 找到systemd的第1个报错的地方，基本上就是出问题的地方，下面所有的报错都是它引起的 经过好多次翻页后发现有如下的系统服务报错了：
Feb 27 23:40:18 i75930 systemd[1]: Created slice User Slice of UID 125.
Feb 27 23:40:18 i75930 systemd[1]: Starting User Runtime Directory /run/user/125...
Feb 27 23:40:18 i75930 systemd-logind[1252]: New session c1 of user gdm.
Feb 27 23:40:18 i75930 systemd[1]: Finished User Runtime Directory /run/user/125.
Feb 27 23:40:18 i75930 systemd[1]: Starting User Manager for UID 125...
Feb 27 23:40:18 i75930 systemd[1488]: pam_limits(systemd-user:session): cannot read settings from /etc/security/limits.d/clickhouse.conf: No such file or directory
Feb 27 23:40:18 i75930 systemd[1488]: pam_limits(systemd-user:session): error parsing the configuration file: 'pam_limits(systemd-user:session):'
Feb 27 23:40:18 i75930 systemd[1488]: PAM failed: Error in service module
Feb 27 23:40:18 i75930 systemd[1488]: pam_unix(systemd-user:session): session opened for user gdm by (uid=0)
Feb 27 23:40:18 i75930 systemd[1488]: user@125.service: Failed to set up PAM session: Operation not permitted
Feb 27 23:40:18 i75930 systemd[1488]: user@125.service: Failed at step PAM spawning /lib/systemd/systemd: Operation not permitted
Feb 27 23:40:18 i75930 systemd[1]: user@125.service: Main process exited, code=exited, status=224/PAM
Feb 27 23:40:18 i75930 systemd[1]: user@125.service: Failed with result 'exit-code'.
Feb 27 23:40:18 i75930 systemd[1]: Failed to start User Manager for UID 125.
查阅系统信息及相关资料可以知道这部分日志的意思为： 125是一个用户的UID，你可以在/etc/password文件里找到它， Linux系统在这里初始化它，并登陆
登陆之前需要先把它纳入用户管理， 如能开多少个session即可以开多少个终端连接，密码强度，是否过期，是否图形界面登陆等等 以及准备让你输入密码登陆图形用户界面
用户认证是由pam进行管理的，看日志我们发现正是pam报的错，而系统也一直卡在用户登陆界面之前
于是可以知道最关键的报错信息为/etc/security/limits.d/clickhouse.conf这个文件没有找到
Feb 27 23:40:18 i75930 systemd[1488]: pam_limits(systemd-user:session): cannot read settings from /etc/security/limits.d/clickhouse.conf: No such file or directory
按q键退出，看一个这个文件的内容： 发现这是一个软链接，进入源目录却发现这个文件根本不存在
i75930# cd /etc/security/limits.d/
i75930# ll
lrwxrwxrwx root root 55 Feb 16 10:55 clickhouse.conf -> /opt/workspace/github/myconf/clickhouse/clickhouse.conf
i75930# cat clickhouse.conf
cat: clickhouse.conf: No such file or directory
i75930# cd /opt/workspace/github/myconf
total 48
drwxr-xr-x 3 wedo wedo 4.0K Feb 21 21:09 emacs
drwxr-xr-x 2 wedo wedo 4.0K Feb 21 21:09 for_test
drwxr-xr-x 6 wedo wedo 4.0K Feb 21 21:09 IntelliJ
drwxr-xr-x 3 wedo wedo 4.0K Feb 28 18:54 linux
drwxr-xr-x 4 wedo wedo 4.0K Feb 21 21:09 maven
drwxr-xr-x 6 wedo wedo 4.0K Feb 21 21:09 Notepad++
-rw-r--r-- 1 wedo wedo 401 Feb 21 21:09 README.org
drwxr-xr-x 3 wedo wedo 4.0K Feb 21 21:09 shell
drwxr-xr-x 2 wedo wedo 4.0K Feb 21 21:09 spacemacs
drwxr-xr-x 4 wedo wedo 4.0K Feb 21 21:09 VanDyke
drwxr-xr-x 5 wedo wedo 4.0K Feb 21 21:09 vim
drwxr-xr-x 3 wedo wedo 4.0K Feb 21 21:09 yong
drwxr-xr-x 2 wedo wedo 4.0K Feb 21 21:09 zsh
既然不存在那就把这个错误的软链接删了试试 然后问题解决
总结
这个问题搞了装修春节加一个周末，本来以为这篇文章会写很长，但是没有想到这这么就结束了。真的是会的不难，难的不会啊