DELL ，你为何要这样？（已解决）

zhaohj

新购买的DELL inspiron desktop 620/620s
机器自带win7 64 家庭版，想重装系统。

本人是企业环境，PXE启动

网卡是realtek 81** pci-e （查了下：PCI\VEN_10EC&DEV_8168&SUBSYS_04ED1028&CC_020000&REV_06）
很多PE1.X没带这个网卡，没WIN7PE
用全外置的PE1.X，整理网卡驱动，悲剧出来了，所有全外置的PE都无法...

[ 本帖最后由 zhaohj 于 2011-7-28 07:40 编辑 ]

yueyezhan

我前段时间买的dell n4030，从网卡启动的时候根本不能从dhcp分配地址，最后只能在pxe server的hanewin中手动绑定mac和ip，才能引导起来

chenall

可以试着换成其它的PXE引导代码。启动时占用了太多的常规内存，导致基本内存不够使用。

zhaohj

难道是双显卡的问题？
pxe启动，进入grub命令行下：
map --mem就会这样。明天再看看...

527104427

嘿嘿`````原来Z大也有遇到难题的时候`````帮不上忙……

不点

这个问题应该早就存在了，但不一定是 dell。

我以前说过，这都是主板（或者网卡） PXE 的问题。

联系前段时间 zhaohj 遇到的华硕主板的 PXE 问题，它竟然在 PXE 启动时，让硬盘无法访问。

所有以上种种现象，都有两种解释：一种是主板制造商故意干的，目的就是让 PE 之类的失效。一种是属于主板的 bug。

关于是不是有意的，这其实不容易判断。我目前似乎只能按各占 50% 的可能性来对待。

其实，只要有人向主板制造商报告 bug，如果制造商马上承认这个问题并表示要着手解决，那就基本可以断定，那不是故意的。否则，主板制造商根本不搭理，那就基本可以断定是故意的了。

所以，弄清这个问题的关键，是要有人去报告 bug。

--------------------

从贴图可见，PXE 占用常规内存太多，导致 Windows NT 启动失败。505K 和 512K 就差 7K。

不要忘了，grub4dos 的磁盘仿真代码，也要占据 12K 的常规内存空间。因此，如果你使用了 grub4dos 的仿真，那么，你可以去掉 map 之类的命令，这样就可节约 12K 的空间，于是问题就解决了。

但如果你本来就没有使用 map 命令，结果仍然只有 505K 可用，那就是主板（或网卡） PXE 的问题了，无解（除非让主板制造商解决）。

不点

原帖由 chenall 于 2011-7-18 21:05 发表
可以试着换成其它的PXE引导代码。启动时占用了太多的常规内存，导致基本内存不够使用。

主板本身的 PXE 不好，而要用第三方的 PXE，这可就麻烦了。

使用 PXE 启动的优点就是方便，不需要从硬盘启动。而如果使用第三方的 “软” PXE，则必须从硬盘（或者U盘）启动，绕一个弯，再执行 PXE 的启动。而这又是多余的：既然能够从硬盘（U盘）启动，又何必使用 “软” PXE 呢？

前面 zhaohj 说了，他使用了 map --mem。因此，我怀疑，正是由于这个 map 的使用，多占用了 12K，就导致 NT 拒绝启动的。

如果 dell 是故意的（假定如此，仅仅是假定），那么这很容易解释。它不想让 grub4dos 能够启动 NT。grub4dos 占据 12K 常规内存，这是公开的。所以，只要调整 PXE 的内存占用量，就可以做到让 grub4dos 无法与 PXE 共存。

目前有两个替代方案：

一个是采用 memdisk。它占用的空间较少，估计正好可以与 dell 的 PXE 共存。

另一个是采用 wee127.mbr 里面的 map，由于这个精简版的 map 不再处理 ATAPI cdrom，所以，节约了很多仿真代码空间。这样就有可能与 dell 的 PXE 共存了（只是有可能而已，如果占用空间仍然太大，那还是无法共存。但是最好测试一下，做到 “心中有数”）。

