China DOS Union

Originally posted by Budian at 2006-6-14 08:05 AM:
wengier: After displaying the information you mentioned, the following one of two messages should be displayed:

Gate A20 is turned on successfully.

Or

Failed to turn on Gate A20!!

Do you mean that it starts to slow down from displaying this message? Then it should be the control of A20 that affects the behavior of the virtual machine. It should belong to a BUG of the virtual machine. Because our control of A20 has not touched the system clock. I have another BUG in qemu, that is, the arrow keys (that is, the direction keys) have lost their function. The binary program just released at http://grub4dos.jot.com/ solves the problem in qemu. I don't know if it also solves the problem in vmware. Please report.

Hmm, I tried the latest version again and found that this problem in VMWare has also been solved, which shows that it is caused by this BUG. However, I still found a problem (also occurs in VPC), that is, /menu.lst cannot be found (the MENU.LST file is located in C:\), but (hd0,0)/menu.lst can. For example, when starting GRUB.EXE without specifying any command-line parameters or specifying --config-file=/menu.lst at the command line, it will fail (and then automatically enter the GRUB command line), while specifying --config-file=(hd0,0)/menu.lst at the command line can display the menu in menu.lst normally.

I just tried it, and my problem has been solved! I wonder when the Chinese version will be available?

There is also the problem that the original GRUB would turn off the numeric keypad light during startup, which has been solved!

But now why does /menu.lst execute unconditionally? If there is an internal menu in /menu.lst, the menu won't appear. What's the matter here?

wengier： The issues you mentioned, I will take another look.

qwe1234567：Don't wait for the Chinese version. It is estimated that pre6 will be released soon.

It is designed like this. When menu.lst and GRLDR are in the same partition and the same root directory, it will be executed preferentially; that is, it needs to be checked and executed before preset_menu.

－－－－－－－－－

This is not over yet. You still need to continue testing. I will come here to report after making changes. The one you just downloaded is a most conservative version, with all the instructions related to restarting the keyboard in the A20 control removed. Your machine is normal, but the machine with a USB keyboard may be in trouble. So, some settings need to be turned on again to see how to take care of more machines. This may have to be repeated many times.

Can pre5 be removed? If there's anything we need to continue testing, just let us know!

Just uploaded a Chinese version just now, you can use it for now. I'm waiting for the test situation of DVHZ. I'll make corresponding adjustments according to his test.

Okay, the issues with DVHZ and qwe1234567 have been completely resolved. Thanks to both of you for your hard work and great assistance! Now the issue with wengier is still not resolved. This problem is still very stubborn, more stubborn than the one qwe1234567 mentioned. Similarly, if this problem occurs on my machine, I'm fairly confident I can solve it. But when it occurs on someone else's machine, I lack the means to debug.

The cause of this problem should be a defect in the design of GNU GRUB. After GNU GRUB reads the disk sectors, it buffers the read tracks, that is, keeps a copy in memory so that when reading the same disk space next time, access to the disk can be avoided.

However, this mechanism causes very many bugs, and such bugs are very hidden. The reason GNU GRUB lost to LILO has three fundamental causes (in my view): one is the A20 gate control problem, one is the various adverse consequences brought about by the tortuous boot route (hidden bugs and many of them), and the other is the poor disk buffer design. So far, the first two problems have been relatively well solved in GRUB4DOS. If we can remove this last obstacle, then it will clear the way for the popularization of GRUB4DOS.

In fact, the phenomenon of continuous access to the same disk file in GRUB is not common, so disk buffering is actually unnecessary, and it doesn't bring enough benefits to disk access. Instead, it's a burden because there's an extra step: not only does it need to reserve precious memory for the buffer, but also copy the disk sectors to the buffer, which actually slows down disk access efficiency.

It can be seen that if the赘肉 of disk buffering is cut off, then the code structure and memory usage of GRUB can be more streamlined, more reasonable, and more efficient. But this is a problem we can consider in the future, and we can't focus on this now.

－－－－－－－－－－

If wengier can create a disk image to repeatedly reproduce this problem, it will be easier to solve, because I can debug it in person. Or, if wengier has time, he can also debug it himself. The debugging starts from stage2.c, where there is the following code:

/* Try config_file */
if (*config_file)
is_opened = grub_open (config_file);

