GRUB4DOS更新建议、bug反馈专帖

xianglang · 发表于 2013-2-3 20:50:40

最新的G4D不是让ROY给砍掉了一些无用的部分吗，怎么体积还是263K而没有减小呢？

chenall · 发表于 2013-2-3 21:09:43

并没有减功能啊，减的只是一些无用的文件。和用户无关的。

chenall · 发表于 2013-2-3 21:10:32

如果要小一点的可以自已编译，比如去掉GFXMENU等的支持，减一减可以少好多呢,再如像那些比较少用的文件等，如果你不需要也可以不编译。

时空有一个贴子就是介绍如何编译精简版grub4dos的

[ 本帖最后由 chenall 于 2013-2-3 21:11 编辑 ]

527104427 · 发表于 2013-2-4 03:08:33

发现一个巨大BUG

从2013.01.13C版开始，会把UD识别成（fd0,0），导致菜单加载失败，自动进入命令行
用U盘写入一个159M的FBA后，出现上述问题
下面是下载地址，ISO格式的，解压后制作的FBA
http://pan.baidu.com/share/link?shareid=287586&uk=2098012847

使用2012.10.02C版，正常：

使用2013.01.13C版，进入命令行：

[ 本帖最后由 527104427 于 2013-2-4 03:20 编辑 ]

roytam1 · 发表于 2013-2-4 06:48:38

原帖由 527104427 于 2013-2-4 03:08 发表
发现一个巨大BUG

从2013.01.13C版开始，会把UD识别成（fd0,0），导致菜单加载失败，自动进入命令行
用U盘写入一个159M的FBA后，出现上述问题
下面是下载地址，ISO格式的，解压后制作的FBA
http://pan.bai ...

先用2013-02-02-2試試

527104427 · 发表于 2013-2-4 10:08:16

2013.01.13C以后的所有的版本都试过了，一个样

不点 · 发表于 2013-2-4 10:21:10

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

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

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

不点 · 发表于 2013-2-4 10:30:20

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

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

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

roytam1 · 发表于 2013-2-4 11:20:22

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

附件的每一個都試一下吧

grldr-130202-gcc5678.7z (311.94 KB, 下载次数: 20)

527104427 · 发表于 2013-2-4 12:26:42

现在在外面，要凌晨才回家，晚点再反馈，久等了

xianglang · 发表于 2013-2-4 23:18:17

原帖由不点于 2013-2-4 10:21 发表

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

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

呵呵……我开始时以为减少了一些部件，，源代码文件减小了，因此相应地编译后的GRLDR也会相应减小，而我看到更新后的GRLDR还是263KB，还以为下载的是没有精简过代码的呢，让各位见笑了。

527104427 · 发表于 2013-2-5 00:46:29

抱歉，昨天时间太匆忙了，从2012.10.02到2013.01.13中间还有几个版本没来得及测试。

刚才测试了一下，这中间的几个版本都是失败的。

ROY上传的几个版本也全部失败，全部进入命令行，UD变成fd0,0

======================================

再对2012.10.02之前，所有2012的版本进行测试，全部OK.

综上所述，以2012.10.02为分割点，这个日期包括之前的都正常；这个日期之后的都不正常

roytam1 · 发表于 2013-2-5 09:02:48

原帖由 527104427 于 2013-2-5 00:46 发表
抱歉，昨天时间太匆忙了，从2012.10.02到2013.01.13中间还有几个版本没来得及测试。

刚才测试了一下，这中间的几个版本都是失败的。

ROY上传的几个版本也全部失败，全部进入命令行，UD变成fd0,0

===== ...

這樣的話應該不是編譯器版本的問題了。

http://bbs.wuyou.net/forum.php?mod=viewthread&tid=257243
1樓的附件試了沒有?

[ 本帖最后由 roytam1 于 2013-2-5 09:04 编辑 ]

527104427 · 发表于 2013-2-5 09:25:48

这三个版本全部正常！！！！

roytam1 · 发表于 2013-2-5 09:31:38

原帖由 527104427 于 2013-2-5 09:25 发表
这三个版本全部正常！！！！

http://bbs.wuyou.net/forum.php?mod=viewthread&tid=256809
那麼這帖1樓的呢?

527104427 · 发表于 2013-2-5 09:37:32

这个不正常：（前面的两个可以）
grub4dos-0.4.5c-2012-11-11.7z

