中国DOS联盟

Thanks, Mr. Budian. I used WinHex to overwrite the 4th sector of grldr with the first sector of the floppy disk, and restored the original positions of the 60 bytes from the 3rd to the 62nd in the first sector of the floppy disk that I had saved in advance. It started successfully in the virtual machine, but then another problem arose. I found that when making this image into a bootable CD, it couldn't start in the virtual machine, while the previous image made using the stage1, stage2 method started smoothly in the virtual machine. Also, after using the virtual floppy drive vFloppy to boot virtually, the following items are unavailable:

title Boot from image file (hd0,0)/floppy.img
map --mem (hd0,0)/floppy.img (fd0)
map --hook
chainloader (fd0)+1
rootnoverify (fd0)
title Smart Boot Manager
map --mem /sbm.gz (fd0)
map --hook
chainloader (fd0)+1
rootnoverify (fd0)
title Memtest86+
kernel /memtest.gz

Cool! grub_for_dos-0.4.0pre4 supports running image images of single partitions instead of the entire hard disk in memory for simulation! Brother Budian has worked hard!

> Successfully booted in the virtual machine, but the problem arises again. I found that when making this image into a bootable CD, it cannot boot in the virtual machine, and the menu.lst interface does not appear.

"The inability to boot" and "the menu.lst interface not appearing" are somewhat vague. Is it "booted but only entering the command line"? Or is it simply unable to boot (such as crashing)?

If it is the former, this is not too big of an issue. The new GRLDR no longer looks for boot/grub/menu.lst but only looks for menu.lst in the root directory. So if there is no menu.lst in the root directory of your floppy disk, entering the command line is correct. Now we don't need the boot/grub/ directory anymore, just delete it.

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

> There is another point. After using the grldr -style image to boot virtually with the virtual floppy drive vFloppy, the following items are no longer available.

I am currently still amazed by this problem. According to reason, it should not occur. I will next study the reason for this problem. But you can also provide more detailed information to help solve this problem. I believe that ultimately the problem should be solvable because we don't seem to find a reason for "inevitably failing" from this. Brother blue has also worked hard, thank you very much.

You can type these command sequences one by one in the command line and see which command returns a failure message.

Your first example should be successful.
title Boot from image file (hd0,0)/floppy.img
map --mem (hd0,0)/floppy.img (fd0)
map --hook
chainloader (fd0)+1
rootnoverify (fd0)

This second example, if it fails, may be due to the lack of root. Just add it as follows.
title Smart Boot Manager
map --mem (hd0,0)/sbm.gz (fd0)
map --hook
chainloader (fd0)+1
rootnoverify (fd0)This third example is the same as the second above, also lacking root, and adding it should work.
title Memtest86+
kernel (hd0,0)/memtest.gz
I'm sorry that there is currently a lack of detailed technical explanations about the operation methods of GRLDR and GRUB4DOS. Indeed, there are differences between GRUB4DOS and GNU GRUB. For example, the following point:
The location of GRLDR is active, and it is not completely fixed like stage2 (the physical sector location of stage2 is recorded in stage1 or stage1.5). Such a difference makes GRUB4DOS unable to determine its "current" drive after booting, that is, its "current" drive is an invalid concept. However, in GNU GRUB, stage1 and stage2 hard - determine the "current" boot device during setup, so it has the concept of "current". I guess, mainly this difference leads to the above problems. The solution is to explicitly set the default "current" device with the root command in the menu, or add the device name where each file is located before each file name, so that there will be no failure when opening the file.

> Cool! grub_for_dos-0.4.0pre4 supports running an image of a single partition instead of the entire hard drive in memory for emulation!

Yes, this function is already available. But I haven't fully tested this function myself. I just did the following simple test:

I successfully emulated a hard drive (hd0) using a 1.44M floppy disk image file of win98, win98dos.img.

map --mem (hd0,0)/win98dos.img (hd0)
map --hook
chainloader (hd0)+1
rootnoverify (hd0)
boot

Since the format of the floppy disk image and the hard drive partition are not much different, this also equals testing the emulation function of the hard drive partition. It seems that memdisk and other similar software haven't provided this function yet. I hope this function can bring convenience to everyone.

