多系统引导的福音!UEFI 引导环境 NVRAM 编辑工具 BOOTICE

启动讨论 grub/grub2/syslinux/grub4dos/Lilo
回复
zhangjint5
帖子: 238
注册时间: 2011-01-02 12:31
送出感谢: 35 次
接收感谢: 11 次

多系统引导的福音!UEFI 引导环境 NVRAM 编辑工具 BOOTICE

#1

帖子 zhangjint5 » 2017-01-11 8:41

在 UEFI 环境中,多系统的引导变得非常简单。

因为你不用在去管 MBR 了,不管是 GRUB2 还是 BOOTMGR ,谁先引导谁后引导完全没关系!

因为该去引导谁,由 UEFI 和 NVRAM 来负责!



如下图,主板固件直接可以识别多种操作系统。(要求主板设置中 CSM 兼容模式关闭,也就是纯 UEFI 模式)
1.jpg


通过主板 UEFI 固件的引导菜单来选择操作系统。(引导项配置实际是保存在主板的 NVRAM 中

完美解决了以前哪个引导器该先启动的问题
2.jpg


如果你想要手动编辑引导项,efibootmgr 是个不错的选择
3.png


Windows 中则可使用 BOOTICE (先用 mountvol s: /s 挂载 EFI 分区)
4.PNG
这些用户感谢了作者 zhangjint5 于这个帖子:
AutoXBC (2017-01-15 19:46)
评价: 3.7%
头像
qy117121
论坛版主
帖子: 50234
注册时间: 2007-12-14 13:40
系统: Winbuntu
来自: 志虚国乌由市
送出感谢: 18 次
接收感谢: 362 次
联系:

Re: 多系统引导的福音!UEFI 引导环境 NVRAM 编辑工具 BOOTICE

#2

帖子 qy117121 » 2017-01-11 9:55

BOOTICE也支持uefi啊,一直没有uefi的设备没注意过
渠月 · QY    https://vz.rs/u
本人只会灌水,不负责回答问题

无聊可以点一下→ http://u.nu/ubuntu

Ubuntu 20.04 快速设置指南,请配合浏浏览器自动翻译使用

我的gnome-shell扩展 https://s1.ax1x.com/2020/06/25/N0IFIS.png
zhangjint5
帖子: 238
注册时间: 2011-01-02 12:31
送出感谢: 35 次
接收感谢: 11 次

Re: 多系统引导的福音!UEFI 引导环境 NVRAM 编辑工具 BOOTICE

#3

帖子 zhangjint5 » 2017-01-11 10:08

qy117121 写了:BOOTICE也支持uefi啊,一直没有uefi的设备没注意过
我也是偶然发现的,这下win里面操作方便多了!
烟波钓叟
帖子: 112
注册时间: 2015-04-04 23:20
系统: linux & windows
送出感谢: 4 次
接收感谢: 6 次

Re: 多系统引导的福音!UEFI 引导环境 NVRAM 编辑工具 BOOTICE

#4

帖子 烟波钓叟 » 2017-01-11 19:41

我也是在linux下用efibootmgr来编辑uefi下的引导顺序的,不过我的电脑不能在主板设置里修改引导顺序。
头像
AutoXBC
帖子: 1744
注册时间: 2007-10-23 12:54
送出感谢: 2 次
接收感谢: 24 次

Re: 多系统引导的福音!UEFI 引导环境 NVRAM 编辑工具 BOOTICE

#5

帖子 AutoXBC » 2017-01-11 23:59

真看不出有什么福音,经典的基于 MBR 的引导器本身就没有痛点,链式引导给用户完全的控制权,引导器和引导器配置和操作系统都存储在硬盘中,完全和主板解耦,更换硬件后没有任何影响。

现在弄出个多余的 UEFI,在引导器配置和操作系统中间又插入一层 EFI 接口文件,呈现 UEFI(引导器) => NVRAM(引导器配置) => EFI 文件(接口文件) => 经典引导器 => 经典引导器配置 => 操作系统 这样的超多层复杂结构,并且前两级和主板耦合,后四级与硬盘耦合这样的杂交局面,属于典型的过度设计。
头像
qy117121
论坛版主
帖子: 50234
注册时间: 2007-12-14 13:40
系统: Winbuntu
来自: 志虚国乌由市
送出感谢: 18 次
接收感谢: 362 次
联系:

Re: 多系统引导的福音!UEFI 引导环境 NVRAM 编辑工具 BOOTICE

#6

帖子 qy117121 » 2017-01-12 10:29

AutoXBC 写了:真看不出有什么福音,经典的基于 MBR 的引导器本身就没有痛点,链式引导给用户完全的控制权,引导器和引导器配置和操作系统都存储在硬盘中,完全和主板解耦,更换硬件后没有任何影响。

现在弄出个多余的 UEFI,在引导器配置和操作系统中间又插入一层 EFI 接口文件,呈现 UEFI(引导器) => NVRAM(引导器配置) => EFI 文件(接口文件) => 经典引导器 => 经典引导器配置 => 操作系统 这样的超多层复杂结构,并且前两级和主板耦合,后四级与硬盘耦合这样的杂交局面,属于典型的过度设计。
UEFI确实很讨厌,ESP分区(或者叫EFI系统分区)还只能是FAT32格式。。。
渠月 · QY    https://vz.rs/u
本人只会灌水,不负责回答问题

无聊可以点一下→ http://u.nu/ubuntu

Ubuntu 20.04 快速设置指南,请配合浏浏览器自动翻译使用

我的gnome-shell扩展 https://s1.ax1x.com/2020/06/25/N0IFIS.png
zhangjint5
帖子: 238
注册时间: 2011-01-02 12:31
送出感谢: 35 次
接收感谢: 11 次

Re: 多系统引导的福音!UEFI 引导环境 NVRAM 编辑工具 BOOTICE

#7

帖子 zhangjint5 » 2017-01-12 17:13

AutoXBC 写了:真看不出有什么福音,经典的基于 MBR 的引导器本身就没有痛点,链式引导给用户完全的控制权,引导器和引导器配置和操作系统都存储在硬盘中,完全和主板解耦,更换硬件后没有任何影响。

现在弄出个多余的 UEFI,在引导器配置和操作系统中间又插入一层 EFI 接口文件,呈现 UEFI(引导器) => NVRAM(引导器配置) => EFI 文件(接口文件) => 经典引导器 => 经典引导器配置 => 操作系统 这样的超多层复杂结构,并且前两级和主板耦合,后四级与硬盘耦合这样的杂交局面,属于典型的过度设计。
纠正一下 UEFI 用的不是经典引导器,虽然界面看起来像,但是代码完全不同。

MBR怎么就没有痛点?

1、MBR 链式引导一样复杂,以 Windows 为例,引导过程为:BIOS => CMOS(引导设备选择配置) => MBR(负责寻找活动分区) => PBR (分区引导记录!吐血) => 经典引导器(NTLDR或BOOTMGR)=> 经典引导器配置 => 操作系统。

2、UEFI在系统运行时就可以直接编辑NVRAM设置下次启动哪个操作系统,并且NVRAM没有操作系统局限性。也就是说在 Windows 桌面上放个图标,点击重启进 Linux ,在 Linux 桌面上放个图标,点击重启进 Windows 是件很容易的事情。

而BIOS根本不认操作系统引导器,里面只能选从哪个硬盘启动(相当于执行哪个硬盘的MBR引导代码),而且还必须进到BIOS设置里面才能改,不能再系统运行时直接修改设置。

3、MBR引导扇区只有硬盘顶头的第一个块,玩双(多)系统常常的局面就是后安装的系统的引导器覆盖前一个系统的引导器。所以玩双系统的总是说先装什么系统,后装什么系统。一旦装反了,还要各种修复引导。

而在UEFI中,则是在ESP分区里面,每种操作系统独立一个文件夹放引导器,不会互相覆盖替换。

4、MBR结构固有缺陷,使用硬盘可用空间地址不超过2T的容量限制、最多4个主分区限制。并且还有个相当于容器的扩展分区类型,简直莫名其妙。

UEFI使用GPT分区布局完美解决。并且GPT分区表在硬盘首部和尾部均有冗余备份,所以以前MBR那种分区表损坏所有分区丢失的情况会小很多。

5、MBR主引导记录代码是16位实模式代码(可以理解为DOS的.com文件那种代码),典型的 Intel x86 兼容CPU的引导方式。并且主板也无法校验引导代码,也就是说MBR引导代码可以被病毒感染!并且MBR引导代码在操作系统引导器执行前就被执行了,从而拥有很高的优先级!

而 EFI 不局限于 Intel x86 计算机、其它很多异构计算机也遵循 EFI 规范。并且有安全引导功能可以校验引导器是否被修改过(病毒感染),目前bootmgr和grub2都有签名的版本。



个人认为部分人不喜欢 UEFI 无非有一下几点

1、不愿意学习接受新事物!(况且不算新东西,很早就有了,在 IA64 架构的计算机上。只是 x86_64 最近几年才开始用,感觉像新东西)

2、老软件不兼容,又要学习折腾新软件。
zhangjint5
帖子: 238
注册时间: 2011-01-02 12:31
送出感谢: 35 次
接收感谢: 11 次

Re: 多系统引导的福音!UEFI 引导环境 NVRAM 编辑工具 BOOTICE

#8

帖子 zhangjint5 » 2017-01-12 17:57

qy117121 写了:
AutoXBC 写了:真看不出有什么福音,经典的基于 MBR 的引导器本身就没有痛点,链式引导给用户完全的控制权,引导器和引导器配置和操作系统都存储在硬盘中,完全和主板解耦,更换硬件后没有任何影响。

现在弄出个多余的 UEFI,在引导器配置和操作系统中间又插入一层 EFI 接口文件,呈现 UEFI(引导器) => NVRAM(引导器配置) => EFI 文件(接口文件) => 经典引导器 => 经典引导器配置 => 操作系统 这样的超多层复杂结构,并且前两级和主板耦合,后四级与硬盘耦合这样的杂交局面,属于典型的过度设计。
UEFI确实很讨厌,ESP分区(或者叫EFI系统分区)还只能是FAT32格式。。。
要求可移动设备上必须是 FAT32 ,但是固定硬盘没有这个要求。

另外,不用FAT32用啥?NTFS?你考虑过 CentOS 等 Linux 系统的感受吗,他们如何去配置 ESP ?
头像
AutoXBC
帖子: 1744
注册时间: 2007-10-23 12:54
送出感谢: 2 次
接收感谢: 24 次

Re: 多系统引导的福音!UEFI 引导环境 NVRAM 编辑工具 BOOTICE

#9

帖子 AutoXBC » 2017-01-12 22:05

没有说 UEFI 用了经典引导器,是说 UEFI 本身作为引导器是不可编程的(作为运行环境可编程),使得用户在有弹性引导需求时,必须添加经典引导器和其 EFI 接口文件。这样用 UEFI 替代经典引导器的目的根本实现不了,最终除了额外引入三个层级并未简化流程。

1.BIOS => CMOS(引导设备选择配置) => MBR(负责寻找活动分区) => PBR (分区引导记录!吐血) => 经典引导器(NTLDR或BOOTMGR)=> 经典引导器配置 => 操作系统

NTLDR(BOOTMGR) 是专用引导器,而我们讨论的是通用引导器。专用引导器的设计缺陷不是 MBR 引导流程的缺陷。

BIOS 是纯固件,对用户透明;
CMOS 选引导设备,绝大多数情况非必需,就算有多个磁盘,一般都用主设备盲引;
MBR 活动分区是非必需的,MBR 及其后的空闲空间可以直接包含引导器,并由其透明自举
PBR 非必需的,绝大多数通用引导器忽略 PBR

最后就剩下
经典引导器 => 引导器配置 => 操作系统

一个层级如果不需要用户参与配置修改,那么就是透明的。从这个标准看,经典的 MBR 引导方式只有三个非透明层级:1.用户安装经典引导器,2.配置引导器,3.安装操作系统。而 UEFI 引入了额外三个层级,UEFI(引导器) => NVRAM(引导器配置) => EFI 文件(接口文件),UEFI 本身需要配置(UEFI only,BIOS,Both),NVRAM 需要配置(盲引怎么知道进入哪个系统?),EFI 接口文件需要配置(虽然是操作系统自动添加的,但是磁盘专用分区 + EFI文件的方式就隐含了被破坏的可能,需要单独维护)。

那这三个层级是必要的么?显然不是,经典引导根本不需要。

2.NVRAM 没有操作系统局限性?未必吧,搜索一下各种 NVRAM 被破坏的例子,搜索一下各种教大家清空重置 NVRAM 的教程,这东西作为主板的芯片,要用操作系统内的用户空间程序读写,隐含了巨大的不确定性。

3.玩双系统的总是说先装什么系统,后装什么系统。一旦装反了,还要各种修复引导
玩多系统的都知道,自己安装一个通用引导器,后面任何其他引导器都不用写 MBR 和 PBR,等着被链式引导就行了,先安装哪个有什么关系?

4.MBR 磁盘结构的缺陷,不是 MBR 引导方式的缺陷。一个重写的支持 GPT 的 BIOS(也就是理想中的UEFI)大可以不必深度介入引导过程。

5.安全引导被夸大了,一个可以写 MBR 的病毒,可以在 UEFI 的 GPT 磁盘里写任何它想写的区域。"真正的问题是聪明的黑客将绕过整个认证问题,签名是一个很有用的工具,但是它并不能解决所有的安全问题,而且我认为一些人有点太在意它了。--Linus Torvalds"


总结一下:
BIOS 有大量缺陷,而以 MBR 为起点的经典链式引导没有问题,没问题就不要修改;
UEFI 有大量革新,包括 GPT 等明显可见的改良,但是引导器耦合的结构被过度设计了;
很多人因为没有接触到设计优良的通用引导器,把引导流程神秘化了,并因此产生了偏见;
BOOTICE 是非常棒的软件,对 UEFI 引导流程的批评不涉及 BOOTICE 对 UEFI 的支持;
推荐两个通用引导器 GRUB4DOS 和 WEE,这是大多数 PE 维护盘和 U 盘量产工具的基础。
zhangjint5
帖子: 238
注册时间: 2011-01-02 12:31
送出感谢: 35 次
接收感谢: 11 次

Re: 多系统引导的福音!UEFI 引导环境 NVRAM 编辑工具 BOOTICE

#10

帖子 zhangjint5 » 2017-01-13 8:37

AutoXBC 写了:没有说 UEFI 用了经典引导器,是说 UEFI 本身作为引导器是不可编程的(作为运行环境可编程),使得用户在有弹性引导需求时,必须添加经典引导器和其 EFI 接口文件。这样用 UEFI 替代经典引导器的目的根本实现不了,最终除了额外引入三个层级并未简化流程。

1.BIOS => CMOS(引导设备选择配置) => MBR(负责寻找活动分区) => PBR (分区引导记录!吐血) => 经典引导器(NTLDR或BOOTMGR)=> 经典引导器配置 => 操作系统

NTLDR(BOOTMGR) 是专用引导器,而我们讨论的是通用引导器。专用引导器的设计缺陷不是 MBR 引导流程的缺陷。

BIOS 是纯固件,对用户透明;
CMOS 选引导设备,绝大多数情况非必需,就算有多个磁盘,一般都用主设备盲引;
MBR 活动分区是非必需的,MBR 及其后的空闲空间可以直接包含引导器,并由其透明自举
PBR 非必需的,绝大多数通用引导器忽略 PBR

最后就剩下
经典引导器 => 引导器配置 => 操作系统

一个层级如果不需要用户参与配置修改,那么就是透明的。从这个标准看,经典的 MBR 引导方式只有三个非透明层级:1.用户安装经典引导器,2.配置引导器,3.安装操作系统。而 UEFI 引入了额外三个层级,UEFI(引导器) => NVRAM(引导器配置) => EFI 文件(接口文件),UEFI 本身需要配置(UEFI only,BIOS,Both),NVRAM 需要配置(盲引怎么知道进入哪个系统?),EFI 接口文件需要配置(虽然是操作系统自动添加的,但是磁盘专用分区 + EFI文件的方式就隐含了被破坏的可能,需要单独维护)。

那这三个层级是必要的么?显然不是,经典引导根本不需要。

2.NVRAM 没有操作系统局限性?未必吧,搜索一下各种 NVRAM 被破坏的例子,搜索一下各种教大家清空重置 NVRAM 的教程,这东西作为主板的芯片,要用操作系统内的用户空间程序读写,隐含了巨大的不确定性。

3.玩双系统的总是说先装什么系统,后装什么系统。一旦装反了,还要各种修复引导
玩多系统的都知道,自己安装一个通用引导器,后面任何其他引导器都不用写 MBR 和 PBR,等着被链式引导就行了,先安装哪个有什么关系?

4.MBR 磁盘结构的缺陷,不是 MBR 引导方式的缺陷。一个重写的支持 GPT 的 BIOS(也就是理想中的UEFI)大可以不必深度介入引导过程。

5.安全引导被夸大了,一个可以写 MBR 的病毒,可以在 UEFI 的 GPT 磁盘里写任何它想写的区域。"真正的问题是聪明的黑客将绕过整个认证问题,签名是一个很有用的工具,但是它并不能解决所有的安全问题,而且我认为一些人有点太在意它了。--Linus Torvalds"


总结一下:
BIOS 有大量缺陷,而以 MBR 为起点的经典链式引导没有问题,没问题就不要修改;
UEFI 有大量革新,包括 GPT 等明显可见的改良,但是引导器耦合的结构被过度设计了;
很多人因为没有接触到设计优良的通用引导器,把引导流程神秘化了,并因此产生了偏见;
BOOTICE 是非常棒的软件,对 UEFI 引导流程的批评不涉及 BOOTICE 对 UEFI 的支持;
推荐两个通用引导器 GRUB4DOS 和 WEE,这是大多数 PE 维护盘和 U 盘量产工具的基础。
多数PC机仍是运行 Windows ,Windows 就是这样的启动流程。况且通用引导器(例如GRUB)也就仅仅少了 PBR 这一个过程。


MBR 后和第一个分区前确实有可用空间,某些第3方通用引导器还使用它们,问题是硬盘顶头存储结构就变成了“MBR可执行代码+分区表+55AA标记+MBR可执行代码”后面再就是第一个分区。而且第一个分区前面空多少保留空间还具有不确定性。

我只想说,这样的结构一塌糊涂~!

而且MBR和第一分区前面的区域并没有文件系统结构,需要直接读写硬盘“块”来操作!一些坑爹的程序员编写的软件因为配置MBR而顺道写坏分区表和第一个分区的情况也不少~!


其实 UEFI 引导过程比 BIOS 要精练。(只看执行代码部分。咱们说的NVRAM、CMOS、引导器配置只是他们的数据而已。)

UEFI 引导过程无非就是 UEFI =》 引导器(ESP分区) =》 操作系统内核。

而 BIOS 则是 BIOS =》 MBR =》 PBR (仅Windows)=》 引导器 =》 操作系统内核。


也就是说 UEFI 认识 ESP 分区的文件系统,直接读取里面的引导器文件(根据设置校验引导器文件是否有数字签名,是否被攥改)。

而 BIOS 只知道读取硬盘第一个块,运行上面的 MBR 可执行代码,然后控制权就交给MBR了,靠 MBR 可执行代码来完成接下来的加载步骤。至于分区、文件系统什么 BIOS 统统不认识。

这点来说,UEFI 要比 BIOS 先进的多。


1、真正的 UEFI 并不需要配置(UEFI only,BIOS,Both)。由于现在是处于 BIOS 到 UEFI 的过度阶段,才保留下这个 BIOS 兼容项目。

只有主板 CSM 禁用了才是真正的纯 UEFI 模式。此时你会发现主板 BIOS 和 Both 灰掉不可选。

(有些老显卡也未升级到 UEFI 固件,禁用CSM后会导致显卡无法显示,所以过度期间主板不得不保留 BIOS 兼容功能。预装正版Win8/10的品牌机硬件都是完全支持UEFI,出厂时CSM也都是禁用的)。

NVRAM 破坏依然可以引导,就我的主板来说,NVRAM 配置了无效的项目,或者清空NVRAM,开机时 UEFI 会自动搜索 ESP 分区里面的引导器并添加到引导菜单。不至于出现 NVRAM 破坏就不能引导。

(当然不排除早期 UEFI 的主板不会自动搜索ESP分区里面的引导器等。另外,有些主板默认启用CSM来兼容BIOS模式,也可能不自动搜索ESP分区里面的其它引导器。禁用CSM后使用纯UEFI模式则没问题)。

至于盲引肯定支持(例如U盘光盘等移动设备进行 UEFI 引导),默认是从 \EFI\Boot\bootx64.efi 引导,也不需要预先对NVRAM配置他们,UEFI会自动处理。

2、NVRAM 读写并不受限制于哪种类型操作系统,也就是说不管是 Win 还是 Linux 都可以正常配置它。即使配置错了,上面提到主板也可以自行搜索到引导器,或者从默认盲引。

即使用户空间可以读写NVRAM,但他存储只是配置数据,并无可执行代码,并不具备很大危险性。相反 MBR 是可引导代码,一旦被覆盖破坏,直接影响系统引导。

3、有多少人是把双引导搞坏了才知道要用第3方引导器。第3方引导要是搞坏了,该如何修复?

每个版本的 Windows 安装程序都是强制写 MBR 的,第3方引导器的 MBR 想长生永不被盖很难。也就 Linux 这类系统可以自己选不写 MBR 。

(当然你要是不用 Windows 安装程序,非要手工展开文件或者 Ghost 折腾那也无话可说,这么强的动手能力啥都不是问题!)

另外,你不在装系统的时候让安装程序自动配置引导器,你就得会手动配置(当然可以用第3方软件)。让安装程序自动配置就得接受后安装的引导器强制替换前一个引导器。

要想成功双引导要看后安装的引导器是否可以引导前一个引导器,或者使用第3方引导器。不同的引导器 MBR 还不相同,没有统一规范。

就算是同一个通用引导器(例如 GRUB2),其 MBR 代码还根据第二部分所在分区的 UUID 不同而不同。调整一下分区就导致GRUB2不工作的情况大有人在吧!

可以说 MBR 引导不确定性非常多,由于所用引导器不同,修复方式也大不相同!

4、BIOS只读取硬盘第一个扇区(512字节),也就是 MBR ,其中还有64字节的分区表和两字节的55AA有效标记。分区表地址空间狭小注定最大地址无法超过2TB。

重写GPT的BIOS?这样的思路是有问题的,因为BIOS并不认识硬盘分区表,或者说不是BIOS不支持大硬盘,而是受制于硬盘MBR分区表架构。

目前有个解决方法,就是在GPT分区表前面添加MBR分区表,让MBR分区表和GPT分区表中的分区重叠,这样的东西叫做混合分区表(我搞过)!

不过,这类破坏规范(不考虑向后兼容)来解决问题的做法还不如升级到 UEFI 去!

5、“一个可以写 MBR 的病毒,可以在 UEFI 的 GPT 磁盘里写任何它想写的区域。”

你说的没错,问题是写到 MBR 的区域是可执行代码,那么他将会是硬盘上最先被执行的实模式代码。而在 UEFI 中就算可写,也无法成为被 UEFI 执行的代码(安全引导启用的情况下)。所以 UEFI 引导器部分是可以保证安全的。

我单位就查到过 MBR 病毒。况且 MBR 代码是16位实模式代码,访问硬件的权限大着呢。不校验这些代码就运行确实是一个很危险的事情。

不过现在这个时代不像DOS时代,并不是引导型病毒泛滥的时代。所以说可以不用太在意。



MBR 可执行空间狭小,导致引导器只是第一部分在 MBR 中,主要部分仍在普通分区中,其文件更容易遭到破坏。(好好的一个引导器被拆成两部分)而且可能出现好几个分区都有引导器的部分文件残留。

而UEFI则是将引导器按文件夹区别统一放在ESP专用分区中,并对该分区有一定的保护措施。(例如即使是FAT32,但也只有root/Administrator才能访问,Windows还不主动挂载呈现ESP分区)


在安装系统时,每个系统都试图用自己的MBR去替换硬盘现有的MBR(上面提到的第一部分),及容易被坏。而且MBR是重要引导代码,被破坏直接影响系统引导。

在 MBR 的部分并不以文件形式呈现,而是直接对硬盘进行块操作,导致配置,备份,还原都要使用专用程序,而不能通过更加安全简单的操作文件方式来完成。

上面也说了,坑爹的软件写坏MBR及分区表的情况也比较常见。


而 UEFI 引导器代码只有一部分,存放在 ESP 分区中,并且全部以文件形式呈现。


对于已经正常使用的机器,保持 BIOS + MBR 并无问题。(目前好像也只有 Intel x86 架构使用这种方式引导。)

但 UEFI+ GPT 是未来的趋势。可扩展性,支持不同架构是其最大优点。

WEE 没用过,但 GRUB4DOS 并不支持 UEFI 引导。而 GRUB2 可同时支持 BIOS 和 UEFI 引导,更为通用。

GRUB4DOS 相比 GRUB2 的最大好处恐怕就是只有一个文件就能搞定(仅支持x86架构),不像 GRUB2 有一大堆功能模块和支持其它架构的模块。
头像
AutoXBC
帖子: 1744
注册时间: 2007-10-23 12:54
送出感谢: 2 次
接收感谢: 24 次

Re: 多系统引导的福音!UEFI 引导环境 NVRAM 编辑工具 BOOTICE

#11

帖子 AutoXBC » 2017-01-13 23:05

UEFI 的优点不是 UEFI 引导流程的优点,上面多处把其混在一起说,使得问题看上去好像是 "UEFI 好还是 BIOS 好?",其实我一直试图避免讨论这个问题,因为在整个 IT 工业发展进程上看,拒绝 UEFI 显得毫无意义。

MBR 磁盘结构的缺陷也不是 MBR 引导流程的缺陷。BIOS 读 MBR 第一扇区,这是整个引导流程的核心,至于后面的分区表什么结构,其实不是重点。BIOS 读 GPT 磁盘的第一扇区,这没什么不可以,已经有人做出来了。
http://chenall.net/post/grub4dos_umbr/

上面两点多次强调,可惜都被无视了。


UEFI 引导流程的设计宗旨是:成为唯一通用引导器,第三方通用引导器边缘化。这一思路的缺陷是,通用引导器应该是可编程的,UEFI 呈现出的结果是不可编程,只可配置,把 EFI 接口文件放在 ESP 分区里,就这么多。

如果接受这种设定,那么显然优雅简洁。如果对灵活性稍有要求,我们还是必须求助于第三方通用引导器,UEFI 画出的大饼只是个障碍。

这种引导器从软件层面(硬盘存储)向硬件层面(主板存储)过渡的趋势,其实是用户控制系统还是系统控制用户两种思想的冲突,工业界的硬件厂商和软件巨头合力把两者之间的缝隙焊死,再加上一把锁(安全引导),更多是维护工业界的利益,对用户加以控制。手机厂商也如法炮制,都是一个道理。

只是,我不喜欢这样,我喜欢有控制权。长远的看,PC 为什么要和 GPT 绑定,为什么要和 FAT32 格式的 ESP 分区绑定,这些都不是必然。固件读入第一扇区然后放手,后面就有无限的可能性,现在,这些都没有了。
zhangjint5
帖子: 238
注册时间: 2011-01-02 12:31
送出感谢: 35 次
接收感谢: 11 次

Re: 多系统引导的福音!UEFI 引导环境 NVRAM 编辑工具 BOOTICE

#12

帖子 zhangjint5 » 2017-01-14 8:18

“BIOS 读 GPT 磁盘的第一扇区” BIOS始终读取磁盘第一扇区,至于分区表架构是GPT还是MBR,BIOS是不关心的。

所以无论如何,BIOS 都会读取磁盘的第一扇区,并当做程序来执行。你想说的应该是 GPT 磁盘第一扇区的代码被 BIOS 当做 MBR 代码来执行吧?

这个在 MBR 流程下本来就很容易!

你说的没错! MBR 引导核心就是硬盘第一个扇区的执行代码。BIOS放手后,只要 MBR 引导核心可以往下走,就有无限可能。读取 GPT 当然也不在话下!

什么 MBR 磁盘架构都是扯淡,其实可以完全不要现有的 MBR 分区表和结构(像软盘那样不要分区表也未尝不可),这样就没有2TB容量和4主分区限制。只要一点“MBR 引导核心可以接下来装载工作”就可以了。

而UEFI不行,必须要有一种分区表架构(目前推荐GPT架构和兼容MBR架构),必须要有文件系统(目前ESP推荐FAT32),必须要有EFI接口文件。


可是,明显 MBR 如果这样做,就是为了解决问题而违背最初定义的规范。因为只有一个唯一的要求:那就是,第一扇区的 MBR 代码可执行。(进一步夸张点说,到那个时候,不只是操作系统像 Linux/Android 这样碎片化了,磁盘存储架构都各自为政,呈现碎片化,谁都可以不兼容谁)

换个说法,就是只要能达到目的,什么方法都能想出来,不管与其它兼容不兼容,以后扩不扩展,想办法解决问题就行。最后可能得到一个面目全非的 MBR 磁盘架构 。与其这样,还不如完全推到,重新做一种一致的引导方式和磁盘结构。



打个不一定太恰当的比方

前一种就是:你有一辆车,点着火之后(BIOS控制权交给MBR后),在空旷的广场上想怎么开,就怎么开。

而后一种就是,车辆我要先检查一下这是一辆车吗?车安不安全(可选),广场上有格子(分区表架构),广场上有一个固定的驶入点(ESP)。


实际第一种情况是,广场上虽然空旷,但还是得按照一定规则行驶(采用一种统一的分区表结构;如果不统一,其它不同系统无法兼容读取磁盘文件)。


你所不喜欢的就是后一种的条条框框。可是前一种虽然可以不要条条框框,但实际上又不得不拥有一个的条条框框来实现统一。然后MBR引导代码还必须兼容这种条条框框。然后你自己还觉得我可以不受限制于条条框框。


有一种情况就是前者可以做到,而后一种做不到。就是从 MBR 开始,全部都按照自己的思想来,不采用任何现有的规范,例如现有的磁盘架构和分区表,文件系统,操作系统。这种情况 UEFI 是做不到的!

你有本事,从 MBR 开始就可以自己动手干。但是实际上没有多少这样的需求!



几十年了,MBR 的实际产品并无改善,没有完美的解决上述问题。最后替换品选择了放弃这种流程。是否是因为这种流程下诞生的产品难以扩展和兼容两者兼顾呢?

相反 EFI 也是几十年前安腾架构早就使用过,他的流程看起来并不完美,可是实际产品这么长时间,经历了扩展到 UEFI,从IA64架构扩展到 X64 架构等等,均能满足需求。

MBR引导流程理论上没问题,可是实际产品就如前面所说的各种问题,当然这不是流程直接造成的。

作为厂商,必须从实际产品考虑,推行哪种显而易见。


就目前计算机来说,实际的工作都是在操作系统完全启动后的环境来做,在操作系统内核引导至保护模式、长模式后,上述两者并没有明显差异。

作为一个引导器,你的工作就是负责加载(安全引导可选)操作系统内核,过于灵活的可编程并不显得十分有意义,反而会造成安全问题。
dddp
帖子: 27
注册时间: 2008-12-10 13:37
送出感谢: 0
接收感谢: 1 次

Re: 多系统引导的福音!UEFI 引导环境 NVRAM 编辑工具 BOOTICE

#13

帖子 dddp » 2017-03-19 22:20

不用吐槽uefi,比bios强大太多,不用管各种五花八门引导程序了。这个简直是神器级别的。如此简单
kappa8086
帖子: 308
注册时间: 2008-06-23 14:42
送出感谢: 0
接收感谢: 0

Re: 多系统引导的福音!UEFI 引导环境 NVRAM 编辑工具 BOOTICE

#14

帖子 kappa8086 » 2017-08-06 18:21

我之前也对UEFI多引入的耦合性吐过槽,程序员的强迫症。。。
但uefi为什么引导比传统bios快很多,去掉“万能”的链式引导这一动作很关键,虽然的确是耦合性高了,这是一种必然的取舍。

链式引导的哲学就像拉绳索,由细渐渐到粗,直接上粗的是不行的。MBR用的只能是实模式代码,这意味着在这之前CPU不能切换运行状态,整个自检过程,查询引导硬盘的过程,都要在极细的这一端完成,之后这一小段引导代码在逐步引入文件系统驱动,找到真正的引导程序,载入OS核心之后,CPU才能进入所谓保护模式,执行32位/64位代码,这时发现之前干的所有事都白干了,硬件自举的事还得在再重来一次。这个效率就是痛点那。

后来想想也就想开了,绑定FAT32分区就绑定呗,这只不过是一个达到几百MB的大型MBR引导块,协议由零面零道一扇区变成了 GPT+ESP,而且以后磁盘上的所有元素对于文件系统层面都是可见的,这未尝不是一种简化。
唯一看着不爽的就是每在ESP里加一个引导程序,还得向UEFI注册,就是写NVRAM了,不过目前的UEFI实现这也不是必须的,只要存在 /$esp/boot/bootx64.efi 这个引导就可以不需要注册,这可以当作是新链式引导的起点。

再来就是现在非常依赖远程切换系统,这个这个,耦合是有道理的啊,否则真干不出来这事~
yanglei_k
帖子: 1
注册时间: 2020-06-11 1:23
系统: win10
送出感谢: 0
接收感谢: 0

Re: 多系统引导的福音!UEFI 引导环境 NVRAM 编辑工具 BOOTICE

#15

帖子 yanglei_k » 2020-06-11 1:58

大佬好,遇到一个棘手问题,求助。
dell笔记本,uefi模式。
前阵子折腾黑苹果,给从盘做了空白efi引导分区,后删除此分区,黑苹果引导工具里有reset nvram选项用过。
后来回到单win10发现一个问题很棘手。表现如下:
dell bios 启动项管理下。
会列出本机所有分区列表,以为pci sata 等属性和uuid形式排列开来,
dell系统硬盘5个分区,除去esp加c盘后面还有3个隐藏分区放置dell系统还原出厂镜像和程序。
单硬盘一切正常。
加装硬盘后,dell boot 分区列表里,新的数据盘就会排到原来主硬盘上方。
然后win10好像自动运行bcdedit之类命令去生成那个标准的引导名称windows boot manager,
此时这个引导项会去列表第一个分区,也就是后加的数据硬盘分区,指向这个分区,导致启动失败。指向的efi-microsoft-boot-bootmgfw.路径空,dell的还原系统引导同时也找不到自己的隐藏分区无法运行。本以为是识别uuid,现在发现dell还原工具可能也是安装顺序去找分区。


dell默认bios磁盘是raid on模式
此模式下我加装的sata数据盘无论更改磁盘模式与否(ahci) sata盘永远在nvme的主盘之上,造成之前的问题。这个笔记本两个m2槽定义一个支持sata所以没法对换位置测试。

双nvme协议的硬盘,bios的raid on模式下,磁盘的顺序正确,主盘为上从盘为下,功能正常。但无法ubuntu和黑苹果。识别为pci下的sata下的0102两个盘名称

改变磁盘模式为ahc后,主盘继续被挤到下方,出现以上问题。ubuntu和黑苹果可用,win10不保险,因为那个boot manager不论我删除还是下移都不定时出现新的错的manager,保险的是每次启动f12直接选主盘bootx64那种方式。(ahci下,识别列表里为pci-pci-0x1b数据盘高于0x1d主硬盘)

现在我是实在搞不懂这个分区顺序是什么原理。不同的模式还会改变。
dell不能提供支持,让我把系统放在数据盘用,可数据盘那个型号速度一般。
我也不确定与之前reset nvram有无关系。
现在情况就是单盘正常,多盘raid模式正常,ahci错误,多盘为sata盘的话怎么弄都是错误。
望指点,谢谢。
回复

回到 “启动和引导”