Grub4DOS 在 64GB 优盘 （FAT32格式）下的使用体验及期望解决的问题

不点

提供的信息不多，不足以确定问题的根源。根据已经提供的描述，我觉得，可能性较大的，是 ultraISO 的问题。

可以试试用 diskgen 来制作 FAT32 分区。

还可以试试用 imdisk 来制作 FAT32 分区。

另外，楼主没说究竟是 g4d 启动出现问题呢，还是 g4e 启动出现的问题。毕竟 g4d 和 g4e 是有一些差别的，在底层是不同的。g4d 基于 grub legacy，而 g4e 是基于 grub2。

应该说清楚究竟是哪一个出现了问题。顺便说，我对 g4d 比较了解。我认为，g4d 在 FAT32 格式方面，具有完整的适应性，不太可能存在无法 mount 的情况。

不点

hzyry2046 发表于 2024-3-15 07:27
看知乎说fat32有两种寻址标准（zhua删nlan.zhi删hu.com/p/74376993）会不会是g4d只支持32GB的那种寻址？

网页 https://zhuanlan.zhihu.com/p/74376993 提到的 32G 分区大小限制，只是说操作系统本身的格式化工具，最大只支持格式化为 32G 的 FAT32 分区。如果用第三方工具，可以格式化为 64G 或更大。从闪迪官方旗舰店购买的 500G 优盘，买来之后就是 FAT32 格式的，而且是单一分区。也就是说，FAT32 分区的大小，已经证明可以达到 500G。而根据刚才提到的知乎网页中的描述，FAT32 分区的容量最大可达 2T。

这个 500G 的 FAT32 分区，在 Windows 下正常识别。在 grub4dos 下（无论 legacy BIOS 或者是 UEFI），也正常识别。

如果楼主不幸被骗，购买了坑爹的 “扩容盘”，那自然是各种不正常，不用说了。

至于说 BIOS，不像是有问题的样子。根据楼主的说明，32G 优盘是正常的。而 64G 的优盘，也把关键文件都放在开头，所以不会有影响。FAT32 格式的关键数据结构（即 BPB相关数据）都位于分区的最开头。所以，mount 总是会成功，按照原理来说，不可能失败。

但是，如果把 g4e 的文件放在优盘的尾部，这恐怕是有问题的吧？你放在尾部，那么 UEFI 也是有可能失败的，我这么认为。我对于 UEFI 没有深入研究，我不太清楚 UEFI 是否像 legacy BIOS 那样存在最大支持的扇区号问题。如果存在同样的问题，那么，UEFI 的相关启动文件，都需要放在优盘的开头，也就是说，不可以把 UEFI 的分区放在优盘尾部。

不点

再次回复一下楼主。

我从闪迪旗舰店购买的 500G 优盘（实际容量约 460G），制作 grub4dos 启动盘。以下凭记忆来描述制作过程。

1、原装优盘就是 FAT32 分区格式，单一分区，无需重新格式化。
2、删除原装优盘里面免费赠送的优盘加密软件。我不需要这些加密软件。其实，主要是，我一看见“软件”，就想到 “流氓”，一阵恶心、呕吐，身体不适，所以必须删除。
3、把 g4d、g4e 的相关文件、文件夹都拷贝到优盘。
4、写入 g4d 的分区引导记录（即 PBR，或者叫做 VBR）。这可以用 BOOTICE 来做。

此时，用 UEFI 启动，正常。

但后来用 legacy BIOS 启动时，发现不行，无法启动。这才知道，优盘上的 MBR 代码并未把控制权交给 优盘的分区引导记录。于是，

5、用 BOOTICE 把 wee 安装到优盘的 MBR 上。

至此，legacy BIOS 也能正常启动 grub4dos 了。

顺便说，哪个软件值得信赖？这个问题很重要。我使用 diskgen 有很多年了，从未发现 diskgen 有过什么大毛病，比如说，把什么东西整坏了。所以，在需要格式化的时候，我通常会用 diskgen 来做——放心。

另外，bootice 在写 wee 的时候有个 bug，它计算菜单起始位置有错误。workaround （躲过此毛病的办法）就是：自定义 wee 的菜单，把菜单中的第一句，重复写一次。也或者在第一句之前增加一条注释语句，注释语句的长度稍微长一点，达到 30 个字符以上即可。由于 BOOTICE 的 bug，反正第一句是不能正常执行的。它会从菜单之后的某个字节处开始执行。我们刚才做的，无非是想要保证：第二句能够正常执行。

