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

blank007

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 分区。

不点

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 又没有 “话语权”，我何必在乎你？你不主动兼容别人，你不努力寻求最大的兼容性，反而故意制造兼容性障碍，在本来没事的地方，制造出个事！说句不太好听的话：你都不是老大，还想冒充老大，企图让别人被迫屈从你？拉倒吧。你是老大的身份，我就千方百计伺候好你。你不是老大，我没必要费劲去伺候你。等你哪天摇身一变，变成老大了，我那时候再开始伺候你也不迟。

2011yaya2007777

言之有理

不点

正常的思路，应该是：看微软怎么做，我也照葫芦画瓢，模仿着做。你 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% 或更低，那就没必要迁就你了。


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

tanchenglong

卤煮好厉害，支持楼主分享O(∩_∩)O~

blank007

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


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


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


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

多谢各位指点。

chen463

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，兼容性好一点

blank007

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

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

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

感谢指点

不点

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 的普及增添了一层障碍？

wuwuzz

偶然路过这里，有感而发，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

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

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

多谢指点

szwp

用hp的格式化工具也不正常的话就需要去修了

wuwuzz

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

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

不一定需要修。

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

freesoft00

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

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

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

wuwuzz

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环境下积累的宝贵资源】

qhb

赞赞