bios识别u盘为usb-zip模式之后就不认u盘普通分区了 这是g4d的bug吗？

不点

你能确认你的 fd0 上有分区表吗？

cat   --hex   (fd0)+1

看看有没有分区表。

然后再试试

ls (fd0,0)/
ls (fd0,1)/
ls (fd0,2)/
ls (fd0,3)/
ls (fd0,4)/
ls (fd0,5)/
ls (fd0,6)/

以及

geometry (fd0)

看看这些命令能否列出你的可见分区？

不点

求道者 发表于 2016-11-24 12:27
不点大师...............
就像1L那个 U盘我量产成了一个USB-HDD和一个USB-CDROM
grub4dos下只能看见（f ...

当你从 usb-hdd 或 usb-fdd 启动的时候，主板把 usb-cdrom 屏蔽掉了。所以没什么有效的办法。

假如主板不屏蔽 usb-cdrom 就好了，可是，好像大多数主板都会屏蔽的。

不点

求道者 发表于 2016-11-24 17:24
只能usb-hdd和usb-cdrom 都放一份PE了...............
如果不屏蔽就方便很多.................

别太认真，太认真你就失败了。世上没有完美的东西。不要忘了，主板厂商可是在有意识地封杀、淘汰 bios。

所以，完全没有必要太认真。凑合着用一天是一天。

不点

求道者 发表于 2016-11-24 19:04
还真是一部分老电脑能在CDROM的情况下让U盘里的东西也能访问
说起来这图里的usb --init之后的ls (cd)/报 ...

你这个经验很好，能遇到这些情况，增长了见识。

还是那句话，不要太认真，尤其是在 bios 正在被淘汰的情况下；一切都属于正常现象。

当你从 cdrom 启动时，如果能访问 hdd 或 fdd 的内容，这是正常现象；如果不能访问 hdd 和 fdd 的内容，这同样也是正常现象。为什么说是 “正常” 呢？因为以普通老百姓的能力，是改变不了这一切的。主板制造商制造成啥样，它就是啥样。只要主板制造商自己不该变它，别人就很难改变它。

同理，当你从 hdd 或 fdd 启动时，如果你有幸能访问 cdrom 的内容，这属于正常现象；如果不能访问 cdrom 的内容，也照样属于正常现象。这是制造商的权力，用户没有话语权，用户改变不了。

看淡它，不要太认真。太认真了就属于 “较真”，会有很大的失落感，不划算。

而 usb --init 是 grub4dos 开发者开发出来的命令，因此，还真有希望修复 bug，让它继续能够访问 (cd)。不过，技术上是否有障碍，还不好说，这得让开发者去实践一下才知道（如果开发者有时间、有精力、有能力、有兴趣的话）。

不点

求道者 发表于 2016-11-26 21:48
不点大师啊...........
由于UEFI只认fat32分区 所以现在我把PE的iso解包了丢到fat32分区
现在勉强能让u ...

很抱歉，我对于 EFI 没有什么了解。

从你描述的情况来看，我觉得是 usb --init （在这台机器上）与你的 bootmgr 和 wim 不兼容。

也有可能是 usb --init 失败了，或者虽然没有失败，但对硬件造成了影响，进而影响到 ROM BIOS，使 ROM BIOS 不能工作。

不知道我这样理解是否正确。

不点

求道者 发表于 2016-11-27 11:14
我觉得是死**bootmgr的问题……这就逼玩意事多
上次在一个gpt硬盘上安装了grub4DOS用他引导bootmgr然后 ...

从你说的这段话，我感觉终于有点明白你的具体使用场景了。

bootmgr 是闭源软件，外界对它进行破解，都不那么容易。bootmgr 的应用环境本来就是受限的。有些场合可以用，有些场合用不成。

不要以为 bootmgr 是 grldr，可以随便折腾。

我猜可能是你 “超限” 使用了 bootmgr，就是说，你在那些它不支持的场合使用了它。或者理解为，你没有把它 “破解” 好。

假如这个 U 盘上的 grldr 或者别的文件（比如 ISO 或 IMG）都能够使用 BIOS 正常加载（加载到 100% 完成），那就说明 BIOS 本身没问题。