不点

既然这里是技术讨论，不妨再说说另外一招：用 wee63.mbr 中的简单磁盘映射功能。不过，这步骤较多，比较麻烦。

wee63.mbr 中的 map 仅仅占用 2K 的代码，非常精简。但它的功能也大大减弱了：仅仅只有 “盘对盘” 的映射功能。

假如你把硬盘开头的第一个分区做成 FAT 格式，那么，这个硬盘的 MBR 上就同时可以放置 BPB 了，于是，这个硬盘也就可以仿真为软盘了（这是基本的知识了，不在这里进行详细解说）。硬盘仿真为软盘之后，这个软盘的内容，就是原来硬盘的第一分区（FAT）的内容了。

用户可以让这个硬盘 FAT 分区隐藏起来，这样，普通的 Windows 就不使用这个分区了。因此，这个方案也是可以与 Windows 共存的了。

由于硬盘直接仿真为软盘，属于“disk-to-disk mapping”，因此，这用 wee63.mbr 就可以做到了：map (hd0) (fd0)。如此一来，就可以把仿真代码的空间减少到 2K 了。

然而这个方法如果要用于 PXE 启动的情形，还是不太方便的。因为首先，从 PXE 启动 grldr 之后，需要在本地硬盘上创建 FAT 分区，这可能不太方便进行操作。

但如果你自己是电脑教室的管理员，那对你来说不是个难事。你可以事先在硬盘上把分区做好，或者在 PXE 引导 GRLDR 之后就强行按照你自己构想来分区（甚至可以不管原有的数据，直接覆盖掉硬盘上原有的数据），这样，这个方案也就成为可行的了。把 PXE 服务器上的软盘映像文件写入本地硬盘，然后执行 “盘对盘” 映射而成为软盘，这样就可以执行安装过程了。

方法可行，不过太罗嗦了。

zhaohj

谢谢不点详细的解决方案！
目前正是PXE启动，由于map --mem多占用12K的内存而导致的。
在用户的硬盘开头的第一个分区做成 FAT 格式，原版的WIN7是这么干的。我也是自己仿真一个软盘（10M）来放置驱动（包含firadisk驱动）。
------------------
下面是仿真软盘后的内存信息：

不点

你给出的这个截图是无效的。这是正常启动时的内存布局，不是经由 PXE 启动时的内存布局。

你给出的数据，解释如下：

low memory 624K，是说常规内存有 624K。这显然不是 PXE 启动的情况。当 PXE 启动的时候，它要占据大量内存，只留下 500K 再多一点的自由内存，根本不够 Windows 使用的。而你贴的这个内存，624K，绰绰有余，足够了。

Usable RAM：Base 0，length 9C000 意思与前面是一样的。9C000 是按字节数算的，它是十六进制，换算成十进制，正好也就是 624K。

Usable RAM 是 “可用内存” 的意思。操作系统以及应用程序可以使用这样的内存。

其它类型的内存（标明为 Reserved，意思是保留给主板使用，而操作系统以及用户都不可以使用这些内存），都是 “不可用内存”。

zhaohj

原帖由 不点 于 2011-7-19 10:03 发表
你给出的这个截图是无效的。这是正常启动时的内存布局，不是经由 PXE 启动时的内存布局。

你给出的数据，解释如下：

low memory 624K，是说常规内存有 624K。这显然不是 PXE 启动的情况。当 PXE 启动的时 ...

确实是PXE情况下的截图，因为我没有其他的启动方式。
这张图是下面蓝色语句前截的图，所以我很怀疑dell在搞鬼！
后一张图可以看出pxe的情况还存在

