那绝对是一个很糟糕的主意，那样我又要重复对无法定位的BUG所带来的困扰。为什么我一再建议恢复APT更新，原因就在这，ISO测试模式比APT全面更新还要愚昧。除非我们都在一起象EVL的开发组成员在一起上班，否 ...
但是这个bug不重做iso是无法重现的。不能重现就不好解决。
另外，因为你的0727升级版和现有的版本已经有所差别了。如果要从0727，那么许多东西需要重来。
2.6.23.1的内核看来是有些问题。
我试试降级到2.6.22看看。 降级内核到2.6.20.11-smp，重新用MI2.1r3制做安装盘，安装正常、编译正常、上网未发现异常，看来现在只有2.6.23.1的内核问题。
splashy的问题，在系统初装完第一次启动时如果按ESC退出会出现启动中断，只能重启，如果去掉grub启动splashy的参数，运行到网络向导时仍然出现焦点丢失的毛病，需要按ALT+F1/F2来回切换一次才正常。初装后网络向导比eth0开启要慢，造成splashy较长时间停在eth0的启动失败上，问题是这时初装用户不知道发生了什么，按F2所跳动的信息可看性太差，按ESC键前面提到过，系统启动中断，splashy出错。 wxAll编译multiget正常，这个挺费解，那么我收回我错误的论断。。。 原帖由 haulm 于 2007-11-14 07:52 AM 发表 http://www.linuxfans.org/bbs/images/common/back.gif
1113测试过了，主要的BUG也是最大的BUG在于内核。为什么这么肯定是内核，因为之前我的自制ISO升级内核到2.6.23.1-smp就出现过编译死机的问题，在1113这个ISO安装后表现就更为明显，编译multiget时拖动窗口开 ...
我的 gentoo 编译 pyQT 也遇到过这个问题，内核好像是 2.6.22-gentooX 。表现为编译到某一个文件时卡死，等一段时间后内存占用疯涨，直到占满所有内存后内存不足推出。
内存占满后计算机几乎失去响应。 曾经编译 koffice 的时候也是这个样子...............:shock: 编译器溢出，如果是内核的问题，也只能是内存部分出问题了。
不然就是 gcc 的问题。 原帖由 jiangtao9999 于 2007-11-14 21:57 发表 http://www.linuxfans.org/bbs/images/common/back.gif
编译器溢出，如果是内核的问题，也只能是内存部分出问题了。
不然就是 gcc 的问题。
gcc没问题，内核问题。据观察，2.6.23.1这个内核的确存在较大的毛病，你可以从EVL论坛得到一些BUG报怨，征状和MGC使用2.6.23.1内核一样，集成2.6.23.1内核的EVL0.5并不稳定，经常死机，如果EVL尝试编译的人群多一些，这个BUG很容易被定位到内核上。 不过我在使用2.6.20.11内核发现几乎是有多少内存它就用多少，虚拟内存swap设也是白设，会不会是内存分配设置上不合理才导致2.6.23.1内核运作时编译死机？
页:
1
[2]