GRUB4DOS更新建议、bug反馈专帖

不点

好像没有这样的限制，你可以看看源码。

如果超过 1432 就失败，那可能是你的 PXE BIOS 有此限制而已。bootmgr 有可能是用自己的 pxe 驱动来做的，不用主板的 PXE BIOS，那当然就不同了。

不点

是你理解不到位引起的吧？当然，那也可能是 grub4dos 的文档含糊不清引起的。

对于无 MBR（即，无分区表） 的分区映像，它本身是一个文件系统（即，volume 卷）。当使用 --mem 把它 map 成一个硬盘时，由于传统的硬盘都是含有分区表的，所以，grub4dos 会自动在其前面添加一个磁道，同时也填写适当的分区表以及 MBR 的代码。此时，这个虚拟的文件系统（卷）将成为 (hdX,0)，就是说，它将成为虚拟硬盘的第一个分区。

当不带 --mem 时，不会为其添加含有分区表的 MBR 磁道（因为实现起来很费事；但严格来说，也有可能实现它）。所以，不带 --mem 时，最好把它 map 为软盘，而不要 map 为硬盘。如果你非要把它 map 为硬盘，那么，你要明白，你这个虚拟硬盘就没有分区表了，它完全就是一个 volume，从虚拟硬盘的第一扇区开始，它就是一个文件系统。因此，像你图片中的情况，你用 ls (hd2)/  应该可以列出这个文件系统中的文件。而

ls (hd2,0)/
ls (hd2,1)/
ls (hd2,2)/
ls (hd2,3)/

等等，都属于错误用法。至于说 ls (hd2,3)/ 能够成功列出文件，那也许是你这个映像的特别设计（映像的第一扇区同时包含有效的分区表和 BPB 表，这样的双重结构），也许是一种巧合。

不点

技术总是有它的局限性的。GRLDR 有总体积限制，好像不能够超过 384K，超过 384K 之后，能否正常运行，不太清楚。512K 是又一个坎。如果超过 512K，引导扇区代码可能根本无法成功加载 GRLDR。

如果引导扇区可以加载超大的文件（比如达到 20M），那就可以把字库续尾在 GRLDR 后了。

看看 yaya 对此有无把握。如果 yaya 能够在 0.4.6 中实现，那就太好了。

不点

小字库我也不赞成，因为它只适合于少数国家、地区的语言。

要加载，就应该加载大字库，包括全部国际化语言字符集（65536 个基本字符）。

所以我希望在 0.4.6 系列中支持加载任意大的 GRLDR 到扩展内存中，这样，这个问题也就可以彻底解决了。

不点

说的也是。

内置菜单其实就是一个内嵌文件。现在的意思是说，再增添一个内嵌文件，内容是字库。应该可以做。

不点

关于新的内嵌菜单的设计，请留意时空论坛的最新动态。

不点

这表明 2012-11-23 的版本有疑似 bug。

我已无暇照顾 grub4dos。

请 chenall、Roy、yaya 等检查排解。


发现楼上兄弟把年份写错了，应该是

2012年11月12日，

而不是

2011年11月12日。

就是说，是 2012-11-23 引入的 bug，较前的 2012-11-12 是正常的。

[ 本帖最后由 不点 于 2012-12-1 16:45 编辑 ]

不点

mygamexxx 说，年份没错。这就证明，不是 2012 年 11 月 23 日引入的 bug，而是早在去年就引入的。但那不应该算是 bug，而可能是 chenall 的设计。

这也间接证明了，2012 年 11 月 23 日 的版本，没有任何问题（因为今年所有的版本都是一样的表现）。

不点

印象中，0.4.5 以来，有过两次改动，一次是把 linux kernel 加载在 16M 处，后来改成加载在 32M 处。

在 boot 执行的时候，又自动把 32M 处的内核以及 initrd 映像向下平移到 1M 处，递交控制权。

首先要看看 memtest86 是不是 Linux 内核。我猜它可能不是 Linux 内核。因为 Linux 内核加载是正常的，已经验证了很长时间了。

如果它不是 Linux 内核，它有可能是符合 multi-boot 规范的内核。它也是加载在 32M 处，而 boot 命令会自动平移到 1M 处，递交控制权。

不点

粗看了一下，r306 没发现问题。叙述如下：

asm.S 仅仅改动仿真代码，完全与 kernel 命令的加载过程无关。

builtins.c 也是改动 map 命令以及 font 命令，与 kernel 命令完全无关。

