准备基于 fbinst 进行再开发，请各位提供帮助

gsool

不点 发表于 2014-1-7 17:07
编译环境是现成的，chenall 在 google code 上的 grub4dos 项目首页，就有一个 Windows 下的 colinux 环境 ...

谢谢大师指点。我还有个问题，编译以后是Linux平台下的程序，怎么编译成Windows平台下的程序呢？

不点

编译以后生成 24M 的映像文件，直接用来写入 U 盘的。而写 U 盘的工具自己搞定，不属于这个软件的管辖范围。

zds1210

同志们，这个项目受到很多大神的关注，期待这个大工程早日成功。
还有一个问题，UD驱动是个很多的想法，为什么fbinstool的作者不尝试开发一下呢？

2010qaqz111

之前用fbinst的时候碰到个问题，也不知道是好是坏，在这里借光说说，有兴趣的童鞋可以瞧瞧看。

fbinst搞出的ud区有primary和extended的区分，其中primary类型的在物理结构上会每隔一段插入一些校验之类的信息（记得以前在论坛专门问过这个问题，好像也是不点大侠还是谁回答的，说是某种历史原因来着），这样就碰到一个问题：用PECMD或者g4d在读物理block进行copy操作的时候，会把这些校验给弄出来整到目标文件里面去，所以如果有这样需要被直接以block read的方式读取内容的文件必须手动指定放到ud的extended区域里面，这样在用fbinstool的gui操作的时候就有点麻烦，尤其是小文件很多的时候。当然好像可以也右键导入文件夹，但是总觉得不方便。

另外还有一种情形是使用 map --mem 的时候好像也不能用primary区域的文件？我记得我遇到过这个问题的，也不知道后来的g4d做出了调整没，反正我自从遇到这个问题之后放文件基本上全都是放在extended区域里面的。

关于这个问题，primary那个校验一直让人很纠结，据说是原来作者为了做数据校验或者安全方面考虑弄进去的，但是实际使用中貌似只碰到了这个东西带来的一些小麻烦，一直只用extended区域放文件也没碰到过啥问题，不知道是不是我的应用层次太浅了。

原来的fbinst规定primary部分至少8M，这样一来在primary区域没有填满的情况下，用gui向ud拖文件的时候老是会默认在primary区域，每次都要手动调整一下，虽说不是多大个事，但是在小文件很多的时候总就弄的人很纠结。

所以，想借光问问，新的fbinst是否还是打算有pri和ext的区分？前面看到大侠说是要保持兼容，所以估计这个还是会有？如果还有pri和ext的话，能否让primary的最小大小可以设置成0（我也不清楚是否有其他因素要求pri必须存在且大小至少要8M，如果有这种要求的话当然就没办法了），或者另外一种解决方案是，在新的gui里（如果有打算做新gui的话，纯命令行也就无所谓多指定一两个参数了）让用户可以选择文件拖放默认丢到ext区还是pri区？


说了这么多，其实重点就是在那个pri区的据说是校验的多出来的数据上，希望各位大侠有知道的给科普下关于这个东西，一直很纠结这个的说

mygamexxx

24M写入后，WINDOWS无法识别U盘。

用U盘启动后，进入GRLDR
find
返回
(hd0,0)
Warning! Invalid first FAT entry (=0x0)!
(hd0)
(hd1,0)
......

不点

mygamexxx，请同时给出启动时的调试输出信息。如果看不清，可长按 P 键保持暂停。

你的下载是否有错误？你是否完整下载了？解压是否正常？解压后的 24M.img 文件的长度是多大？你是如何把 24M.img 导入 U 盘的？是在什么操作系统下进行导入的？导入后又进入了什么系统？有没有可能是因为病毒写入 U 盘扇区导致 U 盘的数据被破坏？导入后，立即关机，然后开机，看看是否正常？

不点

2010qaqz111，开头的 8M 带扇区序列号，是 fbinst 的关键技术，用来突破 BIOS 的封杀的。主板 BIOS 用异常的 CHS 参数来破坏（开源软件的）启动过程。很难有更好的办法来对付，大概只有用 fbinst 的方法才有效。原来的 fbinst 我不再深入研究。新开发的系统不再叫做 fbinst，与 fbinst 不兼容。关键的技术大致相同，都是采用开头的 8M 带扇区序列号。区别在于，这次没有 UD 区了。用户可以把自己的 7M 数据嵌入开头的 8M 空间里面，当然了，那些扇区都是带有序列号的，用户需要自己设法使用这 7M 的数据。开发者（目前就是我）不负责处理这 7M 的数据。对比一下，在原来的 fbinst 中，开发者 Bean 为这 7M 建立了 ud 格式的文件系统，使得用户可以在进入 grub4dos 以后访问这个 ud 系统。现在，我不开发类似的文件系统，用户自己如果想要用这 7M 空间，那就得自己设法使用这个空间。用户可以不用这 7M 空间，只用可见区的 FAT32 空间。新的系统不仅没有了 UD 文件系统，也没有了隐藏区。只有可见区的 FAT32 系统。

