China DOS Union

No. They must be placed in the root directory of drive C:.

Our BOOTGRUB and GRLDR files will not become invalid because of disk defragmentation or file relocation. As long as they exist, they will definitely work. This is something the original GNU GRUB could not do.

In the original GNU GRUB, the real program code is in the stage2 file. As long as the physical sectors occupied by the stage2 file change, GRUB will no longer boot (if GRUB is in the MBR, this will cause the whole system to be unable to boot from the hard disk).

Our BOOTGRUB and GRLDR files only need to be in the root directory of drive C:. No matter how the disk is defragmented, they are unaffected. This should be considered very ideal. "No complicated installation needed, just copy and use"—this is a huge advantage of our GRUB for DOS and GRUB for NTLDR.

Even Microsoft's NTLDR and BOOT.INI, etc., must also be placed in the root directory of drive C:. Being located in the root directory of drive C: is not inconvenient at all. Wherever NTLDR and BOOT.INI are, our GRLDR and BOOTGRUB are there too.

GRLDR must be placed in the root directory of the boot disk, but BOOTGRUB can be placed anywhere.

The following is quoted from 不点 on 2004-2-10 22:28:17:
No. They must be placed in the root directory of drive C:.

Our BOOTGRUB and GRLDR files will not become invalid because of disk defragmentation or file relocation. As long as they exist, they will definitely work. This is something the original GNU GRUB could not do.

In the original GNU GRUB, the real program code is in the stage2 file. As long as the physical sectors occupied by the stage2 file change, GRUB will no longer boot (if GRUB is in the MBR, this will cause the whole system to be unable to boot from the hard disk).

Our BOOTGRUB and GRLDR files only need to be in the C： drive root directory. No matter how the disk is defragmented, they are unaffected. This should be considered very ideal. "No complicated installation needed, just copy and use"—this is a huge advantage of our GRUB for DOS and GRUB for NTLDR.

Even Microsoft's NTLDR and BOOT.INI, etc., must also be placed in the C： drive root directory. Being located in the C： drive root directory is not inconvenient at all. Wherever NTLDR and BOOT.INI are, our GRLDR and BOOTGRUB are there too.

Dear TinyBit,

If I use Grub for DOS to install its MBR to my bootable hard disk, does it still hold true
that fragmentation and change of location of Boot Grub & GRLDR still works?

I tried it. When the WINDOWS 2003 boot disk (drive C) is in NTFS or FAT32 format, the sixth version can boot normally in both cases. It just doesn't support NTFS, so there is no way to use the menu config file on drive C:. It can only enter the command line.

Actually, it is true that GRLDR must be placed in the root directory of drive C:, but BOOTGRUB can be placed in any directory on C:.
You only need to add this in BOOT.INI:
C:\XXXX\BOOTGRUB="GRUB boot"
XXXX is the path to BOOTGRUB.

I wonder what everyone thinks.

Very simple: windows 2003's osloader loads bootgrub, so bootgrub can be placed anywhere, as long as osloader can find it.

You brothers have sharp eyes indeed; I really admire it, hehe.

Yes, bootgrub can be placed anywhere, and it doesn't matter even if it is renamed to anything, as long as NTLDR can find it. However, there is also an exception: I put BOOTGRUB and GRLDR on a floppy disk, and using A:\BOOTGRUB="......." in BOOT.INI did not work. It seems NTLDR could not find the A:\BOOTGRUB file.

－－－－－－－－－－－
Reply to brother windrv:
> If I use Grub for DOS to install its MBR to my bootable hard disk, does it still hold true that fragmentation
> and change of location of Boot Grub & GRLDR still works?

When you use GRUB for DOS or GRUB for NTLDR to install GRUB into the MBR, the GRUB in the MBR is then completely separate from GRUB for DOS and GRUB for NTLDR.

The GRUB in the MBR actually uses the (hd?,?)/boot/grub/stage2 file, and no longer uses GRUB.EXE and GRLDR. Therefore, disk defragmentation may move the stage2 file, causing system boot failure.

GRUB.EXE and the BOOTGRUB and GRLDR files are not affected by disk defragmentation. No matter how they are defragmented, they can work. The precondition is: for GRUB.EXE, it must be able to boot into DOS real mode; for BOOTGRUB and GRLDR, it requires that NTLDR can be started.

