|
adatsui
初级用户
 
积分 46
发帖 18
注册 2007-11-4
状态 离线
|
『楼 主』:
[已解決] 使用pxe keep後再次加載 grub,首次map..
使用 LLM 解释/回答一下
tftp\menu.lst\default 內容大致如下 :
map --mem /dos.img (fd0)
map --mem --unsafe-boot /winpe.img (hd0)
map --hook
pxe keep
chainloader (fd0)/io.sys
進入 dos 處理一些事後, 再度進入 grub 此時 ma --status 已看不到之前的 (fd0), (hd0) , 如刪上一次加載 grub 的 pxe keep 命令, 則 fd0, hd0 仍存在 .
Last edited by adatsui on 2008-5-8 at 09:02 PM ]
The content of tftp\menu.lst\default is roughly as follows:
map --mem /dos.img (fd0)
map --mem --unsafe-boot /winpe.img (hd0)
map --hook
pxe keep
chainloader (fd0)/io.sys
After entering DOS to handle some matters and then entering grub again, at this time ma --status can no longer see the previous (fd0), (hd0). If the pxe keep command that loaded grub last time is deleted, then fd0, hd0 still exist.
Last edited by adatsui on 2008-5-8 at 09:02 PM ]
|
|
2008-5-1 21:12 |
|
|
chenall
银牌会员
    
积分 1276
发帖 469
注册 2002-12-23 来自 福建泉州
状态 离线
|
『第 2 楼』:
使用 LLM 解释/回答一下
我刚试了下,确实如此.应该是BUG吧,
不知保留PXE KEEP有没有其它作用,如果没有用就暂时先去掉PXE KEEP吧.
I just tried it, and it's indeed like that. It should be a bug,
I don't know if there are other functions of keeping PXE. If it's useless, let's temporarily remove PXE KEEP.
|

QQ:366840202
http://chenall.net |
|
2008-5-2 15:40 |
|
|
adatsui
初级用户
 
积分 46
发帖 18
注册 2007-11-4
状态 离线
|
『第 3 楼』:
使用 LLM 解释/回答一下
已去掉了.
這樣做不就是因為套用你的 S&R&S 做法, 試著可不可以進入dos 後才找所需的 SCSI給WINPE用.
只是好奇問問, 因對於10MB的驅動包, 單傳所需一個的額外處理時間, 並不會較整個驅動包傳送的時間節省多小.
哪大俠再問多一個.
map --mem --unsafe-boot /winpe.imb (hd1)
map --hook
map --status
81 FF...... M=U
map (hd1) (hd0)
81 FF ..... M=U
80 FF ..... M=S <..... 不跟源(hd1)的 unsafeboot .
好像是要
map --unsafe-boot (hd1) (hd0) 才會是 M=U . 我是胡亂試, 找不到說明. 這做法正確嗎 ?
It has been removed.
This is done precisely because of applying your S&R&S approach, trying whether we can enter DOS and then find the required SCSI for WINPE to use.
Just curious to ask, because for a 10MB driver package, the additional processing time required for single transmission will not save much compared to the time for transmitting the entire driver package.
Then, the expert asks one more thing.
map --mem --unsafe-boot /winpe.imb (hd1)
map --hook
map --status
81 FF...... M=U
map (hd1) (hd0)
81 FF ..... M=U
80 FF ..... M=S <..... Does not follow the unsafeboot of the source (hd1).
It seems that
map --unsafe-boot (hd1) (hd0) will be M=U. I'm just trying randomly, and I can't find the instructions. Is this approach correct?
|
|
2008-5-2 20:44 |
|
|
chenall
银牌会员
    
积分 1276
发帖 469
注册 2002-12-23 来自 福建泉州
状态 离线
|
『第 4 楼』:
使用 LLM 解释/回答一下
关于前面问题的解释.如下,想信以后会有解决办法的。
应该是grub.exe检测中断向量的方法引起的。如果加了pxe keep的话,pxe运行环境会保留,它会截取int 13和int 15,中断向量就不会指向rom了。
上楼:
确实是在加--unsafe-boot才会是M=U,这个不点有说过。
Last edited by chenall on 2008-5-2 at 09:28 PM ]
Explanation regarding the previous issue. As follows, I believe there will be a solution in the future.
It should be caused by the method of grub.exe detecting interrupt vectors. If pxe keep is added, the pxe running environment will be retained, and it will intercept int 13 and int 15, and the interrupt vector will not point to the rom.
Upstairs:
It is indeed that adding --unsafe-boot will make M=U, this was mentioned without clicking.
Last edited by chenall on 2008-5-2 at 09:28 PM ]
|