First, we should add a print statement after this to see whether the operation of grub_open is successful or failed (it should have failed, otherwise there wouldn't be a problem; but we still need to print it to confirm).

Since it has failed, we need to trace into the function body of grub_open, add other print commands inside, and see which statement causes grub_open to return the 0 value representing failure. If other functions are called, we continue to trace in, and in this way, step by step, repeatedly test, and follow the thread, we can always find out that bug.

The Chinese version has been received.

Now I have another question. That is, if you boot the hard drive from the Coco boot CD, and if you don't press the direction keys to make the built-in menu stop and manually select the correct search path, GRUB will enter the GRUB command prompt and display:

find --set-root /menu.lst

Error 17: File not found
Booting 'find /boot/grub/menu.lst'

fallback 2
find --set-root /boot/grub/menu.lst
Error 17: File not found
Booting 'find /grub/menu.lst'

fallback 3
find --set-root /grub/menu.lst
(hd0,4)
Filesystem type is fat, partition type 0xb
configfile /grub/menu.lst

About to reset the boot drive. Report bug if the machine hangs here.

GNU GRUB version 0.97 (639K lower / 130048K upper memory)





grub>

Can this problem be solved?

[ Last edited by qwe1234567 on 2006-6-15 at 15:14 ]

Let me analyze. I failed to find /menu.lst and /boot/menu.lst in the hard disk, so they should not exist.

/grub/menu.lst was found, and it is in the (hd0,4) partition, which is the first logical partition.

When executing configfile /grub/menu.lst, an unknown error occurred, resulting in the failure to open this file.

Therefore, I feel that this BUG is the same as what wengier said. Can you make a hard disk and CD image so that I can also reproduce this situation?

After making the image, it should be run in your own virtual machine first to be sure that this error can be reproduced, and then it can be sent to me.

From your description, I am more and more convinced that the disk buffer of GRUB should be removed! The drawbacks it brings are simply endless and endless.

Well, for this problem, you can just use the hard disk image I gave you last time. For the CD image, you can find any one randomly. Anyway, as long as you boot from the CD and then choose to boot from the hard disk!

Originally posted by Buddha doesn't light at 2006-6-15 03:52 PM:
Let me analyze. It failed to find /menu.lst and /boot/menu.lst in the hard disk, so they should not exist.

/grub/menu.lst was found, and it is in the (hd0,4) partition, which is the first logical partition.

When executing configfile /grub/menu.lst, an unknown error occurred, resulting in the failure to open the file.

Therefore, I feel that this BUG is the same as what wengier said. Can you make a hard disk and CD image so that I can also reproduce this situation?

After making the image, you should first run it in your own virtual machine to be sure that this error can be reproduced, and then you can send it to me.

From your description, I am more and more convinced that the disk buffer of GRUB should be removed! The disadvantages it brings are endless, without end.

Hehe, basically this is the case. After some tests and research, I was going to come and talk about the specific situation now, but I didn't expect qwe1234567 to say it first (mainly because I was too busy these days, and I just had a little time to continue testing). The menu.lst is on C:\, that is, on (hd0,0)/. The implementation method is very simple. For example, use the CD version of the MS-DOS 7.10 full installation version to boot, select 3 to boot from the hard disk after the boot menu appears, and then run GRUB after booting, and this result will appear, and it will definitely appear.

Originally posted by Wengier
Well, I tried the latest version again and found that this problem in VMWare has also been resolved, which shows that this bug is the cause. However, I still found a problem (also occurs in VPC), that is, /menu.lst cannot be found (the MENU.LST file is located in C:\), but (hd0,0)/menu.lst can. For example, when starting GRUB.EXE without specifying any command-line parameters or specifying --config-file=/menu.lst at the command line, it will fail (and then automatically enter the GRUB command line), while specifying --config-file=(hd0,0)/menu.lst at the command line can display the menu in menu.lst normally.

What you said, is the problem the same as what I said?

Originally posted by qwe1234567 at 2006-6-15 14:59:
It is just that if you boot the hard drive from the Coco boot CD

find --set-root /menu.lst

Error 17: File not found
Booting 'find /boot/grub/menu.lst'

fallback 2
find --set-root /boot/grub/menu.lst
Error 17: File not found
Booting 'find /grub/menu.lst'

fallback 3
find --set-root /grub/menu.lst
(hd0,4)
Filesystem type is fat, partition type 0xb
configfile /grub/menu.lst

About to reset the boot drive. Report bug if the machine hangs here.

I often encounter this phenomenon. Also, IMG files with grub installed cannot be booted from the CD. It seems that EasyBoot is excluded. Using stage1 and stage2 of 0.95 to make an EasyBoot bootable IMG works. Maybe I'm just inexperienced. I've read many such posts and tried several methods, but 0.97 still can't run on the CD.
In the past few days, I installed a virtual machine and felt that batch processing or a certain program still needs to consider whether it can run in the virtual machine, which I'm not used to. Compared with that, BuDian DaShi is much more great!

Originally posted by qwe1234567 at 2006-6-16 08:19 PM:

The problem you mentioned doesn't seem to be the same as what I said, right?

It seems to be the same. It's just that I said it first. When I was about to report the situation in detail, you spoke again.