!BAT
debug off
map --mem /COOLG/EXT.IMG.GZ (fd0)
map --hook
insmod (fd0)/GRUB/FAT
pause --wait=0 Copy Net Drivers...
FAT copy /COOLG/NET.CAB (fd0)/
cat --length=0 /COOLG/OEM_NET.CAB && FAT copy /COOLG/OEM_NET.CAB (fd0)/
pause --wait=0 Coping Tools,Please waiting...
FAT copy /COOLG/IMG/CLIENT.INI (fd0)/
map --mem=0xb000 /COOLG/IMG/TOOLS.WIM (rd)
FAT copy (rd)+1 (fd0)/TOOLS.WIM
checkrange 0x21 read 0x82a0 && pxe keep && goto :1 ! goto :3
:1
cat --length=0 /COOLG/SERV_SET.BAT || goto :2
FAT copy /COOLG/SERV_SET.BAT (fd0)/
set /a ip=*0x8288&0xff
set /a a=*0x8288>>8&0xff
set ip=%ip%.%a%
set /a a=*0x8288>>16&0xff
set ip=%ip%.%a%
set /a a=*0x8288>>24&0xff
set ip=%ip%.%a%
write --offset=0x100 (fd0)/SERV_SET.BAT \r\nset PXE_SERVER=%ip%\r\n
:2
delmod fat
chainloader --force ()/COOLG/IMG/PXEIMG.0 && boot
:3
delmod fat
chainloader ()/COOLG/PE2003I.BIN

不点

要定位问题，必须尽量排除无关的一些乱七八糟的事情的影响。

你何不在第一条命令就执行 displaymem 呢？为何要等到 map 以及其他有可能出现 bug 的语句执行之后呢？

如果依旧显示 624K 内存，那就证明，dell 没问题，而有问题的，恐怕是 grub4dos（的 bug）。

也许 karyonix 的补丁有 bug，也许 grub4dos 的其他部分存在 bug，当然也可能是 dell 的主板在某个地方存在 bug，影响到 grub4dos 了。具体什么情况，还得追查。

[ 本帖最后由 不点 于 2011-7-19 11:38 编辑 ]

zhaohj

再截二张图，
第一张是PXE启动直接displaymem
第二张是PXE unload 后displaymem

不点

它很牛B！PXE竟然完全不占用常规内存！

感觉这是世界上最好的 PXE 程序了！

那么接下来就是要确定，究竟 grub4dos 在什么地方存在问题。

首先，请确定是不是 karyonix 的补丁造成的。

你先用旧版的 grub4dos 来试验，如果没问题，那就是 karyonix 的补丁所带来的新问题。

旧版可以选择 karyonix 补丁之前的版本。看看最近的 change log，那标明 karyonix int15 fix 的，就是这个补丁了。应该使用在此之前的版本来试验。

drdark

呵呵，Dell的新机器确实...伤不起， 我们公司又是清一色dell机器。 去年买的e6410,A09之前的BIOS就是没有办法PXE,死活DHCP不了。刷了A9 后就O了！

还有这个E6410，至今没有成功F6 过，只要一map --mem floppy 安装系统就必死！

最近新进的r210服务器，网卡玩死人，官网下的驱动，接千兆思科2960无信号，非要到引导盘去搜驱动才行，线认了，结果TSE又出问题！
用引导盘装03，复制到95%就死；拿光盘直接装，无论是F6 还是接软驱，加载驱动后能任盘，但是安装程序提示非标准硬盘，无法安装。 F6加Ghost倒可以装好系统
最后电话Dell一顿骂！换回旧的r200!

[ 本帖最后由 drdark 于 2011-7-19 12:23 编辑 ]

zhaohj

2011-06-19 (karyonix)int15 fix. (tinybit)remove code to save handler room.
换回2011-06-10的版本
内存布局还是与13楼一样，但成功进入PE

看来(karyonix)int15 fix有问题

----------------
DELL很牛B！PXE竟然完全不占用常规内存！

