我弄乱了交换分区,现在我觉得启动时挂载超时了,但我找不到原因。我所做的是切换到交换文件,但我决定将交换分区移回单独的分区。我已恢复了分区交换的 /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 系统日志)。