common.c 仅仅增加了一条 printf 语句，所以，也是毫不影响。

dosstart.S 和 grldrstart.S 都是启动代码，与 kernel 命令这种核心代码更是没关系。

fsys_fb.c 的改动仅仅影响 ud 盘启动的情形，所以也可以认为是毫无关系的。

shared.h 最后只剩下这个改动或许值得怀疑了。

要不 Roy 先试试看：是不是 shared.h 的改动引起的？我感觉应该不太可能是这个引起的。不过，请试试看先。

不点

只要找到原因即可。

我有点疑惑：难道有人混进 gcc 的开发队伍中？

不点

我印象中，论坛上神雕兄发布的 Slitaz 中文版，用来编译 grub4dos 很稳定。但我忘了其 gcc 的版本了。

Roy 你就摸索着看吧。

这样也好，提醒了我们，gcc 的版本，问题大着呢。

正式发布时，gcc 版本的筛选，看来是个大课题。

我帮不上忙了。

不点

原帖由 xianglang 于 2013-2-3 20:50 发表
最新的G4D不是让ROY给砍掉了一些无用的部分吗，怎么体积还是263K而没有减小呢？

所发布的 7z 文件中，并不包含源代码树，所以，砍掉的源代码树，不会减少 7z 文件的大小。

但是，当你编译的时候，你会发现快多了，原因就是源代码树被砍掉了许多。

不点

原帖由 527104427 于 2013-2-4 10:08 发表
2013.01.13C以后的所有的版本都试过了，一个样

元月13日以前还有若干个版本，都试验一下吧。因为最近发现编译器问题，所以，怀疑此处的问题依旧是编译器问题。

先试试再说，以便得到足够的信息，确定到底是不是编译器的问题。

不点

正在评估你的测试结果。初步怀疑，是 UD 区设置的问题，超出 UD 的能力，被新版禁止了。

有待进一步确定。

不点

已经差不多弄清楚了。虽然我现在也不是百分之百确定这一情况（我老眼昏花，也是可能的），但我自己已经比较确认了，其根源正如如下所说。

问题出在新增的判断：

        /* if the dir list exceeds 64K, safely exit with failure. */
        if (list_used > 128)
                return !(errnum = ERR_WONT_FIT);

这个判断的意思是说，如果 UD 区的目录项太多，导致目录列表超过 64K，这将被拒绝，不能 mount 这个 ud 区。

就是说，ud 区的目录和文件的个数不得太多。

必须重建 ud 区，删除多余的目录和文件，保持尽量少的目录和文件总数，使得它的列表不超过 64K。

grub4dos 为 ud 区的目录、文件列表保留了 64K 空间。无论新版还是老版，都是如此。

以前的老程序没有检查实际的 ud 区的文件列表是否超限。这会带来潜在的问题，比如造成内存冲突，很难排查。

新版增加了安全检查，对于超限的，拒绝执行 mount 操作。


解决办法：

必须重建 ud 区，减少 ud 区的目录和文件的数量，保证 grub4dos 可以正常 mount 它。具体多少个文件合适，自己先摸索。

不点

159M，这个大小不重要。重要的是，文件和目录的总数有多大。

你没有给个具体的数字，也就无法估计。

如果真的没有很多文件，那么这样的失败，可能就不是我所说的原因了，或许有别的原因。

顺便说，ud 区的文件主要目的是用来启动的。尽量不要把别的文件往 ud 里面塞。有些文件不需要放在 ud 里面，那就最好不要把它放在 ud 里面。



粗略估计，如果每个文件的项目按 100 个字节计算，64K 只能放 655 个文件的信息。

通常放 1000 个较短的文件名，应该也是没问题的。

但是如果有几千个文件，那就几乎肯定超限了。

[ 本帖最后由 不点 于 2013-2-5 16:14 编辑 ]

不点

你的文件个数是 1662 个。这个正好在危险范围之内。如果减少到 600 个之内，应该就没问题了。

我只负责把问题的根源找出来。至于说究竟该怎么处理，究竟要不要改进 grub4dos，适应你这种状况，那由 chenall、Roy、yaya 他们来决定。



我个人认为， 600 个文件，也足够用了。安排妥当的话，根本不需要这么多的文件。这是我的意见。

这最终是个权衡，看看 chenall 他们是怎么决定吧。



顺便想起来，前些日子还讨论过 ud 区存放超过 4G 大小的文件的问题。最后，大家几乎都认为，没必要存放大小超过 4G 的文件。

