Jump to content











Photo
- - - - -

How do I boot Grub4DOS from VHD in PCem?


  • Please log in to reply
41 replies to this topic

#1 Gerolf

Gerolf

    Member

  • Members
  • 75 posts
  •  
    Germany

Posted 07 April 2021 - 12:12 AM

Do I observe correctly that it is not possible to boot Grub4DOS from VHD in PCem due to a gate A20 hickup?

 

While I'm pretty content with VirtualBox and Qemu, I also want to get acquainted with the other virtualizers and emulators around.

 

So I read a PCem tutorial:

https://www.betaarch...pic.php?t=40232

and downloaded PC Emulator:

https://pcem-emulato.../downloads.html

and the required ROM files:

https://github.com/B...aRain/PCem-ROMs

and the latest "classical" Grub4DOS:

http://grub4dos.chen....6a-2021-01-27/

and an MS-DOS 6.22 boot disk:

https://archive.org/details/dos-6.22

and ImDisk Toolkit to access virtual disks:

https://sourceforge..../imdisk-toolkit

 

In PCem, I tested various machines, e.g. "Intel Premiere/PCI" with "Pentium OverDrive 133" CPU and AMI BIOS. As new primary master hard disk, I created a 10 MiB type 01 fixed-sized VHD image.

 

I mounted the DOS boot image as ImDisk Virtual Disk in Windows Explorer context menu and copied the Grub4DOS files BOOTLACE.COM and GRLDR onto it.

 

In the BIOS setup of the emulated machine, I changed the booting order to start with the floppy. I booted to the MS-DOS command line, ran FDISK to create a primary partition, and FORMAT C: to create a FAT12 file system.

 

However, I do not want to install MS-DOS. For a software project, I want to boot to Grub4DOS from VHD. So I entered the commands BOOTLACE 0x80 (to install the Grub4DOS master boot record) and COPY GRLDR C:.

 

If I add my newly created VHD image to the Virtual Media Manager in VirtualBox and then create a new virtual machine with this VHD image attached to, it boots to the Grub4DOS command line, as expected. The same in Qemu and Bochs.

 

But not in PCem. I get a first message from Grub4DOS: "Try (hd0,0): FAT 12:", and then it hangs saying "A20 Debug: C806 done! ...", no matter what configuration changes I try.

 

So I cannot even use the "--disable-a20" option in the chainloader line or the "map --a20-keep-on=0" command which are mentioned in README_GRUB4DOS.txt. Which leads to my initial question. Do I have to forget about PCem for my purpose?

 

Gerolf

 

 



#2 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 07 April 2021 - 12:09 PM

Try first using NOT the grub4dos MBR loader (the code in grldr.mbr that is installed to the MBR and first few sectors).

 

I.e. make a normal DOS boot image, and then try running from it grub.exe.

 

Then try using a different mechanism to load the grldr, such as the "normal" Win2K/XP MBR + NTLDR+BOOT.INI or the Syslinux or the PloP.

 

It is possible :unsure: that  the issue is in the grldr.mbr, of course, if it is in the actual grldr or in the grub.exe (or both) there won't be any change.

 

:duff:

Wonko 



#3 Gerolf

Gerolf

    Member

  • Members
  • 75 posts
  •  
    Germany

Posted 07 April 2021 - 10:16 PM

Thank you for answering, Wonko!

 

Well, I prepared a second VHD like the first, except when booting PCem from the attached DOS floppy, I said FORMAT C: /S instead of BOOTLACE 0x80. Then I copied GRUB.EXE to the VHD using ImDisk.

 

When PCem boots to DOS from this second VHD and I enter GRUB at the command line, all I get is a blinking cursor in the upper left corner. The same with BADGRUB.EXE, which requires the experiment to be repeated with a third VHD under MS-DOS 7+ or FreeDOS.

 

However, when I boot a new VirtualBox VM from either of both VHDs, I can run GRUB.EXE and get to the Grub4DOS command line, as should be.

 

Then, as you suggested, I prepared a fourth 10 MiB VHD (now with C/H/S=21/16/63 instead of 301/4/17 like before, 180 KiB larger) and attached it to a Windows XP virtual machine in VirtualBox. I ran DISKMGMT.MSC to use that tool for the partitioning, but opened the terminal window to FORMAT F: /FS:FAT. I also entered ATTRIB -H -S C:\BOOT.INI and ATTRIB -H -S C:\NTLDR to be able to copy both files to the VHD.

 

Using ImDisk, I copied GRLDR to the VHD and added the line 'C:\GRLDR="Start GRUB"' to BOOT.INI. I opened the VHD in TinyHexer to set the active bit (byte 0x80 at MBR offset 0x1BE).

 

Now, when I boot a new VirtualBox VM from the fourth VHD, I come to the NTLDR boot menu and, after selecting the second entry, to the Grub4DOS command line, as should be.

 

I also come to the menu when I boot PCem. Guess what happens when I select the second entry? Grub4DOS says: "A20 Debug: C806 done! ..." Intuition says it will be the same with Syslinux and PloP.

 

Gerolf



#4 Gerolf

Gerolf

    Member

  • Members
  • 75 posts
  •  
    Germany

Posted 08 April 2021 - 12:46 AM

As mentioned in the tutorial, there is a fork project to PCem called 86Box.

 

Download:

https://ci.86box.net/job/86Box/

ROMset:

https://github.com/8...es/tag/20210324

Documentation:

https://86box.readth...ingstarted.html

 

In the Tools/Settings menu, I can configure the machine and attach the VHD images that I have created before. The resulting failures at boot time are the same as with PCem, however.

 

C'est dommage. These emulators somehow give you the "real" feeling when you step through the pages of the old AMI BIOS.

 

I forgot to add a question mark to the title of the thread, sorry.

 

Gerolf


Edited by Gerolf, 08 April 2021 - 01:14 AM.


#5 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 08 April 2021 - 12:25 PM

Yep, if it fails when going through NTLDR it means that it is the actual grldr causing the issue (and not its MBR loader),
 
About the blinking cursor with grub.exe, it is usually an issue with geometry (not necessarily in this case), the behaviour should be the same with both grub4dos and grub.exe.
 
Only to make sure, do the following to the image you already have (or a copy of it) with NTLDR+BOOT.INI (that has a valid geometry of 16/63, BIOSes can be tricky with uncommon or inappropriate geometries in the CHS values of the MBR or in the volume bootsector) mount it with IMDISK or similar and copy to it the IO.SYS, MSDOS.SYS and COMMAND.COM from a DOS 7.0 or later and also copy to it GRUB.EXE.
Then use bootpart to change the bootsector to a DOS one and add a BOOT.INI entry for DOS.
 
I am not too sure that bootpart can work on a volume mounted by IMDISK, but you can use the Windows XP virtual machine in VirtualBox that you already have.
https://www.winimage.com/bootpart.htm
 
If everything goes as it should you should be able in Pcem to boot to the BOOT.INI options, choose DOS, boot to DOS and from it run GRUB.EXE (most probably obtaining the same A20-related error).
 