如果你发现问题仅仅出现在使用了 usb --init 的情况，那就可以确定是 usb --init 与机器的硬件不兼容。那么，这样也就不属于 bootmgr 的问题了，不要责怪 bootmgr 了。

就是说，出了问题，首先要判断问题的根源，判断出大致的范围、症结，找到究竟是哪方面的因素引起的。这并不容易，有时候会弄错。

不点

我觉得，不要期望太高。grub2 的开发者没把 BIOS 当成重点，不能指望他们开发磁盘仿真模块。磁盘仿真也仅仅用于 BIOS 启动方式罢了。EFI 启动方式的玩法彻底变了，不能再用 “磁盘仿真” 的思维模式了。在 EFI 下，就应该遵守 EFI 的游戏规则。我似乎觉得 0pe 就可以兼顾 BIOS 和 EFI 两种启动方式。其实 EFI 下不存在启动障碍，各种 “不顺利” 都是在 BIOS 下发生的。0pe 主要就是照顾到了 BIOS 的情况。EFI 下不需要照顾，因为 EFI 下启动成功率是 100%（至少目前是这样的，以后如果 EFI 被封杀，另当别论）。

不点

求道者 发表于 2016-11-27 12:48
找到了！
UEFI下能磁盘仿真的启动器！
在本坛找到的 XORBOOT！

好，强！找到就好。

不点

求道者 发表于 2016-11-27 19:16
不点大师........
基本扇区数是不是已经不推荐设置了？
用读扇区速度替代吗？

很抱歉，我对于 ud 的格式化界面，并不特别了解。一来这是 bean 开发的，我没有深入研究过。二来即便有些软件是我开发的，时间一长我都可能记不住了。

不过，我仍可以谈谈自己的看法。我认为 ud 的目的是提高 BIOS 启动成功率。这是它的唯一目的。我发现我们当中有很多人理解得不对（所谓 “不对” 就是说依我看是不对的）。我认为 ud 就是提高启动成功率。而我们有些人把它的隐藏特性过分强调了。bean 开发 ud 的目的，我认为是与隐藏特性八杆子打不着的。

同样的，ud 文件系统能否被操作系统识别，也不是考虑的重点。我认为，根本没有必要把 iso 之类的大文件放在 ud 里面。那些大文件，完全可以放在 FAT 或 NTFS 里面。

有那么多的年轻人热衷于 ud 的隐藏特性，以至于把很多东西都塞进 ud 里面。我年岁大了，跟不上形势，理解不了年轻人的想法。我认为这样的年轻人很偏执，而年轻人很可能认为我顽固不化。当然了，互不干涉，真理也是多元化的。

假如大家不把 Windows 的文件放在 ud 里面（只把 grldr、menu.lst 放在 ud 里面），那就不存在 “操作系统识别不到文件” 的问题了。

不点

没必要纠结某个软件有多高的启动成功率，尤其是在 BIOS 已经被冷落、淘汰的情况下。

失败的案例总会有的。我的粗浅理解：当初微软不想让 U 盘能够启动系统，所以才让 U 盘启动乱七八糟。你根本就不可能找到一个 “万全” 的启动代码，那是因为垄断控制者的控制使然。随着时间的推移，U 盘启动成为必不可少的了，此时，再封杀已经是不可行了。在这样的状况下，才有了移动版的 Windows，也才正式支持 U 盘启动（不过已经是伴随着 EFI 的强制推行而且以制造不兼容性和淘汰旧系统为目的了）。

我发表这个见解，是想给需要的人提供帮助。如果有人觉得我这个见解很浅薄，没有用处，那就罢了，我帮不上忙了。不过我认为我不是损人利己的；我是好意。

就是说，不要纠结了，到此为止。该是啥样，就是啥样。努力和效果应该成正比才对。如果费的劲不小，收效却甚微，那我就觉得不值。

不点

求道者 发表于 2016-11-28 15:17
那不点大师岂不是要放弃MultiMBR 的开发？

闹着玩的，不算是开发。multimbr，其实我都没想好叫什么名，只是用了一个临时的名字而已。用的人也很少。