ud 区的宗旨是来干什么的？这个，开发者们要有清醒的认识。bean 开发 ud 区的主要目的是什么？这个一定不能含糊。不要舍本逐末，让 ud 区去干 “非ud区”的事情。好了，这就是我的大致意见。

[ 本帖最后由 不点 于 2013-2-5 16:42 编辑 ]

不点

是的，把问题弄清楚，是最要紧的。

我们知道这不是编译器的问题了，这是一大收获。Roy 不用再去找编译器的问题了。

弄清根源，是最要紧的事情。

弄清楚了以后，大家各自都会思考，究竟下一步该怎么办。

问题暴露出来以后，用户有用户自己的权衡和决定，每个开发者也都会有自己的思考、酝酿、讨论和决定。

不点

我感觉，要么是编译器的问题，要么是用户超限使用 grub4dos 造成的。我粗略看了 3月3日的改动，没发现有什么改动可以影响到所报告的问题。

用户可能以某种错误的方式使用了 grub4dos。比如，用户占用了 grub4dos 需要使用的内存，造成潜在内存冲突，等等。总之，超限使用 grub4dos，超出 grub4dos 的能力。这种情况很隐蔽。往往当一个用户想当然地以为 grub4dos 应该具有某种能力（而实际上没有那么大的能力）的时候，就会发生这种情况，即，发生莫名其妙的情况。

用户应该检查自己的每一条命令、每一个用法，看看有没有可疑的 “超限” 情况的存在。

grub4dos 开发过程中有很多已经声明不支持的情况，用户如果强制使用那些不支持的情况，用户自己应该负责。

不点

感觉像是 chenall 修改 parse_string 造成的。假如确实如此，那么问题很严重，不仅仅是 cat 要出问题，其他命令也有可能出问题。

不点

cat 命令出错的问题，原则上讲，都可以精确定位。

只要有时间，就能找到根源。

比如说，在出问题的机子上，进入 grub 命令行，单独执行一条 cat 命令，看看是否正常？如果正常，那就怀疑 cat 之所以不正常，是与事先执行过的其他命令相关的。如果单独的一条 cat 就已经不正常了，那就怀疑 grub4dos 本身存在 bug。

不点

楼上，恕我直言，你的测试不严谨。你没有提供 0.4.5c 的测试信息，而 chenall 上载的版本有 0.4.5c 和 0.4.6a 两个版本。

不点

我不是来干扰开发的，只是说说我自己的看法。

增添到 32 字节，依旧是固定长度，终究还是有人要抱怨。所以这没有解决根本问题。

最理想的情况是无限长度，或者支持类似于 Linux 的正则表达式，不过，那都不容易实现，或者说，实现起来太辛苦。

以上 zhaohj 的解决方法，可以给个别人（在个别场合）使用，这肯定没问题。但要融合到 grub4dos 的代码库中，我感觉还不是很合适的。

前不久 shao miller 给 grub4dos 打补丁要解决与 eltorito.sys 相关的某个问题，就被我果断地 “喀嚓” 掉了。他的解决方法不是不正确，而是（在我看来）不可以吸收到 grub4dos 的代码库中。 就是说，那样的解决方式是不成熟的，或者说是有问题的。正确的东西，不一定就能够进入 grub4dos 的代码库中。因为正确性本来也是相对的。干任何事情，都有权衡在里面，你不可能没有权衡。这权衡也便是哲学罢了。本来 “正确” 的东西，经过权衡之后，很可能变成 “不正确” 的，或者 “不合适” 的。

chenall 作为项目管理员，我希望也能够逐步加强哲学训练，把哲学的重要性进一步提升，更加重视哲学问题。其实，积累经验的过程，就是哲学精进的过程。所以，其实我们都是“活到老学到老”，我们每天的哲学都在不断前进，这是不由自主的。哲学是实实在在的，哲学是非常实用的，而不是高不可攀的，更不是无聊的空谈。

通常来说，中庸之道很有用。那就是不走极端。既要宽松，又要严肃。这是矛盾的。正是因为有了矛盾，所以才需要我们去判断、去权衡。这个工作要做起来，还是蛮困难的，不容易把握好。所以还是需要有经验，而经验本身也就是哲学。所以，说到最后，我们还是需要重视哲学，有意识地加强哲学训练。

不点

回复 2823# 527104427