不点

刚才说了，用 BootICE 把 grub4dos 安装在 PBR 以后，启动失败，又安装 wee 到 MBR 才成功。这也挺麻烦的，尤其是 wee 的菜单还要进行微调。

其实，不需要安装 wee。安装微软的 MBR 代码也是可以的。

当时我也尝试安装微软的 MBR 代码，但依旧失败！

我慌了，于是，赶紧安装 wee —— 紧急关头，先解决问题再说。

后来知道了，优盘的 FAT32 分区处于 “未激活” 状态，那么，微软的 MBR 代码，就不会把控制权交给 PBR 代码。使用微软的 MBR 代码，必须激活 PBR 分区，这才能够正常递交控制权。

岁数大了，精力不够使，容易忘事。所以，激活、未激活，这种事情，容易忽略。而在失败后，又容易紧张。紧张之后，就找个 wee 来解决。其实，安装了 wee 之后，就不需要 PBR 了（因为 wee 自己能找到并加载 grldr）。所以，wee 不是来解决 PBR 无法接管控制权的问题的。“把 PBR 分区激活” —— 这才真正解决 MBR --> PBR 的控制权递交失败的问题。

不点

假大空 发表于 2024-3-16 07:19
听不点大佬娓娓道来，收获颇多

感谢假大人善待老年人。老年人身体和精神都很脆弱，不像年轻人那么具有承受力了。

不点

blank007 发表于 2024-3-16 08:54
多谢不点大侠的指点

        经过再次尝试，基本断定这个现象与 UltraISO 有关。

结果好，就是一切都好。感谢告知详情，让我也能学到不少知识。

不点

szwp 发表于 2024-3-16 09:58
HPUSBFW格成dos再启动grub.exe试

这也是个思路。如果 DOS 能够启动，那就说明，FAT32 的分区是正常的，是可以 mount 的。假如说，进入 grub4dos 环境以后，在 grub4dos 底下无法 mount 分区、无法访问分区里面的文件，那就应该算是 grub4dos 的 bug 了。

DOS 底下运行 grub.exe，这只能临时测试用用，这是可以的。不要用于正式发布的产品中。这道理，以前说过。DOS 修改了 BIOS 建立的中断向量表，而运行 grub.exe 之后，无法把这个中断向量表 100% 恢复为 P-O-S-T（通电自检）后的状态。换句话说，中断向量表已经被污染了（或者说，不干净了）。在大多数情况下，不干净的中断向量表也能正常工作。但对于某些品牌电脑，这会产生死机等问题。所以，为了保险起见，我们最好就不要再经由 DOS 而进入 grub4dos 了。

如果是在 syslinux 或 grub2 之下用 kernel 或 linux 命令加载 grub.exe，这是没问题的（此时 grub.exe 是看作 Linux 的内核格式，而不是当作 DOS 的 EXE 格式）。这里不存在 “DOS 污染中断向量表” 的问题。syslinux，grub2，linux 等，都不污染中断向量表。其实，严格来说，Linux 污染了一个中断向量，也就是位于物理内存最开头的4个字节（它应该指向 “除以零” 这个故障的处理程序的入口）。由于 “除以零” 这个故障是很少会发生的，所以，这个问题也就不严重。既然我们忽略这个问题，那么，Linux 也就被认为是 “没有污染中断向量表” 了。

不点

我今天再次进入这个话题，提出一个问题，供各位大人以及开发者们思考。

我注意到，楼主的 64G 的 FAT32 分区，能够在 Windows 下正常使用。然而，grub4dos 启动后，却不能 mount 这个分区。

——对了，这就是问题。Windows 能识别，而 grub4dos 不能识别，这肯定有疑问，对不对？

也就是说，有很大的可能性，grub4dos 对 FAT32 格式的检查过于 “严格”，导致 UltraISO 创建的这个比较 “特殊” 的 FAT32 格式被判定为 “非法” 或 “未知” 格式。

因此我觉得，这个问题值得楼主和开发者们继续深入讨论研究。

不点

blank007 发表于 2024-3-17 12:01
楼上有朋友说FAT32存在2种寻址方式。估计 GRUB4DOS 与 Bootice 的寻址方式一致， UltraISO 对 >=32GB 的  ...

如果 yaya 能够提供一个调试版，让你测试，那就能够定位出错的位置了。