如果你看完了前面的帖子，你就会了解，这次整个 U 盘的结构，完全归我（即开发者）管辖，每次都是提供一个 IMG 映像，供用户写入 U 盘，根据使用说明，用户只有有限的操作权，比如说，普通用户大约只能把自己的文件拖入到 U 盘的 FAT32 文件系统里面，不可以随便更动 U 盘的其他扇区结构。熟悉内部结构的用户可以把自己的 7M 用户数据嵌入到 8M 以内的区域并自己安排它的用途（如上所述）。

mygamexxx

不点 发表于 2014-1-14 08:58
mygamexxx，请同时给出启动时的调试输出信息。如果看不清，可长按 P 键保持暂停。

你的下载是否有错误？ ...

不好意思，肯定哪里出错了，重新下载了24M，重新格式化U盘后，再写入24M，目前一切正常了。

mygamexxx

明基笔记本（需要一次读一个扇区的明基笔记本）
测试成功，屏幕显示：0000 3F60 3F60 AA55
root为(fd0,0)
find
没能找到0x12类型的隐藏分区(hd0,7), 也无法用find /0pe/0pe.iso找到文件。
root (hd0,7)
ls
正常显示隐藏分区的文件
启动隐藏分区中的0PE正常。

联想台式机
测试成功，屏幕显示：0080 3F60 3F60 AA55
root为(hd0,0)
find
没能找到0x17类型的隐藏分区(hd1,7), 也无法用find /0pe/0pe.iso找到文件。
root (hd1,7)
ls
正常显示隐藏分区的文件
启动隐藏分区中的0PE正常。

2010qaqz111

不点 发表于 2014-1-14 09:33
2010qaqz111，开头的 8M 带扇区序列号，是 fbinst 的关键技术，用来突破 BIOS 的封杀的。主板 BIOS 用异常 ...

明白了，多谢大元帅解惑

如果我没理解错的话，也就是说，新的系统只是占用了U盘的前8M来做一个万能启动，后面的部分在写入IMG之后就是一个FAT32了。

以前的fbinst格式化完U盘以后，可以用DG之类的软件对U盘的分区进行重新规划，只要第一个分区的起始位置避开前面UD占用的容量即可，这个新的系统应该也是可以的吧？

不点

GRLDR 的 bug 已修复，请 mygamexxx 重新下载测试。

不点

2010qaqz111，你可能已经看出来了，我的新系统的开发理念与 Bean 的 fbinst 有差别。

1、新系统不处理 8M 以内的剩余 7M 空间，让用户自己来安排（或取舍）。fbinst 则建立 ud 系统，方便用户访问。

2、新系统不提供专门的工具，不提供各种安装参数的变化，只用一个映像文件来做。而 Bean 的 fbinst 提供了很多安装选项，方便用户选择和安装。

3、一旦发现有 BIOS 不适应问题，我的新系统的格式可能随时变动，这方面有着灵活性（这是对开发者来说的，开发者有完全的自由，可以随时变动 U 盘的格式）。外部工具的制作者可能也得随时跟进，调整自己的工具软件，以适应这些变化。相比之下，fbinst 要稳定得多，外部程序的作者不用修改自己的工具软件。

4、外部工具软件的制作者，可以研究这个 U 盘的设计，制作出自己的操作工具，方便最终用户使用。相比之下，fbinst 自带了工具，因此，fbinst 离开外部工具也能自成一体。

我为什么这样做呢？是因为哲学理念的不同造成的。

其一，是因为我个人身体状况不是很好，我想尽量少做点工作，同时又保证把软件的核心功能做到满意。

其二，是因为我个人比较懒，不想做太多的工作。

其三，是因为我个人在建立或处理（新的）文件系统方面缺乏必要的知识，也缺乏耐心，因此，我想省事，给自己 “减负”（减轻负担）。

其四，我想让工具软件的制作者们有事可做。如果我把所有的工作都做完了，那么别人的参与就少了。事实上我不可能做所有的工作，因为我不熟悉 Windows 编程，我只能寄希望于由其他作者们来完成这部分工作。如果其他作者们参与进来的多了，那么这个软件的后续开发就更有保障了。就是说，我开个头，而后续的开发工作将不存在困难，很多人都能参与进来，没有门槛（或者门槛很低）。诸位看看我的代码，核心代码简单透顶，第一阶段是 MBR，一个扇区，第二阶段也是一个扇区。总共只有两个扇区的 assembly 代码，随便一个开发者，花费半天时间，都可以研究完。工具软件的制作者就有可能会成为将来接替开发的开发者了（前提条件当然是说 BIOS 继续存在；如果 BIOS 消失了，当然就不用提了，因为不会再有人关心这个软件了）。