There are a couple "control bytes" in grldr.mbr that you can experiment with, see the README_GRUB4DOS.TXT at chapter "grldr.mbr - Details about the control bytes " that can be hexedited or set when using bootlace, namely you could try setting as "fix" (hd0,0) and setting the geometry-no-tune (on a 16/63 image) but I don't think it may change the A20 related error.

I forgot to add a question mark to the title of the thread, sorry.

Fixed. :)
 
:duff:
Wonko

#6 Gerolf

Gerolf

    Member

  • Members
  • 75 posts
  •  
    Germany

Posted 09 April 2021 - 06:54 PM

the behaviour should be the same with both grub4dos and grub.exe.

You mean GRLDR and GRUB.EXE. I understand that you want to directly compare the booting behaviour of both files on one and the same image with a valid geometry, using NTLDR for multibooting.

 

The BootPart info stresses that "your active partition on your first hard disk must be a FAT16" one, but MS-DOS created FAT12 on my small 10 MiB VHDs, according to the 0x01 byte in the partiton table in the MBR and the text string in the volume boot record. So I made several experiments with 48 MiB VHDs (C/H/S = 97/16/63) to force FAT16B.

 

One might indeed think that BootPart were the right tool to set up the multibooting feature, as it is able to exchange DOS and Windows MBRs even in a reversible manner; but here it failed to create a boot sector from a DOS partition to be started via BOOT.INI that could do more than say "Invalid system disk" or "Cannot load from hard disk", and then return to the boot menu.

 

Anyway, Windows can do the trick automatically when installed in "historical" order. I created a 503 MiB VHD (C/H/S = 1023/16/63) and installed MS-DOS 7.0 (in PCem). Then, (in VirtualBox, for speed,) I started the Windows XP installation from an nLite'd  ISO to the existing file system until the first reboot, which was enough to create the desired multibooting functionality.

 

I mounted the VHD in ImDisk, copied GRLDR and GRUB.EXE to it, entered ATTRIB -R -S -H BOOT.INI to make that file editable, and added the line 'C:\GRLDR="GRLDR"'. So in VirtualBox, I can either select the third menu entry and start GRLDR directly, or the second one to get to the MS-DOS 7.0 command prompt and enter GRUB. In both cases, I get to the Grub4DOS command line.

 

But not in PCem and 86Box. There, the behaviour of both Grub4DOS files is not the same, though: GRLDR hangs saying: "A20 Debug: C806 done! ...", while GRUB.EXE just shows a blinking cursor in the upper left corner. But yes, if I hacked the drive/partition control bits inside GRUB.EXE, maybe I could get it to say "A20 Debug: C806 done! ...", too.

 

Gerolf



 



#7 Gerolf

Gerolf

    Member

  • Members
  • 75 posts
  •  
    Germany

Posted 09 April 2021 - 08:37 PM

The good news is: there are very old versions of Grub4DOS that do not show this error in PCem and 86Box. The NTLDR multibooting arrangement at least is fine to check this out. The oldest version I had lying around was a grub4dos-0.4.4-2009-12-03. Here, GRUB.EXE successfully boots to the command line, while GRLDR still fails, showing another strange message (not in VirtualBox):

Try (hd0,0): FAT16: No GRLDR
Try (hd0,1): invalid or null
Try (hd0,2): invalid or null
Try (hd0,3): invalid or null
Try (fd0): invalid or null
Cannot find grldr in all drives. Press Ctrl+Alt+Del to restart.

While it is no solution for me to use an old Grub4DOS because I want to make use of current features like batch programming, I could of course spend another night downloading old binaries to find out the precise date when they broke, and then a source file comparison of two consecutive versions would reveal the change that causes the error. But I am surely not the right person to look into the innards of Grub4DOS to fix any bugs.

 

By the way, I worry a little about the future of "classical" Grub4DOS, now that I read that "Grub4EFI" (as Steve wants to name it) throws out so much of the familiar functionality.

 

Gerolf
 



#8 Gerolf

Gerolf

    Member

  • Members
  • 75 posts
  •  
    Germany

Posted 10 April 2021 - 08:17 PM

PCem and 86Box are under constant development. They emulate dozens of different machines instead of just one; newer ROMs are added frequently. In a few years, today's machines will run in PCem or alike, with or without Grub4DOS support, when some old guys want to have fun playing the games of their youth.

More seriously, these slow emulators, buggy themselves, are valuable debugging tools. For instance, PCem gives a feedback on C/H/S values before VHD creation; the auto-correction restores H/S = 16/63, correlating size and cylinders. I could create a 504 MiB fixed VHD with C/H/S = 1024/16/63 and install MS-DOS 7.0 to it, but that VHD was rejected by VirtualBox. The second one, mentioned above, one cylinder smaller, got accepted there (and, to give a short "how to",  was sufficient to run the very old GRUB.EXE in PCem, without the help of NTLDR).

I see I got a status promotion to "reboot.pro member", from "newbie", but I lost permission to edit my previous posts.

 


#9 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 11 April 2021 - 08:45 AM

You mean GRLDR and GRUB.EXE. I understand that you want to directly compare the booting behaviour of both files on one and the same image with a valid geometry, using NTLDR for multibooting.

Yep :).

If you can boot to "a" grub4dos, it should be possible to chainload from it *any* later version, both with:

chainloader /<version>/grldr

boot

and

kernel /<version>/grub.exe

boot

:unsure:

 