你把有问题的环境弄好，让它再现问题，以便运行 yaya 的调试版来跟踪执行。

你甚至也可以试试在虚拟机上弄，让问题再现。这样的话，yaya 自己就可以调试了。

既然这个问题与 BIOS 无关，那它就是个 FAT32 格式的问题。可能性较大的，是在 BPB 数据结构方面，有异常情况出现。所以，用虚拟机应该也能再现这个问题。

你把调试环境弄好以后，给 yaya 留言，看看 yaya 有没有时间来做这个事。

不点

2011yaya2007777 发表于 2024-3-17 19:01
好像楼主把U盘重新格式化了，问题得到了解决。如果能重现bug，作为技术问题可以探讨。如果楼主不嫌麻烦的话 ...

yaya 来了，好。

我说几点想法，不一定对，仅供参考。

首先，UltraISO 制作了一个并不常见的 FAT32 格式。这里姑且认为它的格式是 “正确” 的（因为毕竟 Windows 也承认了它的格式）。尽管它 “正确”，但却不常见，属于 “正确” 里面的 “罕见” 或 “奇葩” 情况。我们的开发者，如果有精力、有时间、有兴趣，是可以去支持它、适应它的。如果没时间、没精力、没兴趣，也完全可以放弃支持它。

其次，这个问题，应该可以在虚拟机里面重现。楼主可以制作一个极小的 FAT32 分区，提供给 yaya 来研究。我觉得问题很可能就出在 BPB 上。甚而至于，只要用一个 16 进制编辑器来查看这个异常分区的 BPB，并与其它正常分区的 BPB 进行比较，就有可能发现问题。

不点

我再说第三点看法。

grub4dos 对于 FAT32 的支持，是严格遵照网上搜集到的知识和标准的。有微软公开的标准，也有未公开的、但被网上高人 hack 出来的 “内幕标准”。所以，一个 “正常” 的 FAT32 分区，不太可能让 grub4dos 无法 mount。

在最终结论没确定之前，我姑且认为，UltraISO 在 “走钢丝”，在 “似是而非” 的模糊领域进行 “试探”。这种 “新” 格式，尽管能够被 Windows 支持，但谁敢保证，以后不会出问题？比如说，某一天，突然这个分区瘫痪了！比如，是因为微软自己的某个工具软件不承认这个 FAT32 格式，而产生误操作，把它毁了！或者，虽然微软没有毁掉它，但第三方某个应用程序不能很好地与这个新的 FAT32 格式兼容，那照样也存在毁掉的风险！

如果最终能够确定，这确实是罕见的奇葩格式，那么，我倒是倾向于，不再支持这种格式。就是说，有意不去支持这种格式。“走钢丝” 式的 “正确”，能算是 “正确” 吗？我们知道，世上没有绝对的东西。正确性也是相对的。从不同的视角去看，得到的结论也不同。如果按照 “微软 Windows 能够识别” 就定义为 “正确”，那就是正确。如果考虑到，微软自己从不创建这种格式，那么，这就不属于 “正确” 的范畴。所以说，正确性是相对的。你倾向于哪一个，就是哪一个。没有 “绝对正确” 这回事。

不点

2011yaya2007777 发表于 2024-3-17 20:28
前段时间，一个老外反馈，不能挂载NTFS分区。分区在500Gb左右。他是使用linux工具格式化的。查启动分区的BP ...

这个世界，给人的自由度是蛮大的，各种事情都有。而且，存在皆合理，你又不能说人家是 “错误” 的。

我只能站在我的角度来看问题，因为我永远也不可能站在别人的角度。

NTFS 和 FAT系列格式，都是微软的。微软应该是权威。除了公开的 “标准”、“规范” 以外，还有未公开的规范和标准。而且，还有所谓 “事实工业标准”，这可能与公开或未公开的标准都有所不同。规范是很难得的、很宝贵的东西。如果没有规范，大家在十字路口就会不断地撞车。好不容易有了规范，就应该谢天谢地，十分珍惜。而如果拿规范当儿戏，这是什么样的心态啊？想撞车的心态？

