系统是虚拟机的 ArchLinux 运行于 VirtualBox 上,系统通过 grub2 引导 gpt 分区表的系统,但是启动只有 GRUB 四个字符,卡在那里也没有进入 grub rescue 模式。
按照 Wiki 的教程我已经把分区表设置成如下样子
Model: ATA VBOX HARDDISK (scsi)
Disk /dev/sda: 42.9GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 17.4kB 1075MB 1075MB ext4 Boot bios_grub
2 1075MB 42.9GB 41.9GB ext4 root
正如上面所示,已经设置了 BIOS PARTITION.
系统挂载方式如下
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop0 7:0 0 502.4M 1 loop
sda 8:0 0 40G 0 disk
├─sda1 8:1 0 1G 0 part /boot
└─sda2 8:2 0 39G 0 part /
然后通过如下安装 grub
grub-install --target=i386-pc --recheck /dev/sda
/etc/default/grub 内的内容是默认的,然后通过命令
grub-mkconfig -o /boot/grub/grub.cfg
生成配置。
重启,但是一直停留在只有 GRUB 四个字符的界面。
其中有过一个小错误是,在安装好 grub 到 /dev/sda 之后调用 grub-mkconfig 会出现 unkwon filesystem 错误,然后再运行一次又没有这个错误。
相关信息:
* VirtualBox 6.0.10 r132072 (Qt5.6.2)
* VirtualBox 里没有设置 EFI 模式
* 生成的 grub.cfg 文件 https://paste.ubuntu.com/p/9sStprbRYb/
最近编辑记录 αlpha0x00 (2019-11-24 15:38:31)
离线
找到原因了,BIOS PARTITION 分区不能有文件系统,这样的画需要单独划一个 +1MiB 的无文件系统分区。因为是虚拟机,所以我还是决定换成 MBR/BIOS 模式吧。
离线
那就不是,是grub.cfg没在正确位置
反社会,精神极其不稳定,随时可能炸碎身边所有人
离线
啥叫无文件系统。efi system partition通常都是用fat文件系统啊
ecmascript是世界上最好的语言
离线
啥叫无文件系统。efi system partition通常都是用fat文件系统啊
他不是说是GPT+BIOS啊,那不是UEFI就不关ESP什么事情。就是需要一个bios_grub用来放grub stage1.5。
但是显然楼主的方案是错误的。他分不清这些boot代码流程。但是反正最后现象好了他也就不大关心了。
反社会,精神极其不稳定,随时可能炸碎身边所有人
离线
那就不是,是grub.cfg没在正确位置
为何是 grub.cfg 位置不对呢?
离线
yw662 说:啥叫无文件系统。efi system partition通常都是用fat文件系统啊
他不是说是GPT+BIOS啊,那不是UEFI就不关ESP什么事情。就是需要一个bios_grub用来放grub stage1.5。
但是显然楼主的方案是错误的。他分不清这些boot代码流程。但是反正最后现象好了他也就不大关心了。
谢谢指导,我去看了下相关资料。GRUB2的流程大体这样的
* GRUB2 + MBR/BIOS
GRUB2 boot.img 部分放于 MBR 的前 446 字节(第一个扇区内)这部分主要起到跳转到核心引导部分,之所以要这么设计是由于 MBR 只有 512B 过于小不能实现“功能完整”的引导程序,因而分成了 boot.img 和 core.img 这两部分。后者实现了引导程序的核心完整功能,而这部分在 MBR/BIOS 分区方案中放于第2扇区到第63扇区中,这个扇区由于 BIOS 的历史原因被保留并且第一个分区开始于第64扇区。core.img 被加载执行接着读取 /boot/grub/grub.cfg 文件等引导系统。
* GRUB2 + GPT/BIOS
同样的,boot.img 还是放在第一“扇区”,在 GPT 分区表中采取 LBA 编址方法,也就是 boot.img 放在 LBA 0. 而 GPT 分区表没有 MBR 中预留的 2~63 扇区的空间,因而需要单独划分一个小分区来存储 core.img,同时为了让 grub-install 安装时能识别这个分区,需要给这个分区设置 bios_grub 类型/标志,以便安装 core.img 到此。然后启动流程和上述一致。
但是我查资料看到对于 GPT/BIOS 有这样的一个方案,由于现代分区工具为了使分区读写地址对齐到 4k 通常会选择,即使在 GPT 分区方案中也会预留头部一部分空间不用,让第一个分区开始于 2048 “扇区”(或 1MiB)的位置,那么是不是有某种手动的方法安装 core.img 到这部分间隙中呢?
离线
我这里显然把 bios_grub 分区和普通正常分区混淆使用了,解决方法也就有三种(大概)吧
* MBR/BIOS 方式
* 划分去一个小分区存放 core.img,然后再划分一个 boot 分区存放其他文件
* 上面提到的利用 GPT 分区的那一个间隙?
离线
你之前弄错了 grub-install 竟然没报错。
离线
你之前弄错了 grub-install 竟然没报错。
grub-install 没有错,grub-mkconfig 时报了一个错误。由于grub-install 破坏了 /dev/sda1 的文件系统提示不知道文件系统
最近编辑记录 αlpha0x00 (2019-11-25 13:42:53)
离线
但是我查资料看到对于 GPT/BIOS 有这样的一个方案,由于现代分区工具为了使分区读写地址对齐到 4k 通常会选择,即使在 GPT 分区方案中也会预留头部一部分空间不用,让第一个分区开始于 2048 “扇区”(或 1MiB)的位置,那么是不是有某种手动的方法安装 core.img 到这部分间隙中呢?
这意味着所有分区编辑工具必须正确推断保留的代码空间位置(例如认同分区表头部全部数据位于LBA0~63中,由于看到了第一个可用于分区的LBA是2048,于是64~2047可以被用于boot代码),因为GPT数据结构不指明未使用的头部空间将用于未来新增的分区表项还是用作boot代码。
反社会,精神极其不稳定,随时可能炸碎身边所有人
离线
为何是 grub.cfg 位置不对呢?
如果你能看见命令行,说明normal.mod被正确加载了(否则应该是grub rescue或者grub完全不能工作。),grub很可能正常工作了。既然没有给你呈现boot菜单,那就是没有读取到菜单文件呗
反社会,精神极其不稳定,随时可能炸碎身边所有人
离线
你之前弄错了 grub-install 竟然没报错。
我也觉得有点奇怪,可能grub-install的执行逻辑是先拷贝文件再安装stage1和stage1.5,这样它就不会感知到其实有文件系统正在被破坏。大多数用户态程序应该也不会主动检查这种东西。。。直到文件系统IO发生时才会感知到文件系统的数据结构已经被corrupt了。
这也可以解释grub-mkconfig的行为,由于文件系统被corrupt,grub-mkconfig进行的文件系统IO会返回错误,它就报错了。于是grub.cfg也没有被创建。
最近编辑记录 xtricman (2019-11-25 16:52:09)
反社会,精神极其不稳定,随时可能炸碎身边所有人
离线
我再详细描述下呢
1. grub.cfg 确实被生成了
2. grub启动应该没有进入命令行或rescue模式,也没有读取到 grub.cfg,后者应该是由于文件系统被损坏了
离线
我再详细描述下呢
1. grub.cfg 确实被生成了
2. grub启动应该没有进入命令行或rescue模式,也没有读取到 grub.cfg,后者应该是由于文件系统被损坏了
你给的是结论,不是描述
最近编辑记录 xtricman (2019-11-25 16:48:28)
反社会,精神极其不稳定,随时可能炸碎身边所有人
离线