今年国庆期间，（与上次更新相比）我更新了啥？核心汇编语言代码连一个字节都没变。变的是啥？是操作界面。

我把汇编语言代码的编译过程，“整” 到网页的 JavaScript 里面了。就是说，只用浏览器就可以进行编译了，不需要 Linux 环境，也不需要 bash、gcc、 gas。

与其说是在改进 multimbr，不如说是在练习 JavaScript 编程技术。

不点

求道者 发表于 2016-12-3 09:44
不点大师啊
有UEFI BIOS源码可看啊
这是夙愿达成

很抱歉，我没那么激动。没听说制造商放出源码。不是人家主动放出的源码，我不看它。主动放出了，我也不看，已经过了 “兴趣期” 了。

wuwuzz 说，他不使用 fbinst，他说只需选择某个主控的 U 盘，再进行 “改造” 就可以 “通吃” 所有的 BIOS 了。我不知道是否曲解了 wuwuzz 的原意。有人愿意当小白鼠来验证一下吗？条条道路通罗马，只要找到一个办法能做到 100% 启动，那就行啊！那我们以后无非就是只买某个主控的 U 盘即可（只要它不是贵得 “买不起” 就行）。

不过说实在话，现在太晚了，我估计很难找到许多小白鼠来测试了。原因很简单，bios 已经夕阳西下了，感兴趣的人（或者说对 bios 有激情的人）也不多了。就是说，wuwuzz 的想法，不管是正确不正确、可行不可行，都难以得到验证。

当初 bean 开发 fbinst 的时候，测试者可用 “人山人海” 来形容（当时我身体最糟糕，未能参与测试，更未提供帮助，只是偶尔上网关注了一下）。可是，几年后轮到我开发 multimbr 的时候，情况就惨了，参与测试者只有 5 个人。multimbr 开发完成后，我粗略统计了一下使用者人数，在 20 人左右。就是总共的使用者就这么多。那 100 个点击下载的总数，都是这 20 人反复多次点击下载的结果。当然这原因可能很多，不排除我这软件 “质量低劣” 的可能性，从而导致无人感兴趣。但是我认为，更可能的情况就是，大家对 bios 层面的东西已经失去 “耐心” 和 “热情” 了，或者说已经 “淡漠” 了、“冷酷” 了。还有一个佐证，syslinux 也停止开发了。甚至 grub2 也处于 “不活跃” 和 “停顿” 状态。不过，这两个佐证可就不仅仅是说 BIOS 夕阳西下了，而是说就连 x86 这个总的 “摊子” 都要 “收” 了（因为这两者都支持 EFI）。话不能说那么绝对（真理是相对的），前些天还从你的帖子里了解到 XORBOOT 支持 EFI 下的磁盘仿真，这真是强啊！竟然比 grub2 的开发团队还厉害！

不点

wuwuzz 发表于 2016-12-3 13:54
一、LZ应继续配合yaya测试新版grldr；

二、我正想说这事呢，LZ手快，已经做了测试。

任重而道远。

假如你想把这个工作做好的话，我觉得你需要这么做：

1、告诉大家买什么牌子的 U 盘，比如给出淘宝链接，让傻瓜都不会买错。
2、告诉大家用什么工具 “修理” 这个 U 盘，让傻瓜都会修理。必要时写个 “修理” 教程。
3、制作一个现成的 IMG 让大家 “刷写” 到 U 盘上，让傻瓜都能直接进行启动测试。

即使这样做了，都不一定有多少人愿意参与测试。但如果连这都不做，那我认为根本就没希望。

不点

求道者 发表于 2016-12-3 14:32
所以vid修改是规避了BIOS的特殊处理？
并不是根本上解决了慧荣固件的bug？

wuwuzz 没说 fbinst 不好。他的意思是说，只要按照他的办法搞，就不需要动用 fbinst 技术了。

实践是检验真理的标准。等 wuwuzz 给个普及化的方案（或者一体化、一条龙的刷写软件），让更多的人大面积测试一下，就知道结果了。尤其是让那些 “用 fbinst 启动失败” 的人测试，如果确实能成功，那就更有说服力了。

不点