QQ:366840202
http://chenall.net |
|
2008-5-2 21:23 |
|
|
不点
银牌会员
     不甘寂寞的人
积分 2491
发帖 1115
注册 2003-9-24
状态 离线
|
|
2008-5-6 02:45 |
|
|
adatsui
初级用户
 
积分 46
发帖 18
注册 2007-11-4
状态 离线
|
『第 6 楼』:
使用 LLM 解释/回答一下
兩位大俠的率效實在是沒話說, 初步測試如下:
Dos 的 bootimage 內 config, autoxec.bat 文件全部內容清空.
TFTP 使用 grldr 506 Boot DOS
Dos 下分別執行不同版本 grub.exe
1. 506 X, Failure restore ROM INT -0x13 vector. Unsupported DOS, device driver, or TSR.
2. 505 OK
3. 506 x, Failure restore ROM INT -0x13 vector. Unsupported DOS, device driver, or TSR.
4. 422 --status , The int13 hook is off. The Drive map table is currently empty.
5. 505 OK
6. 506 x, Failure restore ROM INT -0x13 vector. Unsupported DOS, device driver, or TSR.
TFTP 使用 grldr 505 Boot DOS
1. 505 OK (曾試過一次進入dos 後 505版本, 顯示 Failure restore ROM INT -0x73... , 但沒法重現 !!)
2. 506 x , Failure restore ROM INT -0x13 vector. Unsupported DOS, device driver, or TSR.
3. 422 --status , The int13 hook is off. The Drive map table is currently empty.
4. 505 OK
5. 506 x , Failure restore ROM INT -0x13 vector. Unsupported DOS, device driver, or TSR.
TFTP 使用 grldr 422 Boot DOS
1. 422 x , Failure restore ROM INT -0x73 vector. Unsupported DOS, device driver, or TSR.
2. 506 x , Failure restore ROM INT -0x13 vector. Unsupported DOS, device driver, or TSR.
3. 505 OK.
4. 422 --status , The int13 hook is off. The Drive map table is currently empty.
似乎是 Server 方面 TFTP 的 grldr 用 422 Boot image 就配搭 505 版本. Server 用 505 版本 grldr , boot image 就配搭相同 505 版本.
506 似乎沒法配對得成功, 422亦然.
客機啟動了 dos 進入 gurb 後, 卻沒法啟動 winpe (黑屏, 沒重靜, 這PE正常啟動是檢測軟驅, 顯示 win logo ....) .
如去除 pxe keep 則可以. 也許有甚麼要動手腳. 待腦袋清醒點再試.
另外, 好像是 map --mem --unsafe-boot /winpe.gz (hd0) , 會由 server (TFTP) 向 客戶機發送 2 次 winpe.gz ??
第二次傳送是在顯示 probed c/h/s = 122/128/32, probed total sectors = 499711
而 map --mem /dos.img (fd0) 則不會.
Last edited by adatsui on 2008-5-7 at 02:15 AM ]
The efficiency of the two experts is really beyond praise. The preliminary tests are as follows:
The contents of the config and autoxec.bat files in the Dos bootimage are all cleared.
TFTP uses grldr 506 to Boot DOS
Execute different versions of grub.exe under Dos respectively
1. 506 X, Failure restore ROM INT -0x13 vector. Unsupported DOS, device driver, or TSR.
2. 505 OK
3. 506 x, Failure restore ROM INT -0x13 vector. Unsupported DOS, device driver, or TSR.
4. 422 --status , The int13 hook is off. The Drive map table is currently empty.
5. 505 OK
6. 506 x, Failure restore ROM INT -0x13 vector. Unsupported DOS, device driver, or TSR.
TFTP uses grldr 505 Boot DOS
1. 505 OK (Once tried to enter dos and then the 505 version, it showed Failure restore ROM INT -0x73..., but couldn't be reproduced!!)
2. 506 x , Failure restore ROM INT -0x13 vector. Unsupported DOS, device driver, or TSR.
3. 422 --status , The int13 hook is off. The Drive map table is currently empty.
4. 505 OK
5. 506 x , Failure restore ROM INT -0x13 vector. Unsupported DOS, device driver, or TSR.
TFTP uses grldr 422 Boot DOS
1. 422 x , Failure restore ROM INT -0x73 vector. Unsupported DOS, device driver, or TSR.
2. 506 x , Failure restore ROM INT -0x13 vector. Unsupported DOS, device driver, or TSR.
3. 505 OK.
4. 422 --status , The int13 hook is off. The Drive map table is currently empty.
It seems that on the server side, for TFTP's grldr, using the 422 Boot image is paired with the 505 version. Using the 505 version of grldr on the server, the boot image is paired with the same 505 version.
The 506 version doesn't seem to pair successfully, and the same goes for 422.
After the client boots into dos and enters gurb, it can't boot winpe (black screen, no response, this PE normally starts by detecting the floppy drive and showing the win logo....).
If the pxe keep is removed, it can. Maybe there is something to fiddle with. Wait until the head is more clear to try again.
In addition, it seems that map --mem --unsafe-boot /winpe.gz (hd0) will send 2 times winpe.gz from the server (TFTP) to the client??
The second transmission is when it shows probed c/h/s = 122/128/32, probed total sectors = 499711
And map --mem /dos.img (fd0) doesn't.
Last edited by adatsui on 2008-5-7 at 02:15 AM ]
|
|
2008-5-7 01:51 |
|
|
不点
银牌会员
     不甘寂寞的人
