请教关于 grub4dos 读取 gpt 磁盘的问题
本帖最后由 wintoflash 于 2020-6-1 07:10 编辑请问 grub4dos 读取 GPT 分区表磁盘时，会不会忽略 protective MBR 里面记录的分区信息 (比如 CHS)?
如果 protective MBR 里面的分区 CHS 之类的全是乱的，会不会导致 grub4dos 不认这个磁盘？ 本帖最后由 2011yaya2007777 于 2020-5-31 19:54 编辑
首先要判断是否为有效的MBR分区表，因此不会忽略分区表信息。 2011yaya2007777 发表于 2020-5-31 19:53
首先要判断是否为有效的MBR分区表，因此不会忽略分区表信息。
如果只有 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。
如果是硬盘，你可以假定 h=255，s=63，这几乎成了唯一标准。极少数恶意主板采用其他值。
所以，根据 lba 来计算 chs 的值，应该是不难的，只需要写好一个公式即可。 在 grub4dos 的内核已经接管控制的情况下，分区表上的 chs 值是用不上的。bpb 表上的 hs 值也用不上。 不点 发表于 2020-5-31 20:35
grub4dos 在读盘时，首先要确定 c/h/s 的值，以及 lba 的支持与否。如果确定不了这些关键信息，那就无法进 ...
是这样的，这个问题来自 https://github.com/a1ive/grub/issues/26
NOTE:For partitions which begin or end beyondthe 1024th cylinder, the three CHS bytes should always be filled with: FE FF FF ; which are decoded as follows:Byte 1:FEh = 254for 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 about8.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。 我觉得，不一定chs值一定准确，GPT分区也不需要它。而是要符合约定俗成。s在1-0x3f之间，h在0-0xfe之间，c在0-0x3ff之间。 ”chs应该填 ff ff ff‘’uefi还有这规范？ 应该不会这样规定吧。在哪个文件里？我觉得应当是feffff. 我认为，grub4dos 完全支持 c=1024，h=256，s=63
只有 dos 才不支持 h=256，而只支持 255。
所以，分区表上的 ff ff ff 应该是没问题的。你可以让 yaya 改进一下代码，如果有必要的话。 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/files/resources/UEFI_Spec_2_8_A_Feb14.pdf
116页
设置为磁盘上最后一个逻辑块的CHS地址。如果无法在此字段中表示值，请设置为0xFFFFFF。 这是翻译后的结果。没有说必须是ffffff。如果设置为feffff，GTP启动也是正常的，允许的。 2011yaya2007777 发表于 2020-5-31 21:13
应该不会这样规定吧。在哪个文件里？我觉得应当是feffff.
没问题，grub4dos 支持 h=256 的情况。而在 lba 已经支持的情况，chs 是用不上的。所以，它是 ff ff ff 也没问题。这个 ff ff ff 只存在于结束扇区上。起始扇区上是准确的数值。结束扇区上的值，永远都用不上。
h=256 时，dos 无法启动。所以，各个厂家才让 h=255。
但 grub4dos 适应性很强，各种极端情况都能适应。
可以修改一下 grub4dos 判断有无分区表的规则：
当分区 ID=0xEE 时，允许 chs=0xFFFFFF。 会不会有影响
页:
[1]