请教关于 grub4dos 读取 gpt 磁盘的问题

wintoflash

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

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

yzw92

会不会有影响

2011yaya2007777

可以修改一下 grub4dos 判断有无分区表的规则：
当分区 ID=0xEE 时，允许 chs=0xFFFFFF。

不点

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

这是翻译后的结果。没有说必须是ffffff。如果设置为feffff，GTP启动也是正常的，允许的。

2011yaya2007777

设置为磁盘上最后一个逻辑块的CHS地址。如果无法在此字段中表示值，请设置为0xFFFFFF。

wintoflash

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页

不点

我认为，grub4dos 完全支持 c=1024，h=256，s=63

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

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

2011yaya2007777

应该不会这样规定吧。在哪个文件里？我觉得应当是feffff.

2011yaya2007777

”chs应该填 ff ff ff‘’uefi还有这规范？

2011yaya2007777

我觉得，不一定chs值一定准确，GPT分区也不需要它。而是要符合约定俗成。s在1-0x3f之间，h在0-0xfe之间，c在0-0x3ff之间。

wintoflash

不点 发表于 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。

不点

在 grub4dos 的内核已经接管控制的情况下，分区表上的 chs 值是用不上的。bpb 表上的 hs 值也用不上。

不点

如果是硬盘，你可以假定 h=255，s=63，这几乎成了唯一标准。极少数恶意主板采用其他值。

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

不点

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。

wintoflash

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

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

2011yaya2007777

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