wuwuzz 已经差不多说明白了，剩下的就听天由命了——我这么理解，对吧？就是说，今后要看究竟有多少人愿意去 “身体力行” 了。只有 “参与实践” 的人多了，才会有个结果，否则还是停留在纸上，仍是得不到验证，仍是 “悬而未决”。最好是让那些碰巧遇到 fbinst 失败的朋友去测试，那样才有说服力。如果我的预感正确的话，我猜这个问题八成也会是 “悬而未决” 的命——大家都懒了，关心它的人越来越少了。

不点

wuwuzz 发表于 2016-12-4 08:22
大致明白不点的想法了。是想用我这种方法测试那些古怪的BIOS
（尤其是fbinst失败的环境），检验有效性?
...

绝对有必要。最好是 “一条龙” 服务，做到家。——买盘，修理，格式化，连贯起来一条龙，傻瓜操作。

1、你这 U 盘是在哪买的，你就让用户也买这个就行，不复杂。【如果有很多卖家，很多款式，你可以推荐多款。】主要是为了方便那些根本不知道技术细节（主控芯片等）的傻瓜用户；做到贴心。

2、最好是写个软件，直接集成 “修理” 和 “格式化为 FAT （内含 DOS）” 这两个步骤，无需用户再去折腾。

3、用户插在电脑上就可测试。

fbinst 和 multimbr 都曾有失败报告。请那些失败的人进行测试。进入 DOS 就是成功，无需再进入 grub.exe。因为 grub.exe 是在 DOS 下运行，受到 DOS 污染的中断向量表有可能让 grub.exe 失败死机。所以为了确定起见，没必要进入 grub.exe。

很遗憾，fbinst 和 multimbr 在我这里都是 100% 成功，因此我无法用实践来验证你的技术是否有突破。

先要让测试者确定 fbinst 和 multimbr 都是失败的，然后再测试才有意义。

你自己就可以另外开辟一个测试专帖，讲明情况，让大家测试。其实谁都可以测试，不管以前有没有遇到失败。重点是让那些曾经遇到启动失败的人来测试。

不点

BIOS 非常混乱，大多数 BIOS 在以 “磁盘” 方式启动时（包括 FDD、ZIP、HDD 等），屏蔽掉 CDROM。也有不屏蔽的，那就是 QEMU 的 BIOS。老实说，我还没有发现有哪个真实机器不屏蔽 CDROM 的。但或许也存在那样的主板，它在以磁盘方式启动时能够给出 no-emulation 模式的 CDROM 接口。存在与否，我并不知道。

然而注意：为了保证 grub4dos 启动的成功率、保证启动过程中不会发生死机，启动后有意不去探测 cdrom 的 int13 接口。qemu 是例外，当 grub4dos 发现 BIOS 是 qemu 的 BIOS 时，就会探测 cdrom 接口，因为这个探测不会导致死机（已经证明过了），是安全的。其它情况下一律不探测。也就是说，即使主板 BIOS 提供了 CDROM 的 int13 接口，grub4dos 也不去碰它（万一碰死了不划算！）——这就是 grub4dos 的启动逻辑。

有没有在探测 cdrom 接口时死掉的情况？太有了！吃过亏的！！所以后来就不敢去探测了（只在 qemu 的情况才敢探测）。

好了，各位应该明白了，只要以普通磁盘方式启动，就没法了解 BIOS 是否提供了 (cd) 设备。

然而，各位可以手动试验，确定自己的主板是否提供 (cd) 设备。比如这样：

geometry (0xff)
geometry (0xfe)
geometry (0xfd)
geometry (0xfc)
.............
geometry (0x03)
geometry (0x02)
geometry (0x01)
geometry (0x00)

只要发现其中有某个设备的 sector size=2048，那它就是 cdrom 了。一旦发现它，你就可以 ls (0xNN)/ 看它的内容了。

上述的试验步骤实际上就是一个探测过程，如果死机，那也属于正常现象。

不点

find 只找 BIOS 数据区里面的 floppies、harddrives 以及 (cd) 【即 no-emulation 模式的 cdrom（当然是以 cdrom 方式启动才有的）】，不找别的盘。因此，yaya 需要修改 find 命令，让它寻找 usb --init 驱动出来的 cdrom。