and in the chainloader command you can try adding --disable-a20 and/or other parameters, still I doubt that it will make any difference :(

 

I wouldn't try with anything earlier than 0.4.4 10-16-2009, which is the "final" 0.4.4 version, as "first boot grub4dos version".

 

Another possibility (still with an older grub4dos version) could be using a grub4dos floppy, this way the possible issues with geometry and/or MBR setup of the hard disk are by-passed, at least in the early booting stage.

 

:duff:

Wonko



#10 Gerolf

Gerolf

    Member

  • Members
  • 75 posts
  •  
    Germany

Posted 15 April 2021 - 04:29 AM

With your chainloader proposal, I can be confident that there will be a fallback to run the current Grub4DOS in PCem. So I can still do some procrastination before starting to search the supposed bug. I am thinking about how to build a more generic testbed VHD for backward compatibility checks, one which is able to boot to the latest GRLDR on both PCem and VirtualBox. But I also have to sum up the results of my previous experiments before I forget the relevant details.

 

I kind of want to accept that this boot manager named Grub4DOS, in its current versions, can no longer rely on itself for PC backward compatibility. When saying "backward compatibility", I think of my first computer, which was a Toshiba T1100 laptop running a branded version of DOS 2.11. PC-DOS 2.0 for the IBM XT was the first version to support hard disks up to 32 MiB with FAT12 (type 0x01) file system, assuming a C/H/S = 1023/4/17 geometry. But it was already prepared to support C/H/S = 1023/16/63 geometry if only the starting cylinder was 0 and the maximum cylinder size of the 32 MiB partition just 65. The hard disk space was only available in slots, as multiples of cylinders. One cylinder held 16*63*512 B or 504 KiB < 0.5 MiB, the maximum being 32,760 KiB < 32 MiB.

 

Then PC-DOS 3.0 introduced a FAT16 (type 0x04) file system that still was limited to 32 MiB. It made FAT12 above 32 cylinders (16 MiB) incompatible by formatting partitions of 33 cylinders and more as FAT16. DOS 3.0 could only be booted from the new file system. This remained unchanged until version PC-DOS 3.2 A dual-boot system can be created, using FDISK to change the active boot partition, if the FAT12 partition starts at cylinder 0 and has a size of at most 32 cylinders. The file type in the partition table then can be changed to 0x11 (hidden), and a new FAT16 partition for PC-DOS 3.0 can be added. Its size, however, will be limited such that it sums up to 65 cylinders together with the existing FAT12 partition. This remains unchanged until MS-DOS 3.31.

 

So initially, only the first 65 cylinders could hold a bootable partition, but even a third entry in the partition table could be activated for boot if the FAT12 partition was smaller. If it was reduced to 8 MiB (16 cylinders), smaller than the original 10 MiB XT, it could still hold a running Windows 1.04. But then 16 single cylinders would become available that could be made bootable if entered individually, as primary partition, in the partition table in the master boot record. The commands MAP and (not limited to real mode) PARTNEW, according to README_GRUB4DOS.txt, can do this dynamically, simply by directing to an existing logical partition which would be unbootable from within an extended partition.

 

Those logical partitions inside an extended partition, which serves as a container to fill the forth entry in the partition table, are introduced with DOS 3.3, but still restricted to 32 MiB in size (and to the remaining letters of the alphabet for drive assignment), but make the full 503 MiB VHD accessible. It is DOS 3.31 that can make all the space available as one whole partition, introducing a third file system, FAT16B (type 0x06), for partitions above 32 MiB. DOS 3.31 is also the last version to be limited to the C/H/S = 1023/16/63 geometry. Checks for "backward compatibility", even on such a small VHD, will need to deal with all these file systems and early DOS versions, in addition to (or before) booting modern NTLDR and Grub4DOS.

 

* * *

 

0. In other words, and more like a how-to: For backward compatibility tests, create a new 503 MiB fixed-size VHD image named BACKWARD.VHD with C/H/S = 1023/16/63 geometry in PCem. Opened in TinyHexer, it is just a big bag of zeroes with an additional sector that contains a "conectix" string (and a universal identifier, which PCem happily ignores but VirtualBox takes utmost seriously). You can use FDISK of either DOS versions 2.0 to 3.31 to create the boot sector, and the executable code written by David Litton in the upper half still looks identical. Only the 4 * 16 bytes of the partition table at the four last lines, shifted forward by two bytes by the 0x55 0xAA signature, will differ; see full hex dump of the PC-DOS 2.0 MBR:

https://thestarman.p.../mbr/200MBR.htm

https://en.wikipedia...f_partition_IDs

https://en.wikipedia...n_table_entries

 

1a. Boot from a PC-DOS 2.0 disk. FDISK reports only 1022 cylinders total disk space, assigning index number -1 to the first cylinder and reserving it for the boot manager. Create a DOS partition of only 16 cylinders, starting at number 0, ending at 15, and activate it. Reboot. Enter FORMAT C: /S and COPY *.* C: to transfer the system. Eject the floppy image and reboot. PCem boots to PC-DOS 2.0 from BACKWARD.VHD. The last two lines of the master boot record, which is immediately followed by executable code, now look as follows. The partition created at first occupies the last partition table entry. It starts with the active byte 0x80 as first (offset 0x00). The type is 0x01 (FAT12) as fifth byte (offset 0x04, third on last line):

00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 00 
02 00 01 0F 3F 0F 01 00 00 00 FF 3E 00 00 55 AA 

1b. Hide and deactivate this FAT12 partition:

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
02 00 11 0F 3F 0F 01 00 00 00 FF 3E 00 00 55 AA 

2a. Boot from a PC-DOS 3.0 disk. Create a DOS partition in FDISK. Maximum available space is 49 cylinders. Enter partition size 33 cylinders starting at 16. Activate new partition 2. Reboot. Enter FORMAT C: /S and COPY *.* C: to transfer the system. Eject the floppy image and reboot. PCem boots to PC-DOS 3.0 from BACKWARD.VHD The partition table now looks as follows. The active byte sits at the same place again, which now designates the FAT16 partition (type 0x04), shifting upward one line the entry that was created first:

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
02 00 11 0F 3F 0F 01 00 00 00 FF 3E 00 00 80 00
01 10 04 0F 3F 30 00 3F 00 00 F0 81 00 00 55 AA

2b. Unhide the FAT12 partition:

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
02 00 01 0F 3F 0F 01 00 00 00 FF 3E 00 00 80 00
01 10 04 0F 3F 30 00 3F 00 00 F0 81 00 00 55 AA

Reboot to PC-DOS 3.0 from BACKWARD.VHD. Run FDISK to activate the first partition. Reboot to PC-DOS 2.0. Run FDISK to activate the second partition. Hide FAT12 partition like in 2a. Reboot to PC-DOS 3.0. This not-so-comfortable multibooting funtionality could directly be extended to DOS 3.31, which again is bootable from a small FAT12 partition, using the third primary partition entry in the table that can be made active. As said, I attempt to achieve even greater booting flexibility using logical partitons and Grub4DOS's MAP and PARTNEW commands.

 

3a. Boot from a MS-DOS 3.31 disk. FDISK offers to create either a primary or an extended partition which can be at most 973 cylinders in size, from cylinder 49 to 1021, which is just fine. Now FDISK wants to create logical drives. Instead of using the whole space for one large partition, create 16 partitions of only 1 cylinder in size (cylinders 49 to 64, drive letters D: to S:, 504 KiB each); one partition of 32 cylinders, the maximum for FAT12 (drive T: 16 MiB); and one partition of 33 cylinders, the minimum for FAT16 (drive V:). The rest of 892 cylinders then remains for a FAT16B partition (drive V:, 439 MiB) which, as FDISK warns, is inaccessible for older versions including DOS 3.3.

 

3b. After reboot from MS-DOS 3.31, drive C: is occupied with PC-DOS 3.0 files. When you enter FORMAT D: /S and COPY *.* D: to transfer the system, the disk space is insufficient, but the harder problem is: When you eject the floppy image from drive A:, PCem still reboots to PC-DOS 3.0, of course. The logical drive D: is unbootable because it is not yet directed to from the partition table, which as fourth entry only holds the extended type 0x05 partition, with one line for the third primary partition being left out:

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
01 31 05 0F FF FD F0 C0 00 00 30 F7 0E 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
02 00 11 0F 3F 0F 01 00 00 00 FF 3E 00 00 80 00 
01 10 04 0F 3F 30 00 3F 00 00 F0 81 00 00 55 AA 

So much for today. The next step involves getting Grub4DOS to run in the testbed defined by this partition table and the logical drives.

 

Gerolf



#11 Gerolf

Gerolf

    Member

  • Members
  • 75 posts
  •  
    Germany

Posted 17 April 2021 - 01:36 AM

4. Now for the test if Grub4DOS was always named correctly.

 

I wouldn't try with anything earlier than 0.4.4 10-16-2009, which is the "final" 0.4.4 version, as "first boot grub4dos version".

You cannot get exactly that one in Chenall's repository:

http://grub4dos.chen...tegories/0-4-4/

The oldest one is listed under

2009-11-26 but dates 2009-11-14. Prepare a program folder like P:\_PRO\GRUB4DOS and download to it:

http://dl.grub4dos.c...-2009-11-14.zip

Extract the archive to P:\_PRO\GRUB4DOS\grub4dos-0.4.4-2009-11-14

 

5. Change the last five lines (0x01B0 to 0x01F) of the master boot record of the 503 MiB BACKWARD.VHD with its C/H/S = 1023/16/63 geometry as follows to unhide all partitions and activate (byte 0x80, first byte of entry) the FAT12 partition (type 0x01, fifth byte of entry, second to last entry, starting two lines above 0x55 0xAA signature):

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
01 31 05 0F FF FD F0 C0 00 00 30 F7 0E 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 00 
02 00 01 0F 3F 0F 01 00 00 00 FF 3E 00 00 00 00 
01 10 04 0F 3F 30 00 3F 00 00 F0 81 00 00 55 AA 

PCem then boots up to PC-DOS 2.0. Its FDISK displays partition data as follows:

Partition Status   Type  Start  End Size
    1        N   non-DOS    16   48   33
    2        A     DOS       0   15   16
    3        N   non-DOS    49 1021  973

6. Clean up the system files from the installation in point 1a:

MD \_PRO
MD \_PRO\GRUB4DOS
MD \_PRO\GRUB4DOS\4-091114
MD \_SYS
MD \_SYS\PCD200
COPY *.* \_SYS\PCD200
DEL *.*
COPY \_SYS\PCD200\COMMAND.COM \
DIR \_SYS\PCD200

Create an AUTOEXEC.BAT to set the search path for executables. To do it the DOS way, enter COPY CON AUTOEXEC.BAT and type:

SET GRUBDIR=C:\_PRO\GRUB4DOS\4-091114
SET PATH=C:\_SYS\PCD200;%GRUBDIR%
GRUB

Then enter [F6] to close the file.
 

7. Of course, it is much easier to do the above clean-up and file creation in Windows Explorer. So mount BACKWARD.VHD, in the context menu, as ImDisk Virtual Disk. Only one partition with index 1 and file system FAT is listed in the mounting dialog, but it is the relevant one, as the size of 7.87 MiB indicates. Mount the guest system's boot partition to, say, drive G:. Complete unfinished tasks from point 6. Hidden files IBMBIO.COM and IBMDOS.COM, as well as COMMAND.COM and AUTOEXEC.BAT, must remain in the top level folder. Copy GRUB.EXE and other files possibly required for testing (GRLDR, GRLDR.MBR, BOOTLACE.COM) from P:\_PRO\GRUB4DOS\grub4dos-0.4.4-2009-11-14 to G:\_PRO\GRUB4DOS\4-091114. Unmount ImDisk Virtual Disk G: to unlock it and make it bootable again.

 

8. Reboot BACKWARD.VHD in PCem. PC-DOS 2.0 starts and autoexecutes GRUB.EXE. Press [Ctrl-C] when the emulator screen gets cleared (to stop the countdown before vainly searching for MENU.LST) and come to the fallback menu of Grub4DOS. You can enter the command line, which prompts grub> _

 

So, unlike one might have expected, a FAT12 partition (at least one with a H/S = 16/63 geometry) and (at least if that partition starts at cylinder 0) PC-DOS 2.0 indeed are enough to boot GRUB.EXE (at least in its first available version 0.4.4 of 2009-11-14). Therefore GRUB.EXE correctly got named Grub4DOS, initially.

 

How would you like to proceed?

 

Gerolf



#12 Gerolf

Gerolf

    Member

  • Members
  • 75 posts
  •  
    Germany

Posted 17 April 2021 - 06:31 PM

9. One can't be too careful. I first had copied ALL files (not just GRUB.EXE, GRLDR, GRLDR.MBR, BOOTLACE.COM) from the Grub4DOS program archive folder P:\_PRO\GRUB4DOS\grub4dos-0.4.4-2009-11-14 to the guest's target folder G:\_PRO\GRUB4DOS\4-091114 on the ImDisk-mounted BACKWARD.VHD.

 

When the disk image was dismounted, and rebooted in PCem, and GRUB.EXE was autoexecuted, and I had pressed [Ctrl-C] just in time to get to the fallback menu, and I had entered the Grub4DOS command line, and I had typed "quit" to return to the DOS command line, then I could enter the command CHKDSK. And it said, listing a lot of segments in the now C:\_PRO\GRUB4DOS\4-091114 folder:

Errors found, F parameter not specified.
Corrections will not be written do disk.
Allocation error, size adjusted.

Now I could enter CHKDSK /F, and the errors were no longer listed. But when ImDisk-remounting BACKWARD.VHD, it turned out that the long file names got truncated: README_GRUB4DOS.txt became README~1.TXT. If you do NOT enter CHKDSK /F, both long file names and CHKDSK-reported allocation errors will remain. So it seems best to truncate long file names manually on DOS-2.0-accessible file systems.
 

Gerolf



#13 Gerolf

Gerolf

    Member

  • Members
  • 75 posts
  •  
    Germany

Posted 17 April 2021 - 10:04 PM

10. The first annoying thing with PC-DOS 2.0 is the absence of a text editor to modify configuration files. Binaries of different DOS versions usually refuse to run under a "wrong" one, so download the FreeDOS editor

https://archive.org/...t_09a_/EDIT.zip

and extract the archive to, say, P:\_PRO\DOSTOOLS. Then copy EDIT.EXE to a newly created G:\_PRO\DOSTOOLS folder on the ImDisk-mounted 7.87 MiB FAT12 partition of the guest image, BACKWARD.VHD. Modify G:\AUTOEXEC.BAT as follows to make the EDIT command available:

SET GRUBDIR=C:\_PRO\GRUB4DOS\4-091114
SET PATH=C:\_SYS\PCD200;C:\_PRO\DOSTOOLS;%GRUBDIR%
GRUB

A minimum G:\MENU.LST, to judge from the example file in P:\_PRO\GRUB4DOS\grub4dos-0.4.4-2009-11-14, will be something like these few lines:

color light-gray/blue black/light-gray light-gray/blue light-gray/black

title GRUB Command Line\n\n Type [Esc] to return to menu
commandline

title DOS Command Line\n\n Enter GRUB to return to menu
quit

title Reboot
reboot

title Halt
halt

Can I add a menu option for the editor, to start EDIT.EXE, e.g. by quit'ing GRUB.EXE with a pre-defined errorlevel?
 

Gerolf
 

 

 

 

 



#14 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 18 April 2021 - 11:54 AM

Sometimes you need to look closer than you think, here is the (IMHO) "good" version of 0.4.4 (last one):

http://reboot.pro/in...showtopic=16641

http://reboot.pro/in...ds&showfile=175

 

If I get this right, you want to boot to DOS, from it run grub.exe, and from it get back to DOS and run automatically EDIT.EXE? :unsure:

 

No idea about having grub.exe exit with a given errorlevel, but wouldn't be easier (IMHO) a floppy image containing the DOS and EDIT.EXE and chainloading it?

No idea of what kind of time would it take such a "reboot" in PCem, but in Qemu or Virtual Box it should be very fast, not very different from actually invoking the EDIT.EXE from command line.

 

OT, but not much, something like (shameless plug) a COSMIAS  might do:

http://reboot.pro/to...-to-g4d-images/

http://reboot.pro/in...showtopic=17945

but it is a JFYI for future experiments as the approach needs grub4dos batch capabilities (that were implemented much later than 0.4.4).

 

:duff:

Wonko 



#15 Gerolf

Gerolf

    Member

  • Members
  • 75 posts
  •  
    Germany

Posted 18 April 2021 - 09:55 PM

wouldn't be easier (IMHO) a floppy image containing the DOS and EDIT.EXE and chainloading it?

 

11. At least PC-DOS 2.0 is fastbooting, so let's do this. EDIT.EXE has 189 KiB, the PC-DOS 2.0 image is only a 180 KiB one, so create a copy of any 360 KiB floppy image and name it PCD200ED.IMG. Mount the PC-DOS 2.0 boot image to the first floppy drive of VirtualBox and PCD200ED.IMG to the second (which seems to be unaccessible in PCem, at least under PC-DOS 2.0). Enter FORMAT B: /S. Having mounted PCD200ED.IMG as ImDisk Virtual Disk to, say, drive B:, copy EDIT.EXE to it and create B:\AUTOEXEC.BAT as follows, using old DOS syntax without backslashes, and unmount:

C:
A:EDIT C:AUTOEXEC.BAT C:MENU.LST
C:AUTOEXEC

Execution of AUTOEXEC.BAT on hard disk partition C: is necessary because the old path needed to restart GRUB.EXE will be forgotten after booting PCD200ED.IMG. ImDisk-mount BACKWARD.VHD to, say, drive G: and copy PCD200ED.IMG to G:\_SYS\PCD200. Then add the following entry to G:\MENU.LST:

title Editor\n\n Edit AUTOEXEC.BAT and MENU.LST
map --unmap=0
map (hd0,2)/_SYS/PCD200/PCD200ED.IMG (fd0)
map (fd0) (fd1)
map --hook
root (fd0)
chainloader (fd0)+1

The "map --unmap=0" command intends to prevent a mapping-stack buildup when the editor is started repeatedly. The required boot partition number (hd0,2) can be found out at the Grub4DOS prompt. A "geometry (hd0)" command returns, in accordance with PC-DOS 2.0 FDISK, but omitting partitions 0 and 1:

drive 0x80(CHS): C/H/S=1022/16/63, Sector Count/Size=1030176/512
   Partition num: 2, active,  Filesystem type is fat, partition type 0x01
   Partition num: 3, Filesystem type is fat, partition type 0x04   

The Grub4DOS version in use (0.4.4 of 2009-11-14, the oldest one in Chanall's repository) shows a bug here in that it cycles endlessly through the "geometry" output without allowing to return to the command line. But the "Editor" menu entry works fine, comfortably opening the FreeDos editor with both configuration files that will be modified most frequently, AUTOEXEC.BAT and MENU.LST, on a single keystroke, and returning to the menu automatically.

 

Gerolf



#16 Gerolf

Gerolf

    Member

  • Members
  • 75 posts
  •  
    Germany

Posted 19 April 2021 - 12:46 AM

Sometimes you need to look closer than you think, here is the (IMHO) "good" version of 0.4.4 (last one):

http://reboot.pro/in...showtopic=16641

http://reboot.pro/in...ds&showfile=175

 

While I have spent so many years with old versions of DOS and Windows that I feel a little nostalgic about them, the emotional aspect is not exactly the same for me with old versions of Grub4DOS. So I do not really look for the oldest version of GRUB.EXE that can boot reliably in PCem, but rather for the newest one. Thus, when it turned out that the oldest version from Chenall's repository (0.4.4 of 2009-11-14) was bootable, I had no immediate reason to test an even older one, at least as long as no severe bugs showed up and the newer releases were even buggier or unbootable in PCem. But I'm not that pessimistic.

 

12. The plan is to check the next end-of-year releases. So download

http://dl.grub4dos.c...-2009-12-03.zip

and extract GRUB.EXE. ImDisk-mount BACKWARD.VHD to, say, drive G: and copy GRUB.EXE to a newly created G:\_PRO\GRUB4DOS\4-091203 folder. Edit G:\AUTOEXEC.BAT as follows:

:: SET GRUBDIR=C:\_PRO\GRUB4DOS\4-091016
:: SET GRUBDIR=C:\_PRO\GRUB4DOS\4-091114
   SET GRUBDIR=C:\_PRO\GRUB4DOS\4-091203
SET PATH=C:\_SYS\PCD200;C:\_PRO\DOSTOOLS;%GRUBDIR%
GRUB

Unmount BACKWARD.VHD and reboot that image in PCem. It's a success; the latest Grub4DOS version 0.4.4 of 2009-12-03 passes the PCem booting test too. No differences in behaviour appear at first sight, compared with the 2009-11-14 version, the "geometry" runaway bug still being present. And the 2009-10-16 version fares no better.

 

Steve says that version 0.4.6a introduced USB 2.0 drivers. What was the reason for the version change from 0.4.4 to 0.4.5? His tutorial states that 0.4.5a and 0.4.5b were alpha and beta releases. Can I ignore them completely? I'm not quite sure yet about how to deal with the overlap in timeline of these versions when testing the next GRUB.EXEs from Chenall's repository.

 

Gerolf



#17 Gerolf

Gerolf

    Member

  • Members
  • 75 posts
  •  
    Germany

Posted 19 April 2021 - 02:24 AM

The "map --unmap=0" command intends to prevent a mapping-stack buildup when the editor is started repeatedly.

 

I wonder if it must be "map --unmap=0,1" since both floppies (fd0) and (fd1) are involved in the mappings in step 11 (post #15).

 

Gerolf


Edited by Gerolf, 19 April 2021 - 02:46 AM.


#18 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 19 April 2021 - 08:44 AM

The numbering in the development of grub4dos has been over the years confusing, and it was changed around that time (end 2009, begin of 2010, which - if I remember correctly - is also around the time the development passed from tinybit to chenall). 

 

0.4.5a and 0.4.5b were not strictly  "alpha" and "beta", though the meaning is very similar, see:

http://reboot.pro/in...=17576&p=189017

 

The problem with "intermediate" versions may be that one later version introduces one or more features BUT accidentally introduces one or more new or "regression" bugs, bugs that are usually fixed in the "next" version as soon as they are discovered/reported.

 

In a perfect word these fixes should happen to unmodified code, but in the case of grub4dos often a new release fixes the found bugs but at the same time introduces something new (and possibly some new bugs) so, particularly for "niche" uses (such as yoiur PcEm experiments) it is a "hit and miss" game to find (if any) the version with "enough" features and "irrelevant" (for the specific use) bugs.

 

As an example it is perfectly possible that a 0.4.5a version works in your environment and for your needs but it has a bug in something that you will never use (let's say for the sake of reasoning PXE booting) while the next 0.4.5a version has that PXE issue fixed (using the fixed code of an intermediate 0.4.5b) but introduces something that prevents you from booting in PcEm.

 

The:

map (hd0,2)/_SYS/PCD200/PCD200ED.IMG (fd0)

should be :unsure: replaceable by:

find --set-root /_SYS/PCD200/PCD200ED.IMG

map /_SYS/PCD200/PCD200ED.IMG (fd0)

to make it more "portable".

 

:duff:

Wonko



#19 Gerolf

Gerolf

    Member

  • Members
  • 75 posts
  •  
    Germany

Posted 21 April 2021 - 03:41 AM

Now my AUTOEXEC.BAT on the FAT12 boot partition of the described BACKWARD.VHD looks like this:

:: Versions of GRUB.EXE that fail to boot in PCem under PC-DOS 2.0 are commented out:
   SET GRUBDIR=C:\_PRO\GRUB4DOS\4-091016
   SET GRUBDIR=C:\_PRO\GRUB4DOS\4-091114
   SET GRUBDIR=C:\_PRO\GRUB4DOS\4-091203
   SET GRUBDIR=C:\_PRO\GRUB4DOS\5-091223
   SET GRUBDIR=C:\_PRO\GRUB4DOS\5A100420
   SET GRUBDIR=C:\_PRO\GRUB4DOS\5B101231
   SET GRUBDIR=C:\_PRO\GRUB4DOS\5B111230
   SET GRUBDIR=C:\_PRO\GRUB4DOS\5B120116
   SET GRUBDIR=C:\_PRO\GRUB4DOS\5C120117
   SET GRUBDIR=C:\_PRO\GRUB4DOS\5C120618
   SET GRUBDIR=C:\_PRO\GRUB4DOS\5C121117
   SET GRUBDIR=C:\_PRO\GRUB4DOS\5C121205
   SET GRUBDIR=C:\_PRO\GRUB4DOS\6A121205
:: SET GRUBDIR=C:\_PRO\GRUB4DOS\5C121216 :: hangs with black screen
:: SET GRUBDIR=C:\_PRO\GRUB4DOS\6A121216 :: hangs with black screen
:: SET GRUBDIR=C:\_PRO\GRUB4DOS\5C121231 :: hangs with black screen
:: SET GRUBDIR=C:\_PRO\GRUB4DOS\6A121231 :: hangs with black screen
   SET GRUBDIR=C:\_PRO\GRUB4DOS\5C130113
   SET GRUBDIR=C:\_PRO\GRUB4DOS\6A130113
   SET GRUBDIR=C:\_PRO\GRUB4DOS\5C130202
   SET GRUBDIR=C:\_PRO\GRUB4DOS\5C130303
   SET GRUBDIR=C:\_PRO\GRUB4DOS\5C130630
   SET GRUBDIR=C:\_PRO\GRUB4DOS\5C131130
   SET GRUBDIR=C:\_PRO\GRUB4DOS\6A131130
   SET GRUBDIR=C:\_PRO\GRUB4DOS\5C140117
   SET GRUBDIR=C:\_PRO\GRUB4DOS\6A140117
:: SET GRUBDIR=C:\_PRO\GRUB4DOS\5C140624 :: hangs with black screen
:: SET GRUBDIR=C:\_PRO\GRUB4DOS\6A140624 :: hangs with black screen
:: SET GRUBDIR=C:\_PRO\GRUB4DOS\6A140918 :: hangs with black screen
:: SET GRUBDIR=C:\_PRO\GRUB4DOS\5C141224 :: hangs with black screen
:: SET GRUBDIR=C:\_PRO\GRUB4DOS\6A141227 :: hangs with black screen
:: SET GRUBDIR=C:\_PRO\GRUB4DOS\5C151231 :: hangs with black screen
:: SET GRUBDIR=C:\_PRO\GRUB4DOS\6A151231 :: hangs with black screen
:: SET GRUBDIR=C:\_PRO\GRUB4DOS\5C160118 :: hangs with black screen
:: SET GRUBDIR=C:\_PRO\GRUB4DOS\6A161224 :: hangs with black screen
:: SET GRUBDIR=C:\_PRO\GRUB4DOS\6A171223 :: hangs with black screen
:: SET GRUBDIR=C:\_PRO\GRUB4DOS\6A181223 :: hangs with black screen
:: SET GRUBDIR=C:\_PRO\GRUB4DOS\6A191230 :: hangs with black screen
:: SET GRUBDIR=C:\_PRO\GRUB4DOS\6A200809 :: hangs with black screen
:: SET GRUBDIR=C:\_PRO\GRUB4DOS\6A210127 :: hangs with black screen
SET PATH=C:\_SYS\PCD200;C:\_PRO\DOSTOOLS;%GRUBDIR%
GRUB

It turned out that the latest GRUB.EXEs that can boot in PCem under PC-DOS 2.0 date from 2014-01-17. During these tests I always expected to get a message like "unsupported DOS version", but that was not the case. Instead, GRUB.EXE either booted correctly or hang with a black screen and a blinking cursor in the upper left corner.

 

If I observed correctly, some of the "good" binaries shortly showed the "A20 Debug: C806 done! ..." message I had mentioned in my first post and then booted nevertheless, so I think this message is just informative and does not stem from the critical error that causes the hang-up, but rather happens to be just the last message written to screen before the error occurs.

 

It is noteworthy that the GRUB.EXE binaries were fixed once shortly after they broke, but then broke again one year later. And this appeared at the same dates with both 0.4.5c and 0.4.6a versions, so the bug must be in the code that was ported back or forth. In detail:

 

(...)

http://dl.grub4dos.c...c-2012-12-05.7z boots

http://dl.grub4dos.c...a-2012-12-05.7z boots

http://dl.grub4dos.c...c-2012-12-16.7z hangs

http://dl.grub4dos.c...a-2012-12-16.7z hangs

http://dl.grub4dos.c...c-2012-12-31.7z hangs

http://dl.grub4dos.c...a-2012-12-31.7z hangs

http://dl.grub4dos.c...c-2013-01-13.7z boots

http://dl.grub4dos.c...a-2013-01-13.7z boots

(...)
http://dl.grub4dos.c...c-2014-01-17.7z boots

http://dl.grub4dos.c...a-2014-01-17.7z boots
http://dl.grub4dos.c...c-2014-06-24.7z hangs

http://dl.grub4dos.c...a-2014-06-24.7z hangs

(...)

 

Latest entries in ChangeLog_chenall.txt of grub4dos-0.4.6a-2014-06-24:

 

2014-06-23(yaya)
    1. Improved emulation of files with fragments. Up to 32 fragments. If all new versions are used, fragmentation information can be passed.
    2. ntfs file system supports list of non-resident attributes up to 8Kb.
    3. Fixed udf format CD driver bug.
    4. Fixed iso9600_Joliet file format escape character display problem.

2014-01-16(yaya)
    1. When the u-disk in FDD mode (with BPB, no partition table) is assigned drive number 0x80 by BIOS, it is mapped to 0x00.
      At the same time, the drive number 0x80 is masked (to avoid reading the u-disk through BIOS, which may crash).
        This change also avoids the problem of Issue 162 reading 64-bit logical sectors.
        FDD mode u-discs are recognized as hard disks and have a lot of problems. The problems that have been found are executing find, which does not return (hd0), and Lite PE loading image file crashing.
    2. solved the problem that the u-disk in FDD mode returns (fd0,n) when executing find.
    3. Fixed the default location of 0PE.ISO in menu.lst.
    4. usb2.0 driver is loaded with usb --init via menu or command line.
    5. usb2.0 driver adds support for hubs (HUBs). If the load fails, try rebooting.  
    6. When reading multiple sectors fails, a prompt will be given: unplug the disk and insert it again, press any key to continue. At this time, the u-disk will be reinitialized.
      and read 1 sector at a time to continue from the failure point.
    7. Enhance file name recognition for renaming.
    7.1 The file name can be any case, but must be capitalized in grldr.mbr and grldr.pbr.
    7.2 In grldr.pbr.
        FAT16, FAT32 partitions use the 8.3 format.
        ext2, exFAT, NTFS partitions use 12 characters.
    7.3 In grldr.mbr: use 12 characters.
        7.4 For compatibility with all types of partitions, it is recommended that file names should not be larger than 8 characters and suffixes should not be larger than 3 characters. If there is a separator character "." must not be omitted.

2014-04-01(yaya)
    1. improved the usb2.0 driver device enumeration. Improved drive number identification. Run directly from current location, cache moved to 0x80000. resident memory streamlined to 4 Kb.
    2. Support fragmented file emulation, up to 8 fragments. Occupies 11Kb - 13Kb of memory (determined by whether the optical drive is loaded).
    3. Supports short filenames in lowercase for WinXP systems. According to the short file name offset 0x0c: bit 3=1 means lowercase file name, bit 4=1 means lowercase file extension.
    4. mkisofs 2.00/2.01 can be correctly recognized to generate buggy Joliet format CDs.

2013-10-18
    1. New function similar to PATHEXT of CMD, you can set the default extension.
      Use command --set-ext to set, each extension is separated by ";"
      Example.
      command --set-ext=.g4b;.g4e
      You can execute without typing the extension, for example typing test will be used automatically if there is a test.g4b in the current path.
2013-10-17
    1. Modify the code to support the new version of HOTKEY.
      
2013-07-10
    1. insmod now supports long file names (up to 11 characters before, no limit now).
    2. Modify some code to eliminate the "Warning" message during compilation.

2013-06-30
    1.Solve the memory conflict problem when the command line is too long or the batch process has too many parameters.

2013-03-19
    1. Add a new command separator ";;" for unhindered sequential execution.
    Example:
    set a=abcd ;; echo %a% ;; set a=
2013-03-02
    1. Solve Issue 117: menu border has arrow symbol (bottom right)
    2. Let other display modes also specify the menu box color. color border=xx

2012-05-16
    1. Remove case insensitive control for ISO9660 file system. The new version is forced to be case-insensitive

Translated with www.DeepL.com/Translator (free version)

 

Latest entries in ChangeLog_GRUB4DOS.txt of grub4dos-0.4.6a-2014-06-24:

2013-10-18 (chenall) add new command options --set-ext,set default grub4dos executable extensions.
2013-09-17 (tinybit) workaround for ASRock ConRoe865PE (issue 153).
2013-07-12 (tinybit) code cleanup against unused GRUB_UTIL, STAGE1_5, NETBOOT, DISKLESS.
2013-06-24 (tinybit) Improved startup message fighting against hangups due to wrong menu setup by users.
2013-06-23 (yaya) fix issue 85(bootlace64.com can not run on 64-bit linux).
2013-05-21 (daven) enhanced the debug boot code (press Insert when grldr is loading to activate).
2013-05-16 (chenall) done issue 133(add `set @extend BASE_ADDR size`).
2013-04-06 Fixed the file missing BUG on ISO9660 file system,fsys_iso9660.c(iso9660_dir func).
2013-03-29 (chenall) fix issue 125,path limitation in menu.
2013-03-28 (chenall) fix issue 126;
2013-03-20 (chenall)Add new operator ";;";
2013-02-28 (tinybit) re-resolved issue 74.
2013-02-02 (tinybit)enhanced eltorito.sys for working with buggy BIOS which not supporting INT13/4B01.
2013-01-17 (tinybit)fix issue 107 and issue 109.
2013-01-12 (tinybit)cancel r313. add eltorito.sys. set safe_mbr_hook=1.
2012-12-30 fixed a bug on checking filename length in grub_open(issue 103).
2012-12-16  bug fixed(Issue 100: echo to nul after kernel command causes crash).
2012-12-13 (tinybit)set timeout back to 1. set safe_mbr_hook to 0.
2012-11-22 (tinybit)minor fixes on geometry_func and others.
2012-11-07 (tinybit)avoid using memory between address 15M and 16M.

 

Latest entries in ChangeLog_chenall.txt of grub4dos-0.4.5c-2014-06-24:

 

2013-10-18
    1. New function is similar to PATHEXT of CMD, you can set the default extensions.
      Use command --set-ext to set, each extension is separated by ";"
      Example.
      command --set-ext=.g4b;.g4e
      You can execute without typing the extension, for example typing test will be used automatically if there is a test.g4b in the current path.
2013-10-17
    1. Modify the code to support the new version of HOTKEY.
      
2013-07-10
    1. insmod now supports long file names (up to 11 characters before, no limit now).
    2. Modify some code to eliminate the "Warning" message during compilation.

2013-06-30
    1.Solve the memory conflict problem when the command line is too long or the batch process has too many parameters.

2013-03-19
    1. Add a new command separator ";;" for unhindered sequential execution.
    Example:
    set a=abcd ;; echo %a% ;; set a=
2013-03-02
    1. Solve Issue 117: menu border has arrow symbol (bottom right)
    2. Let other display modes also specify the menu box color. color border=xx

2012-05-16
    1. Remove case insensitive control for ISO9660 file system. The new version is forced to be case-insensitive

Translated with www.DeepL.com/Translator (free version)

 

Latest entries in ChangeLog_GRUB4DOS.txt of grub4dos-0.4.5c-2014-06-24:

 

2013-12-14 (tinybit) Workaround for BIOS of BENQ notebook that only supports 1
sector per read(reported by mygamexxx of bbs.wuyou.com). Disabled
Single-Key-Selection feature by default(issue 161). Some fixes on (ud).
2013-10-18 (chenall) add new command options --set-ext,set default grub4dos executable extensions.
2013-09-17 (tinybit) workaround for ASRock ConRoe865PE (issue 153).
2013-07-12 (tinybit) code cleanup against unused GRUB_UTIL, STAGE1_5, NETBOOT, DISKLESS.
2013-06-24 (tinybit) Improved startup message fighting against hangups due to wrong menu setup by users.
2013-05-24 (tinybit) Fix no-emulation-mode boot code so as to load 32K of preset-menu.
2013-05-21 (daven) enhanced the debug boot code (press Insert when grldr is loading to activate).
2013-05-16 (chenall) done issue 133(add `set @extend BASE_ADDR size`).
2013-03-29 (chenall) fix issue 125,path limitation in menu.
2013-03-28 (chenall) fix issue 126;
2013-03-20 (chenall)Add new operator ";;";
2013-02-28 (tinybit) re-resolved issue 74.
2013-02-02 (tinybit)enhanced eltorito.sys for working with buggy BIOS which not supporting INT13/4B01.
2013-01-17 (tinybit)fix issue 107 and issue 109.
2013-01-12 (tinybit)cancel r313. add eltorito.sys. set safe_mbr_hook=1.
2012-12-30 fixed a bug on checking filename length in grub_open(issue 103).
2012-12-16  bug fixed(Issue 100: echo to nul after kernel command causes crash).
2012-12-13 (tinybit)set timeout back to 1. set safe_mbr_hook to 0.
2012-11-22 (tinybit)minor fixes on geometry_func and others.

 

So my fixing tip would be:

 

2013-01-12 (tinybit)cancel r313. add eltorito.sys. set safe_mbr_hook=1.

 

Surely I should repeat those tests with higher DOS versions, a FAT16 boot partition, and an updated master boot record, but my first impression is that this issue does not depend on the DOS version.

 

Gerolf



#20 Gerolf

Gerolf

    Member

  • Members
  • 75 posts
  •  
    Germany

Posted 21 April 2021 - 05:11 AM

 I see WinVBlock developer Sha0 asked Tinybit to set asm.S variable safe_mbr_hook=0 on 2012-12-13, just three days before the error occurred first:

http://reboot.pro/in...showtopic=17881

The current README_GRUB4DOS.txt still states that "along with 0.4.2 final" the default value is 1 and it can be set to 0 with the command
    map --safe-mbr-hook=0

But this requires GRUB.EXE to boot and evaluate MENU.LST, which fails so that I cannot test both values.

 

Gerolf



#21 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 21 April 2021 - 10:17 AM

 I see WinVBlock developer Sha0 asked Tinybit to set asm.S variable safe_mbr_hook=0 on 2012-12-13, just three days before the error occurred first:

http://reboot.pro/in...showtopic=17881

The current README_GRUB4DOS.txt still states that "along with 0.4.2 final" the default value is 1 and it can be set to 0 with the command
    map --safe-mbr-hook=0

But this requires GRUB.EXE to boot and evaluate MENU.LST, which fails so that I cannot test both values.

 

Gerolf

Yes and no. :w00t:

 

The menu.lst that is loaded by grub4dos is actually "menu#2.lst" as there is a main, embedded menu.lst in grldr and in grub.exe (the last few bytes) that is executed before any external file (and this embedded menu.lst  can be edited).

 

Still,. if the error comes out before even this embedded internal menu is parsed, it won't change anything. :(

 

I.e. if the "bad" versions choke on accessing the disk, after having parsed the internal menu, then adding to it first thing the "map --safe-mbr-hook=0" may make a difference, but if this happens before disk access (for whatever reasons) it will obviously be ineffective. 

 

 

:duff:

Wonko



#22 Gerolf

Gerolf

    Member

  • Members
  • 75 posts
  •  
    Germany

Posted 21 April 2021 - 08:50 PM

Still,. if the error comes out before even this embedded internal menu is parsed, it won't change anything. :(

 

I.e. if the "bad" versions choke on accessing the disk, after having parsed the internal menu, then adding to it first thing the "map --safe-mbr-hook=0" may make a difference, but if this happens before disk access (for whatever reasons) it will obviously be ineffective.

 

Sadly, the latter seems to be the case: I added "map --safe-mbr-hook=1" and then "map --safe-mbr-hook=0" at the beginning of the internal menu of GRUB.EXE version 0.4.6a-2014-06-24, but neither could heal the hang-up at boot time.

 

Gerolf



#23 Gerolf

Gerolf

    Member

  • Members
  • 75 posts
  •  
    Germany

Posted 22 April 2021 - 03:22 PM

I submitted an issue:

https://github.com/c...4dos/issues/261

 

Gerolf



#24 Gerolf

Gerolf

    Member

  • Members
  • 75 posts
  •  
    Germany

Posted 01 May 2021 - 06:17 PM

Yaya wrote:

 

 

Try the new version .

https://github.com/c...21-04-28.7z.txt

 

Thank you very much for looking into this issue, Yaya! And yes, the GRUB.EXE contained in https://github.com/c...21-04-28.7z.txt (time-stamped 04:37) does boot from PC-DOS 2.0 in PC Emulator, whereas the regular binary contained in http://dl.grub4dos.c...a-2021-04-28.7z (time-stamped 04:40) fails to do so.

 

Now that the latest GRUB.EXE is available for further tests in PCem, it quickly appears that it does not yet behave as expected, failing to "root" in the experiment described in post 15:

title Editor\n\n Edit AUTOEXEC.BAT and MENU.LST
map --unmap=0,1
map (hd0,2)/_SYS/PCD200/PCD200ED.IMG (fd0)
map (fd0) (fd1)
map --hook
root (fd0)
chainloader (fd0)+1

The error message is: "Error 17:(http://grub4dos.chenall.net/e/17) Cannot mount selected partition", with a missing help text at that URL. The partition number can be checked with the "geometry" command which outputs: "Partition num: 2, active, Filesystem type is fat12, partition type 0x01". So the more portable formulation suggested in post 18 does not help:

find --set-root /_SYS/PCD200/PCD200ED.IMG
map /_SYS/PCD200/PCD200ED.IMG (fd0)

However, the desired booting of a second DOS instance that autoexecutes an editor with already opened configuration files was possible in PCem with the aforementioned version http://dl.grub4dos.c...a-2014-01-17.7z and earlier.

 

And with the new GRUB.EXE contained in https://github.com/c...21-04-28.7z.txt the desired booting is indeed possible in VirtualBox.

 

It does not help if the partitioning made with FDISK from PC-DOS 2.0 (which causes code to be written immediately after the master boot record) is instead made with FDISK from MS-DOS 3.31 (which leaves empty space there).

 

Gerolf



#25 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 02 May 2021 - 08:19 AM

The 

 

map (hd0,2)/_SYS/PCD200/PCD200ED.IMG (fd0)

 

and the 

 

find --set-root /_SYS/PCD200/PCD200ED.IMG
map /_SYS/PCD200/PCD200ED.IMG (fd0)

 

are (should be) perfectly the same.

 

Try (on command line):

find --set-root /_SYS/PCD200/PCD200ED.IMG

root <- if this outputs (as it should) (hd0,2)

and thus the following:

map /_SYS/PCD200/PCD200ED.IMG (fd0)

is exactly the same as:

map (hd0,2)/_SYS/PCD200/PCD200ED.IMG (fd0)

 

If you prefer, if you try:

root (hd0,2)

root <- output will be (hd0,2)

map /_SYS/PCD200/PCD200ED.IMG (fd0)

 

it is once again the same.

 

:duff:

Wonko






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users