无忧启动论坛

标题: Grub4DOS 在 64GB 优盘（FAT32格式）下的使用体验及期望解决的问题 [打印本页]

作者: blank007 时间: 2024-3-14 17:02
标题: Grub4DOS 在 64GB 优盘（FAT32格式）下的使用体验及期望解决的问题
本帖最后由 blank007 于 2024-3-16 09:04 编辑

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

      之前用的都是 <= 32GB  的优盘，通过 UltraISO 写入 USB-Zip + V2 ，并在分区中安装 Grub4DOS （G4D/G4E 同时安装，优盘是单分区），grldr 、bootia32.efi、bootx64.efi 优先拷贝到优盘最开始的位置。
      启动、使用均正常。

      刚刚入手一部爱国者优盘，容量 64GB。依然使用 UltraISO 写入 USB-Zip + V2 （依然是FAT32格式），并在分区中安装 Grub4DOS （G4D/G4E 同时安装，优盘是单分区），grldr 、bootia32.efi、bootx64.efi 优先拷贝到优盘最开始的位置。

      发现：

      Grub4DOS 能正常启动，但进不了菜单，只能进入命令行。运行 root 命令，提示无法 mount 该分区。后面的操作自然无法进行。

      请问各位大侠：

      这是 BIOS 在限制，还是 Grub4DOS 暂时没有考虑这样的情况？

      补充：

      HPUSBFW.exe  也可以将这个 64GB 的优盘格式化为 FAT32 格式。

作者: yyz2191958 时间: 2024-3-14 18:00
我不晓得帮顶

作者: 2010XwX 时间: 2024-3-14 18:07
我采用 UD 三分区的方法，在 128G U盘采用 G4D 和 G4E 双启动没问题。前部 UD 区12M，G4D BIOS 启动。尾部隐藏区2G，FAT32，G4E UEFI 启动。

作者: 481416322 时间: 2024-3-14 18:25
如果你第一启动是g4d，那就结合clover来查看整个优盘

作者: yuguotqing 时间: 2024-3-14 18:38
帮你顶

作者: dayeye 时间: 2024-3-14 19:17
果然是“爱国者”优盘。都用国产程序的估计就行了。

作者: oh312 时间: 2024-3-15 05:21
学习一下

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

作者: tanchenglong 时间: 2024-3-15 08:18
我只是挽尊的，楼主辛苦了

作者: softwarezheng 时间: 2024-3-15 09:16
谢谢

作者: 不点 时间: 2024-3-15 16:00
提供的信息不多，不足以确定问题的根源。根据已经提供的描述，我觉得，可能性较大的，是 ultraISO 的问题。

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

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

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

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

作者: 不点 时间: 2024-3-16 04:51

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 的分区放在优盘尾部。

作者: 不点 时间: 2024-3-16 05:38
再次回复一下楼主。

我从闪迪旗舰店购买的 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，反正第一句是不能正常执行的。它会从菜单之后的某个字节处开始执行。我们刚才做的，无非是想要保证：第二句能够正常执行。

作者: 不点 时间: 2024-3-16 06:55
刚才说了，用 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

听不点大佬娓娓道来，收获颇多

作者: 不点 时间: 2024-3-16 07:27

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

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

作者: blank007 时间: 2024-3-16 08:54
本帖最后由 blank007 于 2024-3-16 09:02 编辑

不点发表于 2024-3-16 06:55
刚才说了，用 BootICE 把 grub4dos 安装在 PBR 以后，启动失败，又安装 wee 到 MBR 才成功。这也挺麻烦的， ...

多谢不点大侠的指点

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

      首先，使用 Diskgen 将启动模式转换为 HDD 模式，MBR 为 WinNT 6.x ，将 G4D 安装在 PBR。后面的操作和前面一样，启动、使用正常了。(usb-zip ，usb-fdd 模式下没有盘符，故没有继续操作)

      因为偏爱 USB-ZIP + v2 启动，故采用 Bootice 对其重新分区，选择 U+ v2 模式，不隐藏，主引导记录自然也是USB-ZIP + v2，G4D 也是安装到 PBR 。启动、使用也正常了。

初步结论：

      1、UltraISO 对 <=32GB 的优盘处理得很好，对 >32GB 的处理可能没有考虑

      2、Bootice  只有 USB HDD+ v2、USB ZIP+ v2 可选

