中国DOS联盟

The following are four blocks of Grub4DOS statements to boot ISO images. They can start successfully in the boot menu.lst at the beginning of boot, but when entering the console command line of Grub by typing "grub" in pure DOS and manually entering "chainloader (0xff)" or "chainloader (hd32)", all errors occur. I don't know why. And there is no problem to boot .IMG and .IMA. Please,各位 Grub masters, how should I manually enter to boot ISO images in the console commands of grub4DOS?

title 1, Boot ISO
find --set-root /ghost/msdos71s.iso
map --mem /ghost/msdos71s.iso (0xff)
map --hook
chainloader (0xff)

title 2, Boot ISO
find --set-root /ghost/msdos71s.iso
map /ghost/msdos71s.iso (0xff)
map --hook
chainloader (0xff)

title 3, Boot ISO
find --set-root /ghost/msdos71s.iso
map --mem /ghost/msdos71s.iso (hd32)
map --hook
chainloader (hd32)

title 3, Boot ISO
find --set-root /ghost/msdos71s.iso
map /ghost/msdos71s.iso (hd32)
map --hook
chainloader (hd32)

Last edited by xiaoyunwang on 2008-10-15 at 13:25 ]

Error, specific information should be provided.

The error phenomenon is (the four methods are all similar, and when not in the command line, the ISO can be started successfully!):
Please, if you want to manually input and start the .ISO image under the command line successfully (while manually inputting and starting .IMG/.IMA is all right).

Specific reasons and solutions, etc. Wait for the author's reply.
Don't understand.

Still thank Lianjiang brother, many of my problems are mostly helped by you, thank you so much!!!!!
I thought I learned a little after reading the Grub tutorial, but I really didn't expect that there were problems everywhere in practical application. It seems that the idea of organizing batch scripts under pure DOS to search for .ISO images and hand them over to Grub4DOS to start .ISO images in the way of grub --config-file="file path" is in vain (starting .ima/.img is of course okay). When will "Budian" see this post? Waiting...

The problem is solved, and this has really messed me up. There's a feeling of wanting to cry but also being surprised. I just tested it on a real computer, and everything is fine, all passed. Starting the .ISO in any way is successful. VPC can really mess people up sometimes (especially when searching everywhere for the reason)...

The following problem is still not solved...
I need to boot the first partition, and the modifications made to the system after booting are invalid after restart. My computer (I810PE motherboard, 128 MB memory, XP system) including on VPC, no matter how I use the following code block, it can't boot. Please help, thanks. Now there's "Power Shodw Shadow System" which protects the C drive and restores it after restart. I believe the virtual simulation function of Grub4DOS can also achieve the same function as the shadow system when booting the system, but I don't know how to write it. I want to use this function of Grub4DOS to protect my C drive. The following writing is theoretically feasible, but actually it can't boot. Please help from Grub experts.

title boot partion
map --mem (hd0,0)+1 (hd0)
map (hd0) (hd1)
map --hook
rootnoverify (hd0,0)
chainloader (hd0,0)+1

Last edited by xiaoyunwang on 2008-10-15 at 13:30 ]

Your image shows grub4dos 2007-08-17, when grub4dos didn't have ISO emulation function yet.

To protect drive C, it is recommended to try Wulpan Angel.

The emulation of grub4dos can only work in real mode. When it comes to protected mode, it doesn't work. So you can't protect your hard drive.

Hehe, speak of the devil and he appears. Thanks to Budian's reply. The real computer has a DOS toolkit installed, using Grub4DOS from October 2008. The virtual computer uses a randomly extracted one, and I didn't pay attention to the year, which differs greatly.

I really want to understand the reason. I encountered the above problem in a real situation. It seems that Wushang Angel can't protect the boot sector. According to my understanding, as long as the ISO file is set to read-only permission, it should be able to prevent viruses in the ISO.

Last edited by fliger on 2009-1-30 at 19:53 ]

I heard that there is a way to install the system on drive D, and then use XP's own partition redirection function - in Disk Management, virtualize drive D to drive C. In this way, no matter how rampant the virus is, it is actually written in a fake location, so this can prevent viruses, but I haven't tried how to redirect the system partition yet. Note that the partition to be protected must have its drive letter deleted after redirection.

Originally posted by fliger at 2009-1-30 07:58 PM:
I heard that there is a way to install the system on drive D, and then use XP's own partition redirection function - in Disk Management, virtualize drive D into drive C. In this way, no matter how rampant the virus is, it is actually writing to a fake...

This method is theoretically good, but I wonder if anyone has tried it and how it feels?