中国DOS联盟

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 ]

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.

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?

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 ]

See if the latest compilation has resolved the issue in the top post. Download: http://grub4dos.jot.com/

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 ]

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 ]

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 ]

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.

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 ]

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 ]

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.