另外一个疑虑：

      曾经，用 UltraISO/BootICE 对某个优盘操作时，强制使用 USB-ZIP + v2 模式后，那个优盘物理损坏了。不知道是不是巧合。

补充：

   之前没有明说是g4d还是g4e ，是因为表现都一样。现在，也是表现都一样：都能正常启动、使用了

作者: szwp 时间: 2024-3-16 09:58
HPUSBFW格成dos再启动grub.exe试

作者: ningzhonghui 时间: 2024-3-16 10:28

不点发表于 2024-3-16 05:38
再次回复一下楼主。

我从闪迪旗舰店购买的 500G 优盘（实际容量约 460G），制作 grub4dos 启动盘。以下 ...

谢谢不点老师的详细讲解，所说的那个wee 有时是有这情况发生，也不知原来是个BUG 有幸看到你讲解，我也把我的修得下菜单才行.

作者: 不点 时间: 2024-3-16 10:36

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

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

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

作者: 不点 时间: 2024-3-16 11:31

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 也就被认为是 “没有污染中断向量表” 了。

作者: szwp 时间: 2024-3-16 15:21

不点发表于 2024-3-16 11:31
这也是个思路。如果 DOS 能够启动，那就说明，FAT32 的分区是正常的，是可以 mount 的。假如说，进入 gru ...

只使用g4d的可以考虑写入grldr.mbr或整个grldr就不需要考虑分区激活了

作者: 不点 时间: 2024-3-17 09:07
我今天再次进入这个话题，提出一个问题，供各位大人以及开发者们思考。

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

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

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

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

作者: szwp 时间: 2024-3-17 09:36
期望谁去解决呢？按分区id判断简单，但可能会遇上故意设置特殊id的

作者: blank007 时间: 2024-3-17 12:01

不点发表于 2024-3-17 09:07
我今天再次进入这个话题，提出一个问题，供各位大人以及开发者们思考。

我注意到，楼主的 64G 的 FAT32 ...

楼上有朋友说FAT32存在2种寻址方式。估计 GRUB4DOS 与 Bootice 的寻址方式一致， UltraISO 对 >=32GB 的 FAT32 应该用的是另外一种寻址方式。

另外，我也觉得这情况值得继续研究：大容量的优盘会越来越多，UEFI 的 ESP 可能在一段比较长的时间内继续以 FAT32 为标准，故移动硬盘、优盘启动计算机时，恐怕还得考虑这个情况。

作者: 不点 时间: 2024-3-17 18:51

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，作为技术问题可以探讨。如果楼主不嫌麻烦的话。

作者: aigpt 时间: 2024-3-17 19:04
不错

作者: 不点 时间: 2024-3-17 19:27

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

yaya 来了，好。

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

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

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

作者: 不点 时间: 2024-3-17 19:54
我再说第三点看法。

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

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

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

作者: 2011yaya2007777 时间: 2024-3-17 20:28
前段时间，一个老外反馈，不能挂载NTFS分区。分区在500Gb左右。他是使用linux工具格式化的。查启动分区的BPB表，结果每磁道扇区数、磁头数、隐藏扇区数都为零。grub挂载时需要检查这里（尽管这几个参数直接启动时需要，而挂载则不是必要的），因此失败。

作者: blank007 时间: 2024-3-17 23:30
本帖最后由 blank007 于 2024-3-17 23:32 编辑

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

这个现象可以重现。

不过，先说另外一个操作：

找到了一个240GB的固态硬盘，使用 UltraISO 写入 USB-ZIP + V2 （fat32格式)后。安装 grub4dos。结果， G4D/G4E 都是正常的、可以启动、使用。（安装g4d到 pbr 时，grubinst 1.4 显示是 fa32(x) 格式，不是常显示的 fat32 格式。）。bootice 下，它被显示为硬盘，不能像优盘一样进行 u+ v2 分区。

作者: 不点 时间: 2024-3-18 05:59

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 的严谨做法。

作者: softwarezheng 时间: 2024-3-18 10:32
谢谢

作者: 不点 时间: 2024-3-19 10:39

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

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

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

作者: 2011yaya2007777 时间: 2024-3-19 10:49
言之有理

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

作者: 不点 时间: 2024-3-19 12:44
本帖最后由不点于 2024-3-19 16:22 编辑

我肯定欢迎 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% 或更低，那就没必要迁就你了。

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

作者: tanchenglong 时间: 2024-3-19 13:44
卤煮好厉害，支持楼主分享O(∩_∩)O~