In this sense, compared with other boot methods, GRUB for DOS and GRUB for NTLDR are a relatively safe boot method.

－－－－－－－－－－－

Thanks to brother SunSpring and brother Chenall for the reports of successful booting under win xp/2003 NTFS/FAT32! We can now safely release GRUB for DOS 0.2.0. Please be patient a little longer, keep calm, and wait a bit more to see whether anyone reports any other BUGs.

Also, FreeDOS 2033 can boot GRUB.EXE too; I tested this myself.

"Yes, bootgrub can be placed anywhere, and it doesn't matter even if it is renamed to anything, as long as NTLDR can find it. However, there is also an exception: I put BOOTGRUB and GRLDR on a floppy disk, and using A:\BOOTGRUB="......." in BOOT.INI did not work. It seems NTLDR could not find the A:\BOOTGRUB file."

NTLDR does not support the "A:" path. However, according to my last test, if files like NTLDR and BOOT.INI are all on drive A, then if you use "C:" in place of "A:", NTLDR can successfully start the corresponding Boot Sector specified in BOOT.INI from drive A.

There is indeed no problem starting GRUB for DOS under FreeDOS Kernel 2033; I also tried it yesterday. It's just that my connection speed here was very slow yesterday, so I didn't report it here, sorry.

No wonder my grub boot that had been working fine (with the .dat in the MBR stored under C) suddenly became invalid for no reason—so it was defrag...

For GRUB that uses stage2 as the actual program code, there are many reasons why it can fail:

1. Disk defragmentation causes the physical sectors occupied by the stage2 file to move.

2. If the stage2 file is deleted and then another stage2 file is copied back in, it generally also won't work, because there is no guarantee that the new stage2 file will happen to be placed exactly in the original sector positions.

3. When you use partitioning software to readjust partitions, for example adding or removing partitions, the partition numbers change, causing GRUB to be unable to find the stage2 file, and it will also fail.

Therefore, on machines with DOS and WinNT, the most convenient thing is to use GRUB.exe or GRLDR.

The following is quoted from 不点 on 2004-2-10 22:28:17:
No. They must be placed in the root directory of drive C:.

Our BOOTGRUB and GRLDR files will not become invalid because of disk defragmentation or file relocation. As long as they exist, they will definitely work. This is something the original GNU GRUB could not do.

In the original GNU GRUB, the real program code is in the stage2 file. As long as the physical sectors occupied by the stage2 file change, GRUB will no longer boot (if GRUB is in the MBR, this will cause the whole system to be unable to boot from the hard disk).

Our BOOTGRUB and GRLDR files only need to be in the C： drive root directory. No matter how the disk is defragmented, they are unaffected. This should be considered very ideal. "No complicated installation needed, just copy and use"—this is a huge advantage of our GRUB for DOS and GRUB for NTLDR.

Even Microsoft's NTLDR and BOOT.INI, etc., must also be placed in the C： drive root directory. Being located in the C： drive root directory is not inconvenient at all. Wherever NTLDR and BOOT.INI are, our GRLDR and BOOTGRUB are there too.

Why is it that after installation, when Grub boots from the MBR, it uses stage2 rather than GRLDR? If it used GRLDR, would it then no longer be affected by defragmentation?

The installer is a built-in function of GNU GRUB. It only uses those stage files under the boot/grub/ directory. There is no way for us to change that.

Since our GRUB for DOS/NTLDR requires the system to be able to boot into a certain state , our GRUB for DOS/NTLDR cannot be installed directly into the MBR. But you can also try this as an experiment:

Put the program code of BOOTGRUB into the MBR, but keep the partition table at the end of the MBR , and do not damage the partition table . In this way, our GRUB for NTLDR can be started from the MBR instead of from the NTLDR menu. Since we still use GRLDR, doing it this way is not affected by disk defragmentation.

＝＝＝＝＝＝＝＝＝＝＝＝＝＝

Background images are now supported; please download and test:
ftp://211.100.7.71/incoming/grub_for_dos-0.2.0pre2.tar.gz

This time support for splash image backgrounds has been added. After extracting, you can find the program files with splashimage functionality in the splash directory.