Brother Budian, I'm very grateful for your serious and detailed answer. Maybe my expression wasn't clear enough:
After making an Image bootable with a CD using grldr boot, when booting in a virtual machine, the machine can't boot at all after the self-check, just a black screen all the time.
Correcting: Not only the Image booted by grldr through vFloppy simulation can't use the above items, but also the Image booted by the stage1, stage2 method through vFloppy simulation can't use the above items. But as long as it's not booted through vFloppy simulation, whether it's the Image booted by grldr or stage1, stage2, used in a real floppy drive, a virtual machine floppy drive, or made into a bootable CD, the above items can all be used. I wonder if it's related to the simulation method of vFloppy itself? vFloppy seems to simulate the operation of the Image in the memdsk way, while grub uses the memdrive way, and can't nest and simulate repeatedly? I don't know if my random guess can provide you with a solution direction? Thanks!

Bu Dian bro, I've been really busy these past few days. Today I downloaded your GRLDR and it can correctly boot the GRLDR on the extended FAT partition. It's really good. And after extracting its boot sector, I can correctly load GANDLAF's Chinese GRLDR. But his doesn't support automatically finding the MENU.LST in each partition's root directory. I hope you can release a Chinese GRLDR in the final version. Also, the LST you mentioned earlier that only looks for the root directory isn't very good. I think it should look in the root directory and also automatically find the MENU.LST files in the BOOT and GRUB folders as before...

> After using grldr to boot an Image and making it into a bootable CD, when booting in a virtual machine, the machine fails to boot after POST and remains black screen all the time.

This passage is not too easy to understand. Maybe you want to be concise and save words.
Making it into a bootable CD, it should be able to boot to the GRUB state. The problem you mentioned probably means that at this time, you can no longer use this GRUB to boot a virtual simulation startup device, while booting a regular non-virtual device is normal. If this is the case, there are many possibilities, such as incorrect command sequence you used, or BIOS issues, or problematic operating system you booted, etc. If the BIOS does not support int15/eax=e820h call, or this call has a bug, or the floppy emulation part of the BIOS bootable CD-ROM itself is also problematic, then the emulation function provided by GRUB4DOS cannot be used normally. Not only is grub4dos problematic, but the same problem will also occur if you use memdisk or other similar software.

> Also, the floppy disk guided by grldr does not directly look for menu.lst, but searches for 5 or 6 os_setup, etc. before finally bringing up menu.lst. Why is it the same as the boot method of qlinux_setup.img in your ftp? qlinux_setup.img can be understood to search for os_setup immediately after booting, but why does grldr also do this?
The latest pre4 has removed these os_setup and others, leaving only /menu.lst. Even /boot/grub/menu.lst is no longer supported.

> Correct my "false alarm" yesterday: It's not only that the items above cannot be used when the image guided by grldr is simulated and started by vFloppy, but also that the items above cannot be used when the image guided by stage1 and stage2 is simulated and started by vFloppy. And as long as it is not simulated and started by vFloppy, whether it is the image guided by grldr or stage1 and stage2, when used in a real floppy drive, virtual machine floppy drive, and made into a bootable CD, the above items can be used. I wonder if it has something to do with the simulation method of vFloppy itself? vFloppy seems to simulate the operation of the image in memdsk mode, while GRUB uses memdrive mode, and nested repeated simulation is not possible? I don't know if my guess can provide you with a solution direction? Thank you!
In that case, the problem is with vFloppy itself. vFloppy is not open source software, and it is difficult for outsiders to grasp some of its deep things. So I think you should ask the developer of vFloppy to get a satisfactory answer more easily. I have known about the vFloppy software for a long time, but I have not used vFloppy myself, so I can't provide you with any help. Thank you for providing these information, which makes me have some understanding of this.

"The Image guided by grldr, after making it into a bootable CD, when booted in a virtual machine, the machine fails to boot completely after self-testing, and it's always a black screen."

That is to say, using the method you introduced to install grldr on a floppy disk and save it as an Image, this Image can start normally in a real floppy drive and a virtual machine floppy drive; but if this Image is made into a boot CD as a boot file, this CD cannot boot at all.

However, using the method of root (fd0), setup (fd0) to install /boot/grub/stage1, stage2 on a floppy disk and save it as an Image, this Image can be used in all occasions. This Image made into a boot CD as a boot file can start completely.

My question is, why does the Image guided by the grldr method fail to boot when made into a boot CD as a boot file?

After extracting its boot sector, the Chinese GRLDR of GANDLAF can be loaded correctly, but its MENU.LST that does not support automatically finding the root directories of each partition is hoped. I don't plan to make a Chinese version, at least not having time for now. I have to thoroughly support the Linux partitions. I think this is the most important. After we support Linux partitions, we are also ready to start the process of phasing out the old GNU GRUB. Our mobile search method is much more superior and robust than GNU GRUB's fixed search method and should gradually be recognized by everyone. I didn't want to say this, but there are indeed many people here concerned about Chinese localization but not very concerned about Linux. Everyone may prefer to have a Chinese localized GRUB version, so I'll just state my plan. Personally, I think Chinese localization can be considered later. Now, the support for Linux by GRLDR (installed to MBR) should be urgent. Although there are source codes for various file systems of Linux, it's not easy to support them.