无论是公开的、未公开的，或者是 “事实工业标准”，无一例外，都是要填写 BPB 表。难道填写一个默认的 S=63，H=255，C=1024 就那么难吗？可是，Linux 工具软件的作者，竟然都敢胡来！我不相信他们不了解规范。他写软件的时候，规范就在他眼前，否则，他根本就写不出软件；他是参照规范来写他的软件的。我一个白脖子都能知道规范，他是专业的，却不知道！这可能性很小很小。可能性大的，是他根本就不想遵守规范，或者说，故意破坏规范、故意添乱、故意制造撞车事件！他是咋想的，只有他自己知道，我又不能钻到他脑子里，看看他是咋想的。如果到处都出现这种 “幺蛾子”，在 “自由万岁” 掩盖之下的各种毫无价值的 “折腾”，各位大人，您说这 Linux 它能普及开吗？

也许，别的软件不受影响。但 grub4dos 受影响。因为 grub4dos 把 BPB 当成 “指纹” 来看待。有了指纹，就能更加可信、可靠地确认，“这确实是一个正常的文件系统”！如果没有指纹，那么你知道这究竟是乱七八糟的数据呢，还是一个完整的文件系统卷？我相信，就算是微软，它也会赞成、支持 grub4dos 的严谨做法。

不点

2011yaya2007777 发表于 2024-3-17 20:28
前段时间，一个老外反馈，不能挂载NTFS分区。分区在500Gb左右。他是使用linux工具格式化的。查启动分区的BP ...

今天又想到了一点，再发表一下。

如果站在 grub4dos 的开发者的立场上看问题，就可能有这样的想法：我们是参照业界规范，在认认真真、正儿八经开发软件。我们应该伺候好谁？当然 “谁最牛B，我们就伺候好谁”。现在仍然是微软的天下，微软是一手遮天。所以，我们应该伺候好微软。至于说别的，比如 Linux 系统（的工具），你 Linux 又没有 “话语权”，我何必在乎你？你不主动兼容别人，你不努力寻求最大的兼容性，反而故意制造兼容性障碍，在本来没事的地方，制造出个事！说句不太好听的话：你都不是老大，还想冒充老大，企图让别人被迫屈从你？拉倒吧。你是老大的身份，我就千方百计伺候好你。你不是老大，我没必要费劲去伺候你。等你哪天摇身一变，变成老大了，我那时候再开始伺候你也不迟。

不点

正常的思路，应该是：看微软怎么做，我也照葫芦画瓢，模仿着做。你 Linux 的工具却不鸟微软，你要来 hack 微软，你这是在 “走钢丝”，你在边缘地带进行 “试探”。这种开发思路，跟 grub4dos 的开发理念完全不同。两种开发的哲学不同，那怎么办？大路朝天，各走一边。各走各的，谁也不碍谁的事。我们没必要伺候它。它也没有义务来伺候我们。它不是老大，我们也不是老大。我们自己肯定不是老大，我们只是孙子。我们不要求别人封我们为老大——“老大” 这个身份，也不是谁想要就能要得到的。我们虽然只是孙子，但我们要伺候谁，也不是随随便便的。你不是那个身份，我还不一定伺候你。你可以自己封自己为老大，这我管不了。但我有权不承认你的老大身份，我有权不伺候你，这个主动权，在我手上掌握着。

不点

我肯定欢迎 Linuxer 来使用 grub4dos。但是，grub4dos 在 Linux 世界里的状况，我也是看得清楚，差不多算是无人问津。问题的报告者能够使用 grub4dos，那其实是很难得的。既然问题出现了，那么，谁是问题的制造者？我们作为开发者，问心无愧，如果有 bug，肯定要全力修复。但没有发现 bug，修复啥？另一方，Linux 工具的开发者，他也有他的哲学理念。在他的理念之下，很可能他也觉得没有 bug。所以，双方都不用修复 bug。这就回到了上一帖所说的 “大路朝天，各走一边”。最终是哲学决定着一切，而不是技术。技术不难，但哲学很难。不同的哲学，很难融合。


为什么说很难融合？举例来说，人家就承认是在 hack，并且，人家发现，hack 的结果是，那些 CHS 数据可以清零，不影响 mount。他根据这个结果，说 “你 grub4dos 检查 CHS 是多余的举动”，因而属于 “错误” 的。你 grub4dos 进行了 “过度” 的检查，导致失败。这样，他就把错误的根源，追踪到 grub4dos 的头上了。你说真理在哪里？每个人都掌握着一个真理。不同的人掌握的真理也不同。


