无忧启动论坛

标题: 请教关于 grub4dos 读取 gpt 磁盘的问题 [打印本页]

作者: wintoflash 时间: 2020-5-31 18:47
标题: 请教关于 grub4dos 读取 gpt 磁盘的问题
本帖最后由 wintoflash 于 2020-6-1 07:10 编辑

请问 grub4dos 读取 GPT 分区表磁盘时，会不会忽略 protective MBR 里面记录的分区信息 (比如 CHS)?

如果 protective MBR 里面的分区 CHS 之类的全是乱的，会不会导致 grub4dos 不认这个磁盘？

作者: 2011yaya2007777 时间: 2020-5-31 19:53
本帖最后由 2011yaya2007777 于 2020-5-31 19:54 编辑

首先要判断是否为有效的MBR分区表，因此不会忽略分区表信息。

作者: wintoflash 时间: 2020-5-31 20:09

2011yaya2007777 发表于 2020-5-31 19:53
首先要判断是否为有效的MBR分区表，因此不会忽略分区表信息。

如果只有 CHS 是乱填的，会不会有影响？

作者: 不点 时间: 2020-5-31 20:35
grub4dos 在读盘时，首先要确定 c/h/s 的值，以及 lba 的支持与否。如果确定不了这些关键信息，那就无法进行后续的读文件操作。

而要确定 chs 三维几何参数的值，就要有个探测的步骤。这不需要用分区表来确定 chs 的值。

用分区表来确定 chs 的值，是在 map 一个 hd.img 的时候。如果 map 命令行未指定 h 和 s 的值，则会探测 hd.img 的首扇区上的分区表，从分区表来确定这个虚拟硬盘的 h 和 s 值。此时，如果分区表上的 h 和 s 是胡乱填的，则会导致探测失败。此时，可以在命令行指定 h 和 s，这就可以继续 map 了。

如果不是进行 map 操作，而且 bios 支持 lba，那么，h 和 s 是用不上的。也就是说，分区表上的 h 和 s 可以是不正确的。

但尽量要保证是正确的。因为，不正确的 hs 值，有可能在启动时导致启动代码的失败。启动代码在启动的早期，通常都是用 chs 模式来读盘的，即使支持lba，也不用lba。

作者: 不点 时间: 2020-5-31 20:46
如果是硬盘，你可以假定 h=255，s=63，这几乎成了唯一标准。极少数恶意主板采用其他值。

所以，根据 lba 来计算 chs 的值，应该是不难的，只需要写好一个公式即可。

作者: 不点 时间: 2020-5-31 20:52
在 grub4dos 的内核已经接管控制的情况下，分区表上的 chs 值是用不上的。bpb 表上的 hs 值也用不上。

作者: wintoflash 时间: 2020-5-31 20:59

不点发表于 2020-5-31 20:35
grub4dos 在读盘时，首先要确定 c/h/s 的值，以及 lba 的支持与否。如果确定不了这些关键信息，那就无法进 ...

是这样的，这个问题来自 https://github.com/a1ive/grub/issues/26

NOTE:For partitions which begin or end beyond the 1024th cylinder, the three CHS bytes should always be filled with: FE FF FF ; which are decoded as follows:Byte 1: FEh = 254 for a total of 255 heads.Bytes 2 and 3: FFh and FFh — split into two full binary counts of 6 bits (11 1111; 3Fh = 63 sectors), and 10 bits (11 1111 1111) or 3FFh = 1023 for a total of 1024 cylinders. CHS: 1023, 254, 63.This tuple corresponds to an LBA sector of: 16450559. That's a point where about 8.4 GB of hard disk sectors could be accessed (16,450,560 sectors * 512 bytes/sector = 8,422,686,720 bytes).16-byte partition table entries can not exceed 1024 cylinders for their Starting and Ending CHS bytes! When utility programs display CHS tuples with a cylinder value larger than 1023, they can only do so by computing pseudo-CHS values from the 4-byte "Starting Sector" or "Partition Size" values.

如果是一个很大的分区，chs应该是 fe ff ff，但是根据uefi的规范，gpt分区表硬盘的mbr上chs应该填 ff ff ff。

作者: 2011yaya2007777 时间: 2020-5-31 21:03
我觉得，不一定chs值一定准确，GPT分区也不需要它。而是要符合约定俗成。s在1-0x3f之间，h在0-0xfe之间，c在0-0x3ff之间。

作者: 2011yaya2007777 时间: 2020-5-31 21:11
”chs应该填 ff ff ff‘’uefi还有这规范？

作者: 2011yaya2007777 时间: 2020-5-31 21:13
应该不会这样规定吧。在哪个文件里？我觉得应当是feffff.

作者: 不点 时间: 2020-5-31 21:15
我认为，grub4dos 完全支持 c=1024，h=256，s=63

只有 dos 才不支持 h=256，而只支持 255。

所以，分区表上的 ff ff ff 应该是没问题的。你可以让 yaya 改进一下代码，如果有必要的话。

作者: wintoflash 时间: 2020-5-31 21:17

2011yaya2007777 发表于 2020-5-31 21:13
应该不会这样规定吧。在哪个文件里？我觉得应当是feffff.

Set to the CHS address of the last logical block on the disk. Set to 0xFFFFFF if it is not possible to represent the value in this field.

https://uefi.org/sites/default/f ... pec_2_8_A_Feb14.pdf
116页

作者: 2011yaya2007777 时间: 2020-5-31 21:27
设置为磁盘上最后一个逻辑块的CHS地址。如果无法在此字段中表示值，请设置为0xFFFFFF。

作者: 2011yaya2007777 时间: 2020-5-31 21:31
这是翻译后的结果。没有说必须是ffffff。如果设置为feffff，GTP启动也是正常的，允许的。

作者: 不点 时间: 2020-5-31 21:31

2011yaya2007777 发表于 2020-5-31 21:13
应该不会这样规定吧。在哪个文件里？我觉得应当是feffff.

没问题，grub4dos 支持 h=256 的情况。而在 lba 已经支持的情况，chs 是用不上的。所以，它是 ff ff ff 也没问题。这个 ff ff ff 只存在于结束扇区上。起始扇区上是准确的数值。结束扇区上的值，永远都用不上。

h=256 时，dos 无法启动。所以，各个厂家才让 h=255。

但 grub4dos 适应性很强，各种极端情况都能适应。

作者: 2011yaya2007777 时间: 2020-6-1 08:30
可以修改一下 grub4dos 判断有无分区表的规则：
当分区 ID=0xEE 时，允许 chs=0xFFFFFF。

作者: yzw92 时间: 2020-6-2 06:39
会不会有影响

欢迎光临无忧启动论坛 (http://wuyou.net/)