内核启动时间较长(40 秒以上)(可能是交换挂载问题?)

内核启动时间较长(40 秒以上)(可能是交换挂载问题?)

我弄乱了交换分区,现在我觉得启动时挂载超时了,但我找不到原因。我所做的是切换到交换文件,但我决定将交换分区移回单独的分区。我已恢复了分区交换的 /etc/fstab 条目,并使用了新交换分区的 UUID,并且它正确挂载了,但内核启动时间仍然超过 40 秒,在我弄乱交换分区之前没有这种情况。挂载超时 30 秒似乎是正确的,但我不知道它来自哪里。

$ sudo systemd-analyze 
Startup finished in 12.396s (firmware) + 3.520s (loader) + 41.762s (kernel) + 4.206s (userspace) = 1min 1.885s 
graphical.target reached after 4.199s in userspace

$ dmesg
[   10.013926] amdgpu 0000:09:00.0: [drm] fb0: amdgpudrmfb frame buffer device
[   41.452204] fbcon: Taking over console

$ swapon -s
Filename                Type        Size        Used        Priority
/dev/nvme0n1p6          partition   4354044     0           -2

当前 /etc/fstab 条目:

UUID=1b29a039-fc6e-4605-ab3b-8c2c7fef5b12 /               ext4    errors=remount-ro 0       1
UUID=900D-3933  /boot/efi       vfat    umask=0077      0       1
UUID=89e04806-5af3-4a54-9039-01880ace0f2e none            swap    sw              0       0

似乎与 blkid 的条目匹配

/dev/nvme0n1p5: UUID="1b29a039-fc6e-4605-ab3b-8c2c7fef5b12" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="de718315-ddc0-49fe-9ceb-76bc07e17d71"
/dev/nvme0n1p3: LABEL="SYSTEM" BLOCK_SIZE="512" UUID="626E216A6E213865" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="68a15aa7-d352-4a82-ba52-dd1dbf9711fb"
/dev/nvme0n1p1: UUID="900D-3933" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="b1c50a15-3d4a-4869-8213-85a4bdd1dd76"
/dev/nvme0n1p6: LABEL="swap" UUID="89e04806-5af3-4a54-9039-01880ace0f2e" TYPE="swap" PARTLABEL="swap" PARTUUID="dd2bfed7-249a-4b2b-b69b-6bba52e0846c"
/dev/nvme0n1p4: BLOCK_SIZE="512" UUID="1C1C38DD1C38B41C" TYPE="ntfs" PARTUUID="259c58e4-26d7-4ee1-937d-43b116110ea6"

我不知所措。我尝试寻找更多东西,但 dmesg 有这么大的差距,而其他 systemd-analyze 命令没有提供任何有用的信息:

$   systemd-analyze critical-chain 
graphical.target @4.199s
    └─multi-user.target @4.199s
      └─kerneloops.service @4.187s +11ms
        └─network-online.target @4.153s
          └─NetworkManager-wait-online.service @797ms +3.356s
            └─NetworkManager.service @749ms +45ms
              └─dbus.service @747ms
                └─basic.target @738ms
                  └─sockets.target @738ms
                    └─snapd.socket @737ms +743us
                      └─sysinit.target @733ms
                        └─snapd.apparmor.service @561ms +164ms
                          └─apparmor.service @496ms +52ms
                            └─local-fs.target @494ms
                              └─run-snapd-ns-snapd\x2ddesktop\x2dintegration.mnt.mount @2.224s
                                └─run-snapd-ns.mount @1.955s
                                  └─swap.target @458ms
                                    └─dev-disk-by\x2duuid-89e04806\x2d5af3\x2d4a54\x2d9039\x2d01880ace0f2e.swap @431ms +12ms

$ systemd-analyze blame
3.356s NetworkManager-wait-online.service
2.707s plymouth-quit-wait.service
1.091s snapd.service
 326ms snapd.seeded.service
 280ms dev-loop5.device
 279ms dev-loop6.device
 276ms dev-loop7.device
 253ms dev-loop1.device
 253ms dev-loop2.device
 252ms dev-loop3.device
 251ms dev-loop4.device
 244ms dev-loop0.device
 228ms dev-nvme0n1p5.device
 195ms systemd-resolved.service
 164ms snapd.apparmor.service
 157ms [email protected]
 155ms cups.service
 150ms systemd-oomd.service
 147ms plymouth-start.service
 146ms systemd-timesyncd.service
 144ms networkd-dispatcher.service

答案1

对于有同样问题的人,请尝试以下操作:

由于某种原因运行

sudo update-initramfs -u -k all

解决了问题:

[   10.056435] amdgpu 0000:09:00.0: [drm] fb0: amdgpudrmfb frame buffer device
[   10.147211] fbcon: Taking over console

$ sudo systemd-analyze time
Startup finished in 11.307s (firmware) + 2.523s (loader) + 10.458s (kernel) + 6.233s (userspace) = 30.523s 
graphical.target reached after 6.224s in userspace

我无法说出原因,但是我看到它提到了新交换分区的 UUID(我认为将其设置为系统休眠时恢复的位置?)所以我的猜测是,无论该命令到底做了什么,它都会更新一些指向旧交换分区的旧 UUID 的剩余设置,从而导致 30 秒超时。但是,/var/log 中的所有日志都没有提到 30 秒超时后出现故障,这一事实实在是……令人震惊。同时,系统日志中充斥着来自 gnome 地理位置恶意软件的垃圾消息,但如果记录了从分区读取失败的情况,那就另当别论了。哦不,先生。。确实,Ubuntu 已经进入了现代桌面操作系统的时代,重要的东西没有记录,而记录的东西也是没用的(看看 Windows 系统日志)。

相关内容