积分 2491
发帖 1115
注册 2003-9-24
状态 离线
|
『第 7 楼』:
使用 LLM 解释/回答一下
谢谢。先猜测一下发送两次 winpe.gz 的原因。因为 gz 文件解压后的长度记录在 gz 文件的末尾(占用四个字节),这是 gz 文件格式设计时的缺陷,因此 grub 需要首先读取 gz 文件确定解压长度,然后再读一次来解压 gz 的数据。
解压 gz 的操作是 GNU GRUB 固有的功能,并非我们在 GRUB4DOS 中编程实现的。要改变就要有很多改动,不太容易。目前建议你不要压缩映象。
---------------------
5月7日刚刚又上载了一个,请试试看 int13 探测失败的问题是否已经解决。
http://grub4dos.jot.com/
Last edited by 不点 on 2008-5-7 at 05:19 PM ]
Thanks. First, guess the reason for sending winpe.gz twice. Because the length after decompressing the gz file is recorded at the end of the gz file (occupying four bytes), which is a defect in the design of the gz file format. Therefore, GRUB needs to first read the gz file to determine the decompression length, and then read it again to decompress the data of the gz file.
The operation of decompressing the gz is an inherent function of GNU GRUB, not programmed and implemented by us in GRUB4DOS. To change it, there are many changes needed, which is not easy. Currently, it is suggested that you do not compress the image.
-------------------------------------------------- --------------------
Just uploaded another one on May 7, please try to see if the problem of int13 detection failure has been solved.
http://grub4dos.jot.com/
Last edited by 不点 on 2008-5-7 at 05:19 PM ]
|

因为我们亲手创建,这个世界更加美丽。 |
|
2008-5-7 08:49 |
|
|
adatsui
初级用户
 
积分 46
发帖 18
注册 2007-11-4
状态 离线
|
『第 8 楼』:
使用 LLM 解释/回答一下
謝謝不點, 5月7 日版本一切正常了. 測試如下.
TFTP grldr版本 DOS grub版本 map --mem --status boot to PE
507 422 OK OK
507 OK OK
505 OK OK
506 Failure restore ROM INT 0x13 vector.
上述配搭伺服務器 TFTP 用 507 版本, 客端 DOS 用 507, 422, 505 版本均正常. 問題解決了.
gzip 的問題明白了, 即使它有讀兩次, 但資料傳輸量仍比不壓縮小, 仍是值得用的.
243mb 的 img , gzip 後約 66mb.
Last edited by adatsui on 2008-5-7 at 09:42 PM ]
Thanks for not clicking. The May 7th version is all normal. The tests are as follows.
TFTP grldr version DOS grub version map --mem --status boot to PE
507 422 OK OK
507 OK OK
505 OK OK
506 Failure restore ROM INT 0x13 vector.
The above - mentioned matching server uses the 507 version for TFTP, and the client DOS uses the 507, 422, 505 versions all normal. The problem is solved.
The problem of gzip is understood. Even if it reads twice, the amount of data transmission is still smaller than that without compression, and it is still worth using.
The 243mb img is about 66mb after gzip.
Last edited by adatsui on 2008-5-7 at 09:42 PM ]
|
|
2008-5-7 21:39 |
|
|
不点
银牌会员
     不甘寂寞的人