后面的也都不行

不点 · 发表于 2013-2-5 14:45:23

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

有待进一步确定。

527104427 · 发表于 2013-2-5 14:57:36

下一步该如何配合？请指示

不点 · 发表于 2013-2-5 15:29:00

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

问题出在新增的判断：

      /* 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 它。具体多少个文件合适，自己先摸索。

527104427 · 发表于 2013-2-5 15:45:46

我测试都用fbinsttool重新格式化U盘的，这样应该算是重建UD了吧？（只有更换grldr的时候没有这样做，直接将grldr拖到UD）

那就只能用旧版的了，一般的合盘，都是以G计算的，我测试的UD只有159M，文件也不是很多，这样都超出了限制，那就没有必要去找最小值了

不点 · 发表于 2013-2-5 16:01:20

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

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

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

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

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

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

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

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

527104427 · 发表于 2013-2-5 16:12:54

原帖由不点于 2013-2-5 16:01 发表
159M，这个大小不重要。重要的是，文件和目录的总数有多大。

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

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

顺便说，ud ...

把列表传上来：

mbr.7z (15.07 KB, 下载次数: 13)

如果是这样的话，这是一个坏消息。光一个DPMS驱动的文件数都超过限制了

chenall · 发表于 2013-2-5 16:17:12

其实我也不建议在UD里面内置太多文件的,像一些比较松散的文件,还有小文件,像SRS驱动,可以做成ISO包来调用.

因为UD驱其实没有目录的概念.用FBINSTALL查看有目录结果,其实是经过处理的.

读取UD驱的文件需要遍历一次文件列表,如果文件太多的话,速度当然就会慢很多.

527104427 · 发表于 2013-2-5 16:24:52

这样处理就会导致很多用户出现问题，而不知道怎么解决。

我前几天在U盘启动区看到一个帖子，也是说UD区被废了，一直以为是fbinsttool的问题。

快雪时晴 · 发表于 2013-2-5 16:25:59

原来64K是目录（实际上还是文件名，没有目录层次）的存储空间大小，以为是LIST数目，觉得怎么那么大。
我用fb都是启动的必须文件加上比较小的DOS/ghost等img，大的ISO和PE还是放到可见区好，随时更换，不必去更改UD区，搞不好还出现UD区和数据区都损坏的情况。

不点 · 发表于 2013-2-5 16:27:50

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

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

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

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

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

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

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

527104427 · 发表于 2013-2-5 16:37:26

这个改不改无所谓了，只要知道是什么问题就行，我也是提个建议

不点 · 发表于 2013-2-5 16:59:22

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

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

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

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

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

pseudo · 发表于 2013-2-14 22:46:15

下次发布时，建议顺便把sample/menu.lst里所有
/0PE/0PE.ISO
都改为
/0PE.ISO

这个iso已经移到根目录很久了。

2012languang84 · 发表于 2013-2-25 00:18:09

今天更新了下合盘pe,grub4dos更新为0.4.6a 2013-02-02,测试了下

title [01] XP 引导修复工具
map --mem /BOOT/IMGS/XPBOOT.IMG (fd0)
map --hook
chainloader (fd0)+1
rootnoverify (fd0)

这个软件不能用了

换回以前的grub4dos,镜像能打开,应该是grub4dos的是吧

		自动登录	找回密码
密码			注册

GRUB4DOS更新建议、bug反馈专帖

回复 #2705 xianglang 的帖子

回复 #2709 roytam1 的帖子

回复 #2713 roytam1 的帖子

回复 #2712 不点的帖子

回复 #2717 roytam1 的帖子

回复 #2719 roytam1 的帖子

回复 #2721 不点的帖子

回复 #2723 不点的帖子

回复 #2727 chenall 的帖子

回复 #2730 不点的帖子

GRUB4DOS更新建议、bug反馈专帖

回复 #2705 xianglang 的帖子

回复 #2709 roytam1 的帖子

回复 #2713 roytam1 的帖子

回复 #2712 不点 的帖子

回复 #2717 roytam1 的帖子

回复 #2719 roytam1 的帖子

回复 #2721 不点 的帖子

回复 #2723 不点 的帖子

回复 #2727 chenall 的帖子

回复 #2730 不点 的帖子

回复 #2712 不点的帖子

回复 #2721 不点的帖子

回复 #2723 不点的帖子

回复 #2730 不点的帖子