![将系统克隆到更大的磁盘后启动非常慢](https://linux22.com/image/1170710/%E5%B0%86%E7%B3%BB%E7%BB%9F%E5%85%8B%E9%9A%86%E5%88%B0%E6%9B%B4%E5%A4%A7%E7%9A%84%E7%A3%81%E7%9B%98%E5%90%8E%E5%90%AF%E5%8A%A8%E9%9D%9E%E5%B8%B8%E6%85%A2.png)
我在 Intel Classmate PC 笔记本电脑的 SD 卡上安装了 Lubuntu 18.04 LTS i386。
我最近使用 Win32DiskImager 将 16GB 卡克隆为 64GB 卡,并使用 GParted LiveUSB 调整其大小。
现在启动速度非常慢,我查看了一下并尝试了所有的解决方案,但似乎问题出在 GRUB 的某个地方,但我对 Linux 还不太熟悉,所以我不知道从哪里开始寻找并识别它。
我禁用了启动画面来查看内核启动消息,并发现在 grub 中启动停滞了整整 2 分钟(120 秒),然后才加载内核(屏幕空白,没有光标),这表明发生了某种超时事件,但我不知道从哪里开始寻找其背后的原因。
到目前为止,我尝试过其他类似问题的解决方案:
/etc/fstab
显示磁盘的正确 UUID(匹配blkid
一个)blockdev --getalignoff /dev/sdb1
节目0
swap
是一个文件,而不是分区/etc/crypttab
不存在/etc/initramfs-tools/conf.d
是空的- 我跑了
update-grub
- 我跑了
update-initramfs -uk all
systemd-analyze
不考虑整个启动时间dmesg
没有显示任何有趣的内容,因为启动信息只在 grub limbo 运行 2 分钟后才开始显示
看来停滞点在 grub 的某个地方。我已检查以确保/boot/grub/grub.cfg
显示 UUIDblkid
在所有地方都匹配。/var/boot.log
为空,journalctl -b
从同一点开始dmesg
(2 分钟后)
任何关于我可以从哪里开始寻找以确定问题的想法都将不胜感激!
答案1
好的,我找到了这背后的原因。
我输入set debug=all
了 grub 控制台,它允许我追踪发生的所有事情,并且加载初始 ramdisk 是最慢的。原因如下。
在非 uefi 模式下,GRUB 需要使用 BIOS 命令从磁盘加载 initrd 内核映像,并切换至保护模式以读取每个块。这加上 SDXC 卡延迟在读取内核映像时会产生很大的延迟。内核映像的大小超过 60MB,GRUB 默认配置为在 BIOS 模式下以较小的块加载它,以避免内存不足。以下是与此相关的 GRUB 错误:https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/944347
较小的卡只是稍微快一点,虽然不是很多,但 GRUB 延迟加载方案将差异放大了很多。