积分 2491
发帖 1115
注册 2003-9-24
状态 离线
|
『第 9 楼』:
使用 LLM 解释/回答一下
读取两次 gz 的问题,原则上应该也是可以解决的。不过目前暂时无暇顾及,只能等到以后某个机会再做,请原谅。
如果 5月7日能够正常使用的话,那么以前的版本都该淘汰了。此次更动了探测中断向量的算法,应该是最合理的、同时兼容性也是最好的了。其他朋友最好也试试看,此次更动是非同寻常的,其结果可能使得在以前不支持的某些硬盘保护卡之下也能使用新的 grub.exe(前提是这个硬盘保护卡不故意阻止 grub.exe 的运行)。
谢谢 adatsui 的辛苦测试和详细报告。
The problem of reading gz twice should, in principle, also be solvable. But for the time being, there is no time to take care of it, and it can only be done at some future opportunity. Please forgive.
If it can be used normally on May 7th, then the previous versions should all be eliminated. This time, the algorithm for detecting interrupt vectors has been changed, which should be the most reasonable and also has the best compatibility. Other friends should also try it out. This change is extraordinary, and the result may make the new grub.exe usable under some hard disk protection cards that didn't support it before (provided that the hard disk protection card doesn't deliberately prevent the operation of grub.exe).
Thanks to adatsui for the hard work in testing and detailed report.
|

因为我们亲手创建,这个世界更加美丽。 |
|
2008-5-7 22:36 |
|
|
adatsui
初级用户
 
积分 46
发帖 18
注册 2007-11-4
状态 离线
|
『第 10 楼』:
使用 LLM 解释/回答一下
對不起, 因昨天試能否啟動 PE 而去掉了伺服器 TFTP menu.lst 的 pxe keep . 加回該項參數重試結果修正如下.
TFTP grldr DOS grub.exe
507 507 map --mem --status OK boot winpe failed
422 map --mem --status "int13 hook is off "
505 failure restore ROM INT 0x73 vector.
伺服務器 TFTP 用 507 版本, 客端 DOS 用 507 版本, map --mem 問題解決了.
而 winpe 啟動問題, 我試找其他人做的試試看啟動如何.
Last edited by adatsui on 2008-5-8 at 01:34 AM ]
Sorry, because I tried to see if I could boot PE yesterday, I removed "pxe keep" from the server TFTP menu.lst. After adding back that parameter and retrying, the correction is as follows.
TFTP grldr DOS grub.exe
507 507 map --mem --status OK boot winpe failed
422 map --mem --status "int13 hook is off "
505 failure restore ROM INT 0x73 vector.
The server TFTP uses version 507, and the client DOS uses version 507, and the map --mem problem is solved.
And for the winpe boot problem, I will try to find someone else's to test how it boots.
Last edited by adatsui on 2008-5-8 at 01:34 AM ]
|
|
2008-5-8 01:20 |
|
|
不点
银牌会员
     不甘寂寞的人