作者: blank007 时间: 2024-3-19 14:17
本帖最后由 blank007 于 2024-3-19 14:20 编辑

再次向各位大侠汇报一个试验：

依然采用 UltraISO 对这个64GB的优盘做了 USB-ZIP+ V2 的写入，然后安装了 XorBoot 的 BIOS/UEFI 两个版本，结果发现：
xorboot 的启动、使用均正常。

所以，现在就有些糊涂了。

当然，有了折中方案，遇到的这个现象请慢慢研究。

多谢各位指点。

作者: chen463 时间: 2024-3-19 15:02
本帖最后由 chen463 于 2024-3-19 15:44 编辑

blank007 发表于 2024-3-19 14:17
再次向各位大侠汇报一个试验：

采用 UltraISO-USB-Zip + V2做了深度隐藏，引导是在最前面深度隐藏区里面，似同UD深度隐藏一样，必须使用第三方软件开启前面深度隐藏区去修改里面主引导MBR-，不是从其他分区引导中去安装引导PBR- grldr。

尤其使用UltraISO来安装深度隐藏版本，跟新版本grub4dos兼容性差，如您使用UD来制作，相信这问题出现的机率极低。这现象已存在多年了。

您制作UltraISO-USB-Zip+ V2是双分区-一个前面深度隐藏区+后面显见的单FAT32分区。不是单一分区FAT32分区

+V2就等于是制作前面深度隐藏区似同UD深度隐藏一样

坚持的话，建议使用UltraISO-USB-HDD + V2，兼容性好一点

2024-03-19_151251.png (23.28 KB, 下载次数: 17)

2024-03-19_2.png (13.94 KB, 下载次数: 17)

作者: blank007 时间: 2024-3-19 17:20

chen463 发表于 2024-3-19 15:02
采用 UltraISO-USB-Zip + V2做了深度隐藏，引导是在最前面深度隐藏区里面，似同UD深度隐藏一样，必须使用 ...

我的优盘向来都是单分区的，并且不隐藏。

难道 UltraISO 的 USB-ZIP+ V2 实际上是双分区或者多分区？

感谢指点

作者: 不点 时间: 2024-3-20 05:59
本帖最后由不点于 2024-3-20 09:18 编辑

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 了。你要是打算与微软共存，那你最好还是按照微软的规范来好好编写你的工具。你不可以取代微软，另立一个新的标准。

作者: 不点 时间: 2024-3-24 09:00
今天再向各位达贵汇报一下个人一管所见。

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

作者: wuwuzz 时间: 2024-3-29 16:27
本帖最后由 wuwuzz 于 2024-3-29 16:41 编辑

偶然路过这里，有感而发，LZ问题虽解决，但后续没完，我还是想延申一下。

一、问题本身是Ultraiso自定义格式(也就是所谓的U+)引起的(参见11、17、41楼信息)，出现这种结果我不感到意外。我困惑的是，UD、U+..是在早期不清楚BIOS USB启动机制时产生的。时至今日，由于多个版本的UEFI/BIOS源码流出，我们对UEFI/BIOS内部情况的认识早已今非昔比，为什么还要用UD、U+..这些(图增复杂性)的东西。

早在200X年左右，我就放弃使用“通过在MBR/PBR上做文章，试图影响BIOS启动行为”的软件，原因很简单，通过学习知道，BIOS最关心的是U盘固件参数(少了它们,BIOS无法驱动、无法正确引导U盘)，而不是MBR/PBR这些。只要把U盘固件参数搞好，啥复杂引导格式都不用，就用最原始的MBR(DOS)就可以了。

二、我极其反对DG、UltraISO等启动盘制作软件“滥用”USB-HDD、USB-ZIP、USB-FDD这些名词，因为它严重误导使用者。

USB启动规范本身，只有粗线条的规定，要么磁盘(DISK)启动，要么光驱（CD/DVD）启动。USB-HDD、USB-ZIP、USB-FDD是BIOS对DISK扩展细化出来的“非标准”内容。不同的BIOS厂家判定算法各不相同，U盘被BIOS判定为USB-HDD还是USB-ZIP、USB-FDD等，核心决定因素还是U盘固件参数---比如，U盘固件报告的“总扇区数(最大LBA)”就是重要参数之一。