我都升到大元帅了，讲话自然也得有所变化。姑妄言之，姑妄听之。每个人都是哲学家。你脑子里面想的是什么，别人干涉不了。你想听谁说，就听谁的。如果你不想听，完全可以置之不理。大家都是自由的、平等的。谁也不比别人高一头、宽一肩膀。自己的事，自己做主，别人做不了主。

不点

zhaohj 改进后，支持任意长字符串，这点不错。我没时间看代码。chenall 可以看看代码是否存在别的隐患，如果没有发现什么问题，我觉得可以采纳。或者 chenall 再检查、修改、完善一下，然后提交到 svn。

不点

是的，感觉糊涂兄应该发求助帖，而不是 bug 报告帖。

很可能是你原来的菜单有问题，只是未被你自己发现罢了。

不点

chenall 发表于 2013-4-11 10:35
@zhaohj,@不点
看了一下,这个暂不采纳.
这个修改只是简单的把以前的固定16数字改掉.

你说的意思是，有隐患。

scratchaddr 处的空间是有限的，而且将来可能移动到别处。所以，依赖 scratchaddr 的做法，那就有着潜在的“缓冲区溢出”危险性。安全第一，你权衡之后不采用，我觉得也是对的。另外顺便说，即使采用调用 malloc 分配内存的方法，我也觉得不好，因为我认为 malloc 是不该由内核使用的。以前我说过，内核应该使用 32M 以内的固定内存地址，而不应该调用 malloc 来分配内存。

我同意你后来的分析。应用程序本身应该进行优化处理，避免搜索很长的字符串。

当然，搜索长字符串的问题，将来仍有可能解决。但另一方面，即使解决了任意长字符串的搜索问题，也不等于就解决了与此相关的所有应用问题。比如说，有人搜索的字符串不长，但却不是一个恒定的字符串，而是按照某种规律变化的字符串。此类特殊应用，即使使用 Linux 的 grep 也不一定能够解决。这些特殊的应用，似乎不应该列为 grub4dos 必须解决的问题，而应该划归一般的应用程序设计问题。

开发 grub4dos 很累。开发者、维护者应该也想到如何为自己 “减负”（减轻负担）的问题。不能够 “事事关心”、“面面俱到”。

有人反对我讲哲学。可是事事都离不开哲学。我以上这段话也全都是哲学。所以，反对归反对，执行归执行。别人的反对，与自己的执行，是两件事。别人的反对或支持，那只是自己的参考。权衡之后，自己有自己的判断，照着自己的来。世上没有绝对真理，也不可能让所有的人都满意。

不点

我印象中，Linux 的内核中就有一个叫做 kmalloc 的函数。它分配的内存是内核空间的内存。而普通的 malloc 所分配的内存是给应用程序使用的。

如果用固定内存的话，则不需要创建 kmalloc 函数。

使用固定内存当然是有坏处的，比如说，内存的使用不灵活。但固定内存的执行效率要稍稍高那么一点点，不需要“分配内存”这个动作。

我觉得 chenall 有时间、有精力的话，就写个 kmalloc 函数。需要懂得内核的空间占用情况，才能写好这个 kmalloc 函数。如果别人不熟悉 grub4dos 的内存占用情况，那就不太容易做这个工作。所以我还是觉得 chenall 比较适合做这个工作。

如果没时间的话，就保持现状也可以。

顺便说，我已经渐渐脱离 grub4dos 的开发。关于 grub4dos 的开发方面的见解、主张，我已经在论坛上有所表露。离开之后，我当然还是很关心 grub4dos 的。看过去的历史，有很多事情是我不曾想到的。正式加入维护的有 bean，chenall，Roy，yaya。对这几位维护者表示十二分的满意。维护者们各自都有超级精彩的贡献，这是以前所没能想到的（没敢有这奢望，甚至曾经担心不会有人接手开发）。还有太多幕后的奉献者，像 Gandalf 等，不一一提及。在 chenall 投入 grub4dos 开发之初，我就说过，我一定全力支持。我觉得，我也尽到了最大努力支持 chenall 和 grub4dos。我能够如此满意地渐渐离开，这真的是我做梦都不曾想到的。也许是上帝给了我支持吧，感谢上帝。也简单作个自我评价。我觉得我自己对这个项目的贡献主要是两条：其一是应对 BIOS bug 的挑战，其二是引入哲学式开发和维护的思路。在早期由于认识水平低下，我还骂人了，或者与朋友们发生矛盾冲突，表现出神经质的症状。希望得到当事人的理解与原谅。

不点

好的，有太多的人在等待正式版了。