This test is mainly to see whether the splashimage background works properly. Note: you should use the files in the splash directory for testing.

I just downloaded it and tested it a bit (note: all on a real machine), and found that both the GRLDR file with splashimage support and the one without splashimage support still seem to have some problems. Specifically:

When BOOTGRUB is used to call GRLDR on that large hard disk from last time, the system goes to a black screen, and the cursor blinks in the upper-left corner of the screen with no response;

When BOOTGRUB is used to call GRLDR on that small hard disk from last time, the menu does appear, but no matter which item is selected, the following error message always appears:

Selected Partition does not exist.

But if GRLDR is replaced with the first version (the GRLDR from 2004-1-23), then everything works normally.

I also tested GRLDR (on the small hard disk) and GRUB.EXE in the splashimage directory, but when I entered the splashimage command, it showed "Unrecognized command". I don't know why.

Also, I suggest including an XPM test image in the splashimage directory for everyone to test with. How about that?

The following is quoted from 不点 on 2004-2-13 1:26:32:
The installer is a built-in function of GNU GRUB. It only uses those stage files under the boot/grub/ directory. There is no way for us to change that.

Since our GRUB for DOS/NTLDR requires the system to be able to boot into a certain state , our GRUB for DOS/NTLDR cannot be installed directly into the MBR. But you can also try this as an experiment:

Put the program code of BOOTGRUB into the MBR, but keep the partition table at the end of the MBR , and do not damage the partition table . In this way, our GRUB for NTLDR can be started from the MBR instead of from the NTLDR menu. Since we still use GRLDR, doing it this way is not affected by disk defragmentation.

＝＝＝＝＝＝＝＝＝＝＝＝＝＝

Background images are now supported; please download and test:
ftp://211.100.7.71/incoming/grub_for_dos-0.2.0pre2.tar.gz

This time support for splash image backgrounds has been added. After extracting, you can find the program files with splashimage functionality in the splash directory.

This test is mainly to see whether the splashimage background works properly. Note: you should use the files in the splash directory for testing.

Actually, it is possible to modify GNU GRUB's install command... but that part would have to be rewritten.....

The following is quoted from Roy on 2004-2-13 7:11:36:

The following is quoted from 不点 on 2004-2-13 1:26:32:
The installer is a built-in function of GNU GRUB. It only uses those stage files under the boot/grub/ directory. There is no way for us to change that.

 Since our GRUB for DOS/NTLDR requires the system to be able to boot into a certain state , our GRUB for DOS/NTLDR cannot be installed directly into the MBR. But you can also try this as an experiment:

 Put the program code of BOOTGRUB into the MBR, but keep the partition table at the end of the MBR , and do not damage the partition table . In this way, our GRUB for NTLDR can be started from the MBR instead of from the NTLDR menu. Since we still use GRLDR, doing it this way is not affected by disk defragmentation.

 ＝＝＝＝＝＝＝＝＝＝＝＝＝＝

 Background images are now supported; please download and test:
 ftp://211.100.7.71/incoming/grub_for_dos-0.2.0pre2.tar.gz

 This time support for splash image backgrounds has been added. After extracting, you can find the program files with splashimage functionality in the splash directory.

 This test is mainly to see whether the splashimage background works properly. Note: you should use the files in the splash directory for testing.
 

Actually, it is possible to modify GNU GRUB's install command... but that part would have to be rewritten.....

Dear TinyBit & Roy,

Such modification is an essential item as it can free us from depending on the use of another intermediate agent, i.e. DOS or NTLDR, for booting up an image file containing a bootable disk image.

Could TinyBit do us a favour to give higher priority to this item?

I had wanted to wrap this up earlier, but I didn't expect several things to pop up all at once.

1。 What brother SunSpring said brought up the topic of calling GRLDR from the MBR. Brother Roy said that by modifying the GNU GRUB program, this goal could be achieved.

2。 Brother windrv even hopes to break away completely from intermediaries like DOS and NTLDR, and run our GRUB code directly from the MBR, rather than stage2.

These really are issues I had not thought of. Brothers, I truly admire you, have been inspired, and also thank you for the discussion.

3。 wengier still has problems when using FAT16. But those using FAT32 and NTFS all passed.

4。 splash still left out some things, so it doesn't work.