[ 本帖最后由 zhaohj 于 2011-7-19 12:41 编辑 ]

不点

接下来就要仔细研究，karyonix 的代码究竟在什么地方有错误了。

135956

不点的钻研分析精神，太专业了。

zhaohj

看来这次是冤枉DELL了...
但还有点疑问，PXE竟然不占用常规内存

canmao

牛！----- 比对13楼截图，貌似0内存占用
或：
dell 定义了一块“Reserved” 专用于 PXE ？

[ 本帖最后由 canmao 于 2011-7-19 16:14 编辑 ]

2011wanpimao

你们都是高手，我是神马？

不点

发现 karyonix 的代码有错误。不过，要全部弄清楚，还需要时间。

zhaohj 可以上载一个没有 PXE 时的内存布局图片，看看从硬盘启动时的常规内存量是多少。如果仍然是 624K，那就说明，PXE 不占用常规内存。如果比 624K 大，那就说明，PXE 还是占用了（少量）内存（其差值就是 PXE 所占用的内存）。

无论如何，这个 PXE 的内存占用确实是很少了，最大也超不过 （640K - 624K） = 16K。这应该算是非常棒的了。PXE 内存占用越少，它的兼容性就越好，它就越不容易与别的软件产生内存冲突。

>>> dell 定义了一块“Reserved” 专用于 PXE ？

这是很有可能的。DELL 可以使用 EBDA（即所谓 “扩展的 BIOS 数据区”） 的一部分空间供 PXE 使用。如果是这样的话，我认为这是到目前为止所发现的最合理的 PXE 程序。

一般认为，PXE 不可能不使用常规内存。因为 PXE 的运行需要保存一些变量（数据结构），这不能够仅仅在 ROM 中完成，因为 ROM 是不可写的。那么 PXE 应该把变量保存在哪里呢？我认为，EBDA 就是一个比较合适的地方。EBDA 当然也占据常规内存。不过，如果程序设计得很周到，可以做到很少的占用。

从已经贴出的图片可以推知，DELL 的 EBDA 最大可能占据 16K，最小当然是 0K。究竟是多少，还需要看内存中的 BIOS 数据区 0040:000E 处的双字节值。

大家搜索 “BIOS data area”，可以找到相关的知识。

zhaohj

好的，我明天会上传。
我准备把这台机器再扣留几天，偏于不点大分析与解决问题。

不知还需要什么资料？

不点

把 BIOS 数据区显示出来看看。也可以顺便把中断向量表弄出来看看。

另外，等将来更新 grub4dos 以后，还需要验证问题是否解决了。

你就多扣留几天吧，直到问题彻底解决为止。

zhaohj

好的，单位同事的机器，扣留几天没问题。
不过问题不大，单位同事的机器一定在单位的，随时可以支配！（好在自己有这点权力）。
---------------
我就上传两个5K的内存空间（PXE与非PXE启动的5K内存空间）。

zhaohj

太神奇了，hdd-boot，常规内存量仍然是 624K。
我把资料分成两个目录下：610目录代表grub4dos版本号是2011-06-10；714代表grub4dos版本号是2011-07-14
下面的文件：
pxe，代表pxe启动时的保存的内存5K
hdd，代表hdd启动时的保存的内存5K
hdd-mem表示hdd启动时displaymem的输出记录
----------------
大概看了一下，HDD启动时，可用的常规内存是0x270=624kb，与显示的实际情况相符。PXE启动时，可用的常规内存是0x205=517kb，与displaymem的情况不相符。

[ 本帖最后由 zhaohj 于 2011-7-20 08:19 编辑 ]

不点

好了，这下就全清楚了。

先前由于没有贴 BIOS 数据区的内容，所以仅仅凭借 int15 的显示来说话。但 int15 在常规内存中不具有 “话语权”，因此，先前的分析是无效的。

在常规内存中，真正具有事实工业标准地位的是 0x413 处的 “常规内存总量”。