第一阶段的 MBR 引导记录代码，复制到最开头的 190 个扇区上。这 190 个扇区的每个扇区都带有 BPB 和分区表。

所以，工具软件的作者，应该研究分区表的变化规律，从而能够添加正确的分区表项。

第一个分区表项已经是 FAT32 了。还剩下 3 个表项可以由工具软件的作者来处理。

开头的 190 个扇区中的每个扇区，都应该有分区表项。每个表项含有 16 个字节。

除了第一个已经被 FAT32 占据的表项以外，新创建的表项，其前 8 个字节和表示分区长度的后 4 个字节应该是（在这 190 个扇区里面）保持不动的，而表示分区起始扇区号的 4 个字节在这 190 个扇区里面都是递降的。看到这个规律，那么，外部工具软件的作者要想写分区表已经不困难了。

由于 FAT32 分区故意设置为 8G 左右，超出了 CHS 的访问能力，所以，新创建的表项，其 CHS 值可以都搞成固定值：柱面号 C=1023，磁头号 H=254，扇区号 S=63。这样就简单了，新创建的表项，其前 8 个字节就是 00 FE FF FF XX FE FF FF，此处，XX 可以是 0C 表示 FAT32 分区，或者 07 表示 NTFS，或者是 0F 表示扩展分区，这些大家都懂的。精于计算的工具软件的作者，一定不难把这搞定。

---

在作出以上解释之后，我想，诸位可能也就看出来了：现在我可以 “撒手不管” 了。剩下的事，大都是用户自己的事，或者是工具软件开发者的事了。

已经制作好的这个 U 盘，估计差不多应该可以 “通吃” 了。即使不能通吃，由于内置了调试输出，所以，其失败根源很容易定位，再也不会出现 “模棱两可”、“说不清楚” 的情况了。与原来的 fbinst 相比，这也算是一个重大的改进。

---

还需要补充说明的一点是，内置的这个 grldr 版本，已经屏蔽掉了 PXE。这是因为，从 U 盘启动时，一定不是从 PXE 启动，所以，这个内置的 grldr 版本就把 PXE 功能屏蔽掉了。另外，前面还提到，默认时执行单扇区访问。用户可以通过执行一次 geometry --lba127sector 命令来切换到高速的多扇区访问。

mygamexxx

不点 发表于 2014-1-14 20:55
GRLDR 的 bug 已修复，请 mygamexxx 重新下载测试。

新版全乱了：
hd1.0不见了，
hd1,4变成了hd1,1
hd1,5变成了hd1,3
hd1,6变成了hd1,4
hd1,7变成了hd1,5  此为隐藏分区，能用find /0pe/0pe.iso找到文件了。

anxi_dongri

用一个128M的u盘，采用winimage恢复后，可以启动电脑，但是可见区容量被扩容到8G了，而事实上才总共128M啊，感觉在使用上相比fbinst，向我们这种菜鸟是比较困难的，或者是因为还没有专门的工具配合吧！期待有工具配合

mygamexxx

anxi_dongri 发表于 2014-1-15 09:26
用一个128M的u盘，采用winimage恢复后，可以启动电脑，但是可见区容量被扩容到8G了，而事实上才总共128M啊 ...

呵呵，确实如此，平白增加了容量，不知道会有什么后果。

anxi_dongri

mygamexxx 发表于 2014-1-15 10:54
呵呵，确实如此，平白增加了容量，不知道会有什么后果。

变成网上坑爹的扩容盘了，数据拷贝多了肯定丢失喽

2010qaqz111

不点 发表于 2014-1-14 23:49
2010qaqz111，你可能已经看出来了，我的新系统的开发理念与 Bean 的 fbinst 有差别。

1、新系统不处理 8 ...

了解了。也就是说如果重新分区的话，需要把分区表copy到前190扇区每区一份才能保证重新分区后新的系统仍然正确运作。

这个倒是不难，有很多办法可以搞定的：）

不点

mygamexxx 发表于 2014-1-15 08:14
新版全乱了：
hd1.0不见了，
hd1,4变成了hd1,1

谢谢您的辛苦测试和报告。又更新了，好事多磨，这次应该 “健壮” 了吧？

不点

anxi_dongri 发表于 2014-1-15 11:06
变成网上坑爹的扩容盘了，数据拷贝多了肯定丢失喽

是有点不那么自然。不过，自己小心，应该没什么大事的。顶多是拷贝进去的文件丢失了，或者拷贝失败。应该不会有别的危害。

如果想保证文件系统的完整性，那你可以只在 16G 以上的 U 盘上使用。

