China DOS Union

I have two large hard disk images set as the second hard disk, and it can't boot normally. It's a pity that the files are too large!

It doesn't matter. You can use qemu to run these two hard disk images first. If it succeeds, it means it's a VPC issue. If it doesn't succeed, it means it's a GRUB issue. Qemu can directly recognize VPC hard disk images, which is very convenient! Hurry up and download qemu. For example, use the following command to start the VPC hard disk image:

qemu -hda part1.vhd -hdb part2.vhd

If it's determined to be a GRUB issue, take screenshots of the operation process and post the relevant configuration files.

I'm sure it's a GRUB issue. The relevant configuration files are in the vhd file I sent you. The strange thing is that when I put MENU.LST in /BOOT/GRUB/, it errors out when it waits for it to find MENU.LST by itself, but when I press the direction key during startup to stop the built-in menu and then manually select to find /BOOT/GRUB/MENU.LST, it works normally. When I put MENU.LST in /GRUB/, it errors out when it waits for it to find MENU.LST by itself, but when I press the direction key during startup to stop the built-in menu and then manually select to find /GRUB/MENU.LST, it works normally. It seems like there's automatic error correction!

And this problem, Administrator Wengier must have encountered it too, and my real machine also has the same problem. If it's a problem with VPC, then how to explain that my real machine has the same problem?

Just to say again, the error message I posted at the top of the thread was copied directly from the screen of VPC!

Then I'll also state my view. If it's a problem with GRUB, then no matter what machine or what virtual machine you use to run the same hard drive, it should have an error. As long as there is a virtual machine or a real machine that doesn't have a problem on the same hard drive, it means it's not the fault of the **software** of GRUB, but related to the hardware. To determine if it's a software error of GRUB, we'd better test on different virtual machines (also available with multiple real machines, but it's too cumbersome and unrealistic, so just forget it). The purpose of the test is to rule out the possibility of hardware errors. Therefore, both qemu and vmware should be tested. If neither works, then it can be considered that it's a GRUB error.

Then I'll post a few pictures of errors when searching automatically, you can take a look!

For the sake of completeness, both things need to be done: one is to use a virtual machine like qemu, and the other is to take a screenshot. Now you've done the second thing, and it's best to do the thing with another virtual machine too, which is beneficial.

From the posted image, the /grub/menu.lst file was found, but an error occurred when opening this file. This should be a GRUB error. So, we need to technically find out where the specific error is.

This error message means that the BIOS does not support LBA and can only access hard disk files in CHS mode. When accessing the sectors of the hard disk file in CHS mode, the cylinder number is too large, so it fails.

However, since you can open the same file at the command line, this is not caused by a BIOS error, but by GRUB making a mistake itself. We just need to locate exactly where GRUB got confused?

I just used qemu to boot the same two files and got the same error!

Judging from the screenshot, the /grub/menu.lst file was found, but an error occurred when opening this file. This should be a GRUB error. So, we need to technically find out where the specific error is.

As for /grub/menu.lst, it should have nothing to do with whether it was found or not, because the search command has not yet appeared on the screen. If it were normal, the search command would appear on the screen. (Because I manually selected to search for /BOOT/grub/menu.lst and it also went wrong! (/BOOT/grub/ does not have menu.lst)

[ Last edited by qwe1234567 on 2006-6-13 at 12:54 ]

After I press the arrow keys during startup to stop the built-in menu, manually selecting to look for /GRUB/MENU.LST works normally, but if I press the arrow keys during startup to stop the built-in menu, manually selecting to look for /boot/GRUB/MENU.LST doesn't work, and it has the same error as when letting it automatically find MENU.LST. That is, if there is no MENU.LST in the specified search path, I can't boot MENU.LST from the built-in menu!

What you said makes sense. It seems you are meticulous. That is to say, the Error 20 occurred before the find --set-root /grub/menu.lst was printed. I also found another problem. These will take some time to figure out. You take a few days off first. I'll let you know when I have time to work out a result.

Okay! I'm waiting for your good news!

Originally posted by Budian at 2006-6-13 09:17 AM:
Let me also share my view. If it's a GRUB issue, then no matter what machine or virtual machine you use to run the same hard drive, it should encounter an error. As long as there is one virtual machine or a real machine that doesn't have a problem with the same hard drive, it means it's not the fault of the **GRUB software**, but related to the hardware. To determine if it's a GRUB software error, we'd better test on different virtual machines (using multiple real machines is too cumbersome and impractical, so let's omit that). The purpose of the test is to rule out the possibility of hardware errors. Therefore, both qemu and VMware should be tested. If neither works, then it can be considered a GRUB error.

When I run GRUB.EXE with VMWare here, after the screen shows the following content, the text on the screen is actually displayed one letter at a time (the interval between displaying each two letters is about half a second to 1 second), making it completely impossible to use normally. This is the case even when no other programs are loaded.

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

Return from int13/AH=0. The reset of the boot drive is OK.

About to enable gate A20. Report bug if the machine hangs here.

What version is yours?

wengier: After displaying the information you mentioned, one of the following two messages should be displayed:

Gate A20 is turned on successfully.

Or

Failed to turn on Gate A20!!

You mean it started 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 in 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 arrow 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.