“Diskgen 将启动模式转换为 HDD 模式”----DG这种说法严重扯淡，不是它想转就能转的，只有BIOS算法才能决定USB-HDD、USB-ZIP、USB-FDD。当然，我们通过调整U盘固件参数，就能欺骗、利用BIOS算法，达到我们想要的HDD或ZIP或FDD--这才是顺应BIOS的正确解法。

三、不点关于LBA/CHS/BPB的许多观点是正确的，我补充的内容是：
U盘物理上没有CHS，内部固件也只使用LBA(其他USB存储设备也都这样)。但是，由于历史的原因，UEFI CSM或BIOS，需要CHS这种访问方式。U盘没有CHS，UEFI CSM或BIOS也要为它伪造(计算)一个。不同的UEFI CSM/BIOS厂家，计算方法不同。在PC上电、U盘枚举(也就是UEFI/BIOS驱动U盘)时，这个CHS计算过程就开始了。换句话说，不管G4d、wee等引导软件将来用不用CHS，UEFI CSM或BIOS都要为U盘计算设定CHS，这个过程不以用户意志转移，不以g4d、wee的意志为转移。

作者: blank007 时间: 2024-3-30 09:25

wuwuzz 发表于 2024-3-29 16:27
偶然路过这里，有感而发，LZ问题虽解决，但后续没完，我还是想延申一下。

一、问题本身是Ultraiso自定义 ...

多谢指点

作者: szwp 时间: 2024-3-30 09:38
用hp的格式化工具也不正常的话就需要去修了

作者: wuwuzz 时间: 2024-3-30 17:58
本帖最后由 wuwuzz 于 2024-3-30 18:02 编辑

blank007 发表于 2024-3-30 09:25
多谢指点

我这里再对45楼第2段内容进行补充。

一、不仅DG、UltraISO等软件在滥用USB-HDD/ZIP/FDD...名词，U盘主控固件厂商的量产工具
也起到很坏的推波助澜作用(参考图一)，导致误导越来越严重、水越搅越混。到最后从网上
搜来的东西，混淆是非的谬误广泛流传。

二、当理解、掌握了BIOS算法后，才能真正人为实现想要的HDD、ZIP结果。
下图就是在Phoenix BIOS下，我用1支SMI 3267AE主控/128G优盘，有目的地
制作出USB-HDD、USB-ZIP、USB-CDROM。当然，USB-FDD、USB-LS120，我也能
制作出来。只是按Phoenix BIOS算法，它们与前述设备类型冲突，不能在
同一支U盘上实现，需要用第2支U盘单独制作。

作者: wuwuzz 时间: 2024-3-30 18:17

szwp 发表于 2024-3-30 09:38
用hp的格式化工具也不正常的话就需要去修了

不一定需要修。

HP格式化工具在win下，有时会出现设备写保护误报。
此时，可能是win设备利用冲突，需要换其他方式制作启动盘。

作者: freesoft00 时间: 2024-4-8 08:33

wuwuzz 发表于 2024-3-29 16:27
偶然路过这里，有感而发，LZ问题虽解决，但后续没完，我还是想延申一下。

一、问题本身是Ultraiso自定义 ...

有部分dell或者hp的品牌机，使用ud做的U盘无法启动，使用微软的引导可以。这个分析过没有

作者: wuwuzz 时间: 2024-4-8 11:30

freesoft00 发表于 2024-4-8 08:33
有部分dell或者hp的品牌机，使用ud做的U盘无法启动，使用微软的引导可以。这个分析过没有

一、UD早期开发、流行的时候，我对周围Dell、hp品牌机做过测试，样本量比较小，偶尔遇到过启动异常现象(印象中，HP机是复制BPB解决、DELL机是调整U盘固件CHS参数解决)，但那时的理论认识不清、硬件测试手段也不行。现在的情形正相反，理论认识、测试手段都提高了，但测试对象没了(身边DELL、HP机已被淘汰了)。

二、没有DELL、HP机也没什么，我在ventoy区曾发过贴“一种克制Ventoy、fbinst的buggy BIOS(http://bbs.wuyou.net/forum.php?mod=viewthread&tid=437567)”，我看层主也回了。我想，这就是个典型例子。【题外话：最近由于写论文举例测试需要，我正在想其他办法，更好地应付这个BIOS。主要任务是，在此BIOS下保留U盘上已装的Ventoy或fbinst的内容与功能。也就是向前兼容，保护Ventoy或fbinst环境下积累的宝贵资源】

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