积分 2491
发帖 1115
注册 2003-9-24
状态 离线
|
『第 11 楼』:
使用 LLM 解释/回答一下
我感觉,PE的启动失败,不能表明 GRUB4DOS 的仿真以及中断探测恢复存在问题。有可能是 PE 自身的适应性问题,也许 PE 本身和 PXE 有冲突。
从我们的讨论中已经得知,PXE 的 ROM 竟然占用了大量的常规内存,占用了几十个 KB 甚至超过 100 KB 之多,并接管了中断 15h 和 73h 。先不论 PE 在中断号码的使用上是否与此类 PXE ROM 有冲突,单单说 PXE ROM 所占用的如此巨大的常规内存,这就很容易与其他软件相冲突了。因为在常规内存的顶端,一般认为只是用来存放“扩展的 BIOS 数据区”也即 EBDA 的,它的空间占用应该很少,一般是 1KB,最多也是 8KB。我们的磁盘仿真代码也放在这里了,目前大约占据 10KB,其实已经有点大了。然而在 30KB 以下应该还算是比较安全的。而 PXE ROM 的加入,突然提升了常规内存的占用,即便不计算 GRUB4DOS 的仿真所占据的空间,仅仅 PXE 的 ROM 就可能占用 64KB 甚至 128KB,对于如此巨大的常规内存占用,如果与其他软件完全不出现任何冲突,那才叫不可信。
我对于网络编程完全是外行,但是,我想借此机会顺便说说我对 ROM 扩展卡的一些看法。首先我认为,ROM 扩展卡不应该占据常规内存的代码空间,最多只能够占据 EBDA 中的一些数据空间(如果 EBDA 太小,ROM 扩展卡的设计者可以动态增加 EBDA 的大小)。就一个网络功能,64KB应该足足够了,用Assembly实现应该不是一件特别困难的事情;ROM扩展卡不应该用C语言来实现,因为C语言会浪费很多空间。这样,如果空间占用太大,那么开发者就要考虑压缩 ROM 的代码,而解压后就只能放在常规内存中了,这是非常糟糕的事情。
Last edited by 不点 on 2008-5-8 at 11:34 AM ]
I feel that the failure of PE to boot does not indicate a problem with the emulation of GRUB4DOS and the recovery of interrupt detection. It is possible that it is an adaptability issue of PE itself, or perhaps PE has a conflict with PXE.
From our discussion, we have learned that the PXE ROM actually occupies a large amount of conventional memory, occupying dozens of KB or even more than 100 KB, and takes over interrupts 15h and 73h. Regardless of whether there is a conflict between PE and such PXE ROMs in the use of interrupt numbers, just the fact that the PXE ROM occupies such a large amount of conventional memory is very likely to conflict with other software. Because at the top of conventional memory, it is generally considered to be used to store the "Extended BIOS Data Area" (EBDA), and its space occupancy should be very small, generally 1KB, and at most 8KB. Our disk emulation code is also placed here, currently occupying about 10KB, which is actually a bit large. However, it is still relatively safe below 30KB. The addition of the PXE ROM suddenly increases the occupancy of conventional memory. Even if the space occupied by the emulation of GRUB4DOS is not counted, the PXE ROM alone may occupy 64KB or even 128KB. For such a large occupancy of conventional memory, it would be unbelievable if there were no conflicts with other software at all.
I am completely a layman in network programming, but I would like to take this opportunity to briefly express my views on ROM expansion cards. First of all, I think that ROM expansion cards should not occupy the code space of conventional memory. At most, they can only occupy some data space in the EBDA (if the EBDA is too small, the designer of the ROM expansion card can dynamically increase the size of the EBDA). For a network function, 64KB should be more than enough, and it should not be a particularly difficult thing to implement with Assembly; ROM expansion cards should not be implemented with C language, because C language will waste a lot of space. In this way, if the space occupancy is too large, the developer should consider compressing the ROM code, and after decompression, it can only be placed in conventional memory, which is a very bad thing.
Last edited by 不点 on 2008-5-8 at 11:34 AM ]
|

因为我们亲手创建,这个世界更加美丽。 |
|
2008-5-8 10:45 |
|
|
adatsui
初级用户
 
积分 46
发帖 18
注册 2007-11-4
状态 离线
|
『第 12 楼』:
使用 LLM 解释/回答一下
是的,pe以這樣方式啟動失敗,並不意味任一方存在問題,畢竟這偏離微軟擬定的啟動方式太遠了,我也不見有多小人會意圖以這方式啟動,強求也許只是鑽牛角尖了。grub現在的彷真功能,已是很大的成功了。
pxe keep 在此引至的兼容問題,在實際應用上影響也不大,只需用帶網絡驅動包的 dos boot disk,便完全可取代,網絡功能也強很多。
Yes, the failure of PE to boot in this way does not mean that either party has a problem. After all, this deviates too far from the boot method Microsoft has established. I don't think there are many people who would intentionally boot in this way. Insisting might just be being too pedantic. The current simulation function of GRUB is already a great success.
The compatibility issue caused by "pxe keep" has little impact in practical applications. Just use a DOS boot disk with a network driver package, which can completely replace it, and the network function is much stronger.
|
|
2008-5-8 21:01 |
|
|