大家各自根据自己的爱好、根据自己的判断、根据自己的理解，来自由地使用吧。



补充一句吧，fbinst 以及这里的新系统，都是 “变态” 的启动工具。使用这些工具的人，也多多少少都有些 “变态” 的成分，不属于 “常态”。跟诸位开个玩笑，大家都很变态（包括我在内）。

anxi_dongri

不知道有没有办法更傻瓜一些，哪个高手做个像fbinsttool这样的工具，让我们这些菜鸟也有机会可以用上，最好是能把前面8M预留下来，后面的留给用户自由的使用，以后要更新就更新这8M就可以了。

不点

在第 10 页（100 楼），公布了 24M 映像文件的结构。简述如下：

扇区 0 - 扇区 189，共 190 个扇区，填充的是第一阶段的扇区。外部工具可以为每个扇区增加分区表项，别的就不要动了。

扇区 190，共 1 个扇区，是第二阶段的扇区（stage2）。这个扇区就不要动它了。当然，如果想改进它的话，那可以修改它的程序代码。

扇区 191 - 扇区 1341，共 1151 个扇区，是第三阶段的扇区（grldr）。这也不需要改动。

扇区 1342 - 扇区 16192，共 14851 个扇区（大约 7M），是空白扇区，但每个扇区都带有物理序列号。我觉得也不需要动它。

扇区 16193 - 扇区 48480，共 32288 个扇区（大约 16M），是 FAT32 的分区结构数据。目前是固定的，用户不可以随意修改。其开头的 31 个扇区（0x1F 个扇区）是保留扇区数，紧接着是两份 FAT 表，每一份占用 0x3F00 个扇区，两份共占用 0x7E00 个扇区。最后剩下一个扇区，就是 FAT32 根目录的数据。31 + 0x7E00 + 1 = 32288。目前来说，这些也都不能动。

看到没有？在理想的情况下，根本不需要改动什么。开头的 190 个扇区，一旦添加了用户的分区表项，那也就是固定的了，以后也就不会轻易改动了。如果 grldr 有更新，那只需要把新的 grldr 嵌入进去就行了。grldr 的位置是固定的，外部程序可以轻松搞定。甚至手动也能搞定（自己编译 mbr_24M.img，然后按照 grldr 的位置，取出 grldr 部分共 1151 个扇区，再导入到 U 盘对应的位置便可）。其他都应该保持不动。

用户自己在 FAT32 之下建立的文件，当然可以在资源管理器里面随便增删，这不会有什么不良影响的。

2010qaqz111

不点 发表于 2014-1-15 15:00
在第 10 页（100 楼），公布了 24M 映像文件的结构。简述如下：

扇区 0 - 扇区 189，共 190 个扇区，填 ...

区 1342 - 扇区 16192，共 14851 个扇区（大约 7M），是空白扇区，但每个扇区都带有物理序列号。我觉得也不需要动它。


这一个部分的扇区是否只有 0x0E 处的两个字节扇区号不能动，其他位置都可以自己使用的？

不点

2010qaqz111 发表于 2014-1-15 18:13
区 1342 - 扇区 16192，共 14851 个扇区（大约 7M），是空白扇区，但每个扇区都带有物理序列号。我觉得也 ...

是的。它是 userdata 的区域。如果你把自己的文件 userdata 放在源代码之下，运行 make 来编译，那么，userdata 会被添加上扇区序列号，并被放在 mbr_24M.img 的合适位置。

mygamexxx

其他分区正常了，就是不见hd1,0
ls (hd1,0)/
返回无此分区

不点

mygamexxx 发表于 2014-1-15 18:17
其他分区正常了，就是不见hd1,0
ls (hd1,0)/
返回无此分区

需要用 cat --hex (hd1)+1 看看分区表是否正常。

不点

找到毛病了。脑子开始钝化了，把 & 写成了 &&，造成低级错误。看来我真的该退出电脑软件的开发了。

这次应该没问题了。

2010qaqz111

不点 发表于 2014-1-15 18:16
是的。它是 userdata 的区域。如果你把自己的文件 userdata 放在源代码之下，运行 make 来编译，那么， ...

mygamexxx

不点 发表于 2014-1-15 20:14
找到毛病了。脑子开始钝化了，把 & 写成了 &&，造成低级错误。看来我真的该退出电脑软件的开发了。

这次 ...

目前正常了

mygamexxx

内置的grldr不支持中文了, font 加载字库后还是乱码。
好像不是
难道是我的使用错误。font /boot/grub/FONT_CN.HEX
应该是使用错误。
但不知错在哪里，同样的菜单在其他grldr上能正确显示中文。

不点

是不是菜单有隐蔽的错误？

命令行执行 font，有什么错误显示吗？