然而，规范中并未提到 “CHS 可以是 0”。所以，我们 “检查 CHS” 这个举动是符合规范的。S 的取值范围是 1～63，不可能为 0。H 的取值范围为 0～255，倒是有可能为 0。在规定该填写 S 的位置，如果发现是 0，那么，这肯定不符合规范。究竟我应该按照规范办事呢？还是应该按照你 hack 的结果来办事？这不就是个哲学问题吗？那我觉得，最后还是要看 “身份” 和 “话语权”。如果你有 “话语权”，你的身份特殊，那我也得迁就你。如果你的用户数量不大，比如说，占 1% 或更低，那就没必要迁就你了。


对的，标准也是可以破坏的。把旧的标准毁掉，建立一个新的标准。谁掌握着 “事实工业标准”，我们就应该服从（迁就）谁。胳膊扭不过大腿。你是大腿，我就服了你。如果你是大腿，你可以指鹿为马，我统统予以服从和迁就。

不点

2011yaya2007777 发表于 2024-3-17 20:28
前段时间，一个老外反馈，不能挂载NTFS分区。分区在500Gb左右。他是使用linux工具格式化的。查启动分区的BP ...

今天又有一点思考，分享一下。

Linux 的世界，不同于微软。Linux 在启动之后，立即转入保护模式，不在实模式停留片刻。也就是说，Linux 不使用 BIOS。这是从 Linux 开发之初就实施的，一直延续下来，都是如此。那么这样一来，Linux 相关工具的开发者，就自然而然地认为，CHS 等参数毫无意义。加之后来，LBA 寻址模式出现以后，CHS 越来越不重要了。而在 UEFI 的新时代，整个旧的 BIOS（包括 chs 和 lba）都过时了、失效了。

再说说微软。直到 UEFI 开始实施之前，DOS 还是可以支持的。所以，CHS 这种参数，尽管用处不大，但还是保留了。即便是一个 “非启动” 的分区，其 BPB 中的 CHS 参数也是存在的。

而 BPB 本身就是 BIOS Parameter Block，即 “BIOS 参数块”。即便在 UEFI 时代，BIOS 已经不存在了，其 BPB 中的虚拟参数的位置也照样是保留了。这也很容易理解：尽管没有用，但你删除它能带来任何好处吗？没有任何好处。所以，不会删除。尤其是，假如某种情况需要回归到旧的 BIOS 启动，此时如果没有 CHS，则有可能带来启动失败，这对微软肯定是没好处的。

Linux 系统工具的开发者与微软的心态不一样，导致双方在 “如何对待 BPB 中的 CHS 参数” 上的做法也不同。

Linux 系统，你究竟要不要与微软共存？如果不要，那就一刀两断，各走各的路。你也不要格式化为 FAT 和 NTFS 了。你要是打算与微软共存，那你最好还是按照微软的规范来好好编写你的工具。你不可以取代微软，另立一个新的标准。

不点

今天再向各位达贵汇报一下个人一管所见。

Linux 内核、Linux 的启动工具（grub 和 lilo 等）、linux 的格式化工具，三者的开发是割裂的。内核开发只管内核，启动工具的开发只管启动，分区工具只管分区，格式化工具只管格式化。几张皮，没人进行整合，给出可靠解决方案。按理说，发行版制作者应该给出整合。但发行版厂家往往不作为，甚至是 “负” 作为——专门制造麻烦的——添加一些不兼容因素让别的发行版不能工作。操作系统之上的 “应用程序”，当然是可以 “百花齐放”，但是，“启动”、“分区”、“格式化”，这些东西是 “基本层面” 的，理应是内核开发不可缺少的关键组件。应该由内核开发者进行统一安排、统一实施。在没有统一实施的情况下，如果各自的开发者都很有责任感，启动、分区、格式化，如果这些开发者都明白自己是在开发 “内核” （或者说是与内核密切相关的核心工具！），而不是 “内核之外的普通工具”，那也行。但实际情况是，内核开发十分严谨、认真，但启动、分区、格式化工具的开发吊儿郎当。在 BIOS 时代，你一个 ext2 分区，在 super block（引导扇区中）总得有个 BPB 表吧？微软都定义了 BPB，你为什么不定义呢？哦，现在是 UEFI 了，正好 BIOS 被废弃了，你确实赢了。但我讲的是个道理，不是赢和输的问题。在 BIOS 时代，你脱离业界标准，或者说你鄙视业界标准。这样做能带来好处吗？你这么做，是能让 Linux 普及得更顺利一些呢，还是给 Linux 的普及增添了一层障碍？