Jump to content











Photo
- - - - -

How do I boot Grub4DOS from VHD in PCem?


  • Please log in to reply
9 replies to this topic

#1 Gerolf

Gerolf

    Member

  • Members
  • 32 posts
  •  
    Germany

Posted A week ago

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
  • 15604 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted A week ago

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
  • 32 posts
  •  
    Germany

Posted A week ago

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
  • 32 posts
  •  
    Germany

Posted A week ago

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, A week ago.


#5 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted A week ago

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
  • 32 posts
  •  
    Germany

Posted 5 days ago

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
  • 32 posts
  •  
    Germany

Posted 5 days ago

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
  • 32 posts
  •  
    Germany

Posted 4 days ago

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
  • 15604 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 4 days ago

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
  • 32 posts
  •  
    Germany

Posted 8 hours ago

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






1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users