In addition, what you mentioned above that only finding the LST in the root directory is not good. I think it should automatically find the MENU.LST file in the root directory and the BOOT and GRUB folders as before...

Yes, now it only supports the root directory. In the short term, this will have compatibility issues, but in the long term, it's worth it. Microsoft's habit is to put all important things related to system startup in the root directory, and I relatively agree to follow this Microsoft habit. Originally, GNU GRUB set the boot directory at /boot/grub/, which I think is not very appropriate. Maybe they have their reasons, that is, those stage1_5 files used to support various file systems are as many as more than ten. If all these many stages files are placed in the root directory, it's not very elegant, so the developer opened a directory boot to specifically store these files.

We are different now. Those stages files, none are needed, all to be discarded. We just need a GRLDR and a menu.lst, all solved. Not for other reasons, just for elegance, we have to discard the boot directory.

I'm really sorry. The grldr I used the day before yesterday wasn't the latest pre4 version. I installed the latest version onto a floppy disk today. When booting, the following interface appeared first:
find /menu.lst
enter commandline mode
After a 5-second countdown, the menu.lst interface came out. It was my false alarm, causing you trouble.
But there's still one problem that hasn't been solved. That is, saving this floppy disk as an image, using this image as the boot file to make a bootable CD, and testing it in a virtual machine still can't boot. No interface appears except the machine self-test.
If the old method is used to make an image containing stage1 and stage2, making it into a bootable CD can boot smoothly and bring up menu.lst.

> My question is, why does the Image booted by grldr fail to boot after being made into a bootable CD?

I have other things to do today. This problem probably won't be solved immediately, let's talk about it tomorrow.

> Also, I did install the latest grldr from pre4 on March 9th on a floppy disk. Before the menu.lst appeared after booting, a series of os_setup and other things appeared, and then menu.lst was called up. Therefore, I am very puzzled, please ask the reason.
This can't be. You must have made a mistake. I have tested many machines, and only find /menu.lst appears.

I'm really sorry. The grldr I used the day before yesterday wasn't the latest pre4 version. I installed the latest version onto a floppy disk today. When I booted up, the following interface appeared first:
find /menu.lst
enter commandline mode
After a 5-second countdown, the menu.lst interface came up. It was my false alarm, causing you trouble.
But there's still one problem that hasn't been solved. That is, saving this floppy disk as an image and using this image as the boot file to make a bootable CD-ROM, when tested in a virtual machine, it still can't boot. Except for the machine self-test, no interface appears.
If I use the old method to make an image containing stage1 and stage2 and make a bootable CD-ROM, it can boot smoothly.

I rechecked the code in the fourth sector of GRLDR and found no errors.

I made a CD that is booted by grldr, and it can successfully start in both the virtual machine and the real machine and enter the usual menu interface. The virtual machine I used is the qemu software. It seems that the error you encountered is probably caused by some mistake of your own. If you can confirm that it is definitely not caused by your own mistake, there may be the following some reasons:

1. The virtual machine you use cannot fully comply with the BIOS boot specification (this has been a widely recognized industry standard for many years). For example, when booting from CDROM, it cannot correctly pass DL=0 to the boot code of the floppy disk image in the CD. That is to say, the BIOS of the virtual machine has a bug.

2. The virtual machine you use cannot fully comply with the BIOS boot specification (this has been a widely recognized industry standard for many years). For example, when booting from CDROM, it cannot correctly pass the floppy disk specification data (C/H/S) to the boot code of the floppy disk image in the CD, resulting in misreading or failure when the boot code calls int13. That is to say, the BIOS of the virtual machine has a bug.

3. The CD making tool or ISO file making tool you use has an unknown (or random) bug. For example, it misplaces the floppy disk image, thus making an invalid and unbootable CD.

The general situation should be like this. Except for the above situations, there should be no other possibilities.

Brother Budian, I'm really sorry to keep bothering you. I'm testing under the virtual machine VPC 5.2 version. The disc - making tool is UltraISO. The three possibilities you mentioned don't exist. Well, I'll upload the grldr.img I made. This image is made with the latest grldr from your FTP on March 9th. It can start normally when used on a floppy drive (real, virtual, or in a virtual machine), but it can't start when made into a bootable disc. Could you please test it to see what the reason is? Open the attachment