在 PXE 启动时，常规内存总量变成了 517K，如果此时使用 map，则会占据 12K，结果，常规内存将会减少到 505K。这正是 Windows 报告的数值，无法启动 Windows。

就是说，DELL 的 PXE 是很糟糕的。它的 EBDA 也是很糟糕的。

EDBA 通常只有 1K，2K 或 4K，而 DELL 的 EDBA 占据 16K。

DELL 的 PXE 又占据了 624K - 517K = 107K。

EBDA 和 PXE 两者总共占据 123K。这就造成 grub4dos 的 map 没有足够空间可用的情况。

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

剩下一个疑问：为何旧的 grub4dos 能够启动 Windows？

旧的 grub4dos 的 map 没有修正 int15，而 Windows NT 则使用 int15 来确定常规内存。由于旧的 int15 完全没有保护 12K 的仿真代码，即，相当于这些代码不占据常规内存，因此，骗过了 Windows NT 的启动程序。经过 karyonix 修正的 int15 则保护了 12K 的仿真代码，于是，Windows 就发现，内存不够了，因此，Windows 拒绝继续运行。

好了，这就完全解释清楚了。karyonix 的代码，并未表现出错误（其实也有小错误，不过没有影响到 DELL 这台机器的情况，这些小错误以后也会加以更正的）。它只是太真实了，所以，反而无法启动 Windows 了。

已经证明了，问题的根源在于 DELL 的 PXE 代码以及 EBDA 占用了过多的内存，只剩下 5K 的空间留给别的程序（例如磁盘仿真）使用。这是 grub4dos 无法启动 Windows 的根源。解决办法正如前面所说，可以使用 memdisk 来代替 grub4dos，也可以使用 wee127 等，不再重复说明了。它们可能只需要 5K 就能完成仿真的任务。

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

从这一系列的报告中，我们可以了解到不少知识。

其一，主板制造商用 0x413 来指示常规内存的占用情况。而在主板的 int15 中，根本不反映常规内存的占用情况。这一点与以往所公布的资料是一致的。这确立了 0x413 （在常规内存方面）的事实工业标准地位。

其二，Windows NT 不使用 0x413 这个具有事实工业标准地位的规范，它反其道而行之，使用 int15 来确定常规内存的使用情况。旧版的 grub4dos 之所以能够 “蒙混过关”，就是因为省略了 int15 的步骤，导致仿真代码（所占据的空间）实际上处于不被 int15 保护的状态，使得 Windows 以为仿真代码没有占用空间，因而幸运地启动了 Windows。新的 grub4dos 之所以不能启动 Windows，则是因为增补了 int15 代码，让 Windows 明白，仿真代码占据了 12K 的空间，于是，Windows 发现，总的剩余空间不够 512K，从而拒绝启动。所有这一切证明了，Windows NT 并不看 0x413 处的值，而只看 int15 的返回结果。

好了，我们已经知道了，硬件制造商和微软（确切地说，是微软的 NT）使用的是不同的规范。在 DOS 和 Win9x 时代，大家都使用 0x413 这个统一的规范（那时候，甚至 int15/E820 这个规范都可能是不存在的，或者刚刚诞生不久）。

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

以上就是这一系列报告的概况（或综述）。至于说如何解决这一问题，大家先发表各自的意见吧。

zhaohj

1：那displaymem显示的可用常规内存是否应该显示的是0x413的值？
   我看到PXE启动时，6.10版及7.14版0x413都是05 02，应该是正确的。

2：PXE启动时，能否加个命令，使int15保护的状态禁用。

zxw

设置一个开关，默认使用int15保护。

[ 本帖最后由 zxw 于 2011-7-21 17:57 编辑 ]

不点

看来只有设置一个开关了。

而默认时，究竟是采用 int15 的保护呢，还是不采取 int15 的保护，这还